You Don’t Need a Framework to be Agile

Out of the boxAny systematic approach to managing work is better than no system. And any of the existing Agile frameworks are better than a “waterfall” method where Agile is more appropriate, the majority of cases. But you don’t need Crystal or SAFe or even my Full Scale agile™ to be Agile.

At the same time Scrum was being developed, I began training “self-directed work teams” (SDWTs) that met all of the principles of the Agile Manifesto years before it was written. As detailed in an earlier post, they had all the functional roles needed to complete their various duties. They met every week or two to review issues new and old, make decisions, and create, volunteer for, and report on tasks. They were in contact with customers every day, and released changes in small increments as those were ready. One set of teams I worked with delivered a major change project to high customer satisfaction without creating a project plan, and without overtime. All were also truly self-organizing: They created their own team rules and procedures, and had no team leaders.

Scrum pioneer Jeff Sutherland has described how various methods now called “Agile” co-evolved in the early days. Obviously, all of the current methods had to be created by somebody! “The New New Product Development Game,” a groundbreaking report in Harvard Business Review in 1986, described highly empowered product development groups in which executives provided marching orders and money and little else.

My point is that any line manager could easily implement an Agile mindset simply by turning their team into an SDWT. Adding in the scientific evidence that decentralized firms based on small empowered groups improve financial performance, and the best approach for upper managers to create an Agile organization might seem the most radical:

  1. Decide on a specific need you want to fill, and how much you can spend on a workable design or minimal viable product.
  2. Choose an initial set of people with all the business and technical skills needed to produce that product or service, and strip them of their job titles.
  3. Tell them to follow the Agile Manifesto, replacing the word “software” with their product type if it isn’t software.
  4. Exempt them from all organizational policies not required by law, regulations, or ethics.
  5. Put them in an offsite conference center with skilled big-meeting facilitators to self-organize.

That’s it. The rest, including the schedule, is up to the people. Read the “New New” article to see how this works out.

I spent months writing up the Full Scale agile™ (FuSca™) website for do-it-yourselfers, yet the steps above are the way I wish everyone would implement Agile. The goal is complete freedom for all programs to meet their customers’ needs as they see fit. They might choose to implement an initially prescriptive methodology like FuSS, but wouldn’t have to.

Unfortunately, few executives appear willing to implement this approach, despite the data in its favor. My attempts over 14 years when I was a teamwork consultant to get managers to succeed by giving up control met with limited success. One objection I still hear today is that this would show the company is “out of control.” In a sense that is true! But again, the best evidence says a lack of centralized control will improve a firm’s financial performance.

Nonetheless, these executives feel more comfortable buying a package other executives have bought, though created by strangers, than trusting their own workers to create something workable. In the old “make or buy” dilemma, they feel safer buying. I don’t mean this to sound as critical as it probably does. There are a host of reasons why good managers often cannot adopt radical empowerment even when they want to.

That being the case, the question then becomes, what is the Lean-est way to implement Agile quickly that eventually maximizes team and worker empowerment for the benefit of all stakeholders? An approach like Full Scale agile is my psychology-based answer:

  1. Use an organizational culture change method to build consensus behind one pre-built system.
  2. Get agreement to try the system completely, with all its parts, until everyone understands how they fit together
  3. Then allow process experimentation as long as performance standards are met.

This approach provides managers a greater sense of confidence and oversight, and balances efficiency with empowerment. My hope is that once a program or team proves itself through this disciplined means, managers will free people to maximize both.

However, in the spirit of 1960s counterculture figure Abbie Hoffman, who wrote a book called Steal this Book, I say: “Don’t use my Agile framework!” Create your own. Only if you aren’t allowed to, or need something workable right away, should you go the pre-packaged route.

Subscribe

Please share this post at the bottom of the page.


Sources:

  • Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” Harvard Business Review, January 1, 1986, https://hbr.org/1986/01/the-new-new-product-development-game.
  • Rigby, Darrell K., Jeff Sutherland, and Hirotaka Takeuchi. “The Secret History of Agile Innovation.” Harvard Business Review, April 20, 2016. https://hbr.org/2016/04/the-secret-history-of-agile-innovation.
Tell the world: