Why IT Managers Should Care About Agile 2 - CC Pace

Everyone says you should use Agile. The call for Agile has reached the CEO level: I myself have heard CEO announcements stating that the organization must use “Agile”—whatever that is, because I wonder how many actually know.

On the other hand, how many Agile proponents actually understand what Agile is? As I wrote in a recent article, Old Versus New Agile, Agile has changed—and changed a lot. Thus if you bring in “Agile” consultants to help, are they using “old Agile,” or “new Agile”?

Old Agile is arguably very limited, and does not acknowledge the realities of a large organization. What I refer to as “new Agile”—and I believe it is described well by Agile 2—is completely focused on the general problem of agility, and how that plays out in the broad range of situations, including and especially large organizations. Because to do big things—profitable things at scale—you need a very sophisticated model. Agile 2 provides that.

I have seen IT managers make tragic and far-reaching mistakes in their attempt to follow “old” Agile. For example, in more than one case an IT SVP eliminated all roles pertaining to testing. I wrote in an article why that is a tragic error that eventually results in terrible quality issues and actually impedes agility.

Old Agile is not all bad. It broke the grip of rigid approaches being pushed at the time by PMI and the procurement school of thought. In a fast-changing market, custom market-facing software cannot be “procured”: it must be seen as something that evolves over time. Agile made us face that. Some of the ideas that it brought into the forefront were:

• Phase-based (requirements, design, implementation) software development does not usually work.
• Business users often do not know what they want or need.
• It is almost impossible to fully design software up front
• Documents alone are not effective for communicating things
• Don’t build something entirely in one go
• Big teams do not work
• Don’t micromanage how developers work
• Don’t trust anything until you see it running
• Build quality in
• More effort ≠ better; automate to avoid effort
• Continuously reflect and improve

These are all good things, especially if one views them as reminders rather than absolutes. But the Agile community also came to espouse some extreme and ultimately toxic viewpoints—again, especially if one views them as absolutes (which is often the case). I consider these views to be part of “old” Agile. These include:

 Teams do not need leaders, except to “remove impediments”.

 Always trust the team.

 A team must be completely autonomous.

 Multiple teams will collectively self-organize.

 Written communication is not important.

 Everyone must sit together.

 Most challenges pertain to individual contributor team behavior.

 Teams can resolve technical issues if leaders merely “get out of the way.”

 If Agile does not work at scale, it is the organization’s “fault.”

 Specific technical practices such as pair programming and TDD are always “best.”

In contrast, “new” Agile ideas are markedly different. A tiny sampling of these authors includes Klaus Leopold, Nicole Forsgren, Jeff Dalton, David Marquet, Matthew Skelton, Manuel Pais, Mirco Hering, Mark Schwartz, and Gary Gruver, as well as some “old Agile” authors who have evolved a mature view over time (or had one from the beginning) such as Johanna Rothmann, Diana Larsen, as well as myself and the 15 members of the Agile 2 team.

You probably see now that the peril of bringing in Agile consultants is that you might not know if they embrace “old” Agile ideas or “new” Agile ideas. But that is not all. “New” Agile includes many additional narratives that are critical for achieving agility at scale. The Agile 2 team attempted to summarize these through its principles, but a very abbreviated summary is as follows. Note that these are considerably at variance with “old” Agile, but are well aligned with the “new” Agile that Agile 2 and many of the above authors advocate:

On leadership:

• The predominant forms of leadership are the most determinant factors of success.
• Someone usually needs to coordinate things, and be the organizer.
• On any team, one wants a “missionary, not mercenary”—someone who values the organization’s success first and foremost.
• There are many forms of leadership: team focused, advocate focused, technically focused, and maybe others; as well as individual leadership.
• The organization needs to explicitly focus on encouraging benign and effective forms of leadership, and take steps to avoid giving the wrong people authority—avoiding people who “seem like leaders,” and instead selecting (actively or passively) those who are the “missionaries” and the helpers.
• Leadership is needed at every level of an organization, and the same principles apply.
• Leaders of tech-focused organizations not only need to understand outcomes, but they also need to understand how the work is done, because the “how” is often strategic.

On a systems approach:

• Don’t be extreme, unless the situation is extreme.
• Always think holistically—in terms of the whole system.
• Product design is an essential element, apart from product implementation; yet the two are intertwined.

On products:

• Direct feedback from customers and stakeholders is the only way to measure success.
• Product implementation teams must be partners with business stakeholders—not mere order takers.

On data:

• Data is strategic, and it must not be treated as an afterthought.

On collaboration:

• Collaboration is essential, but so is deep thought. People often need quiet and isolation in order to think deeply.
• People work, communicate, and collaborate best differently. A one-size-fits-all approach is not effective.
• Team autonomy is an essential aspiration; but for a complex endeavor, full autonomy is seldom fully realizable.
• Some people want to be experts. Some people want to be generalists. Some are in between. All are valuable.
• Both teams and individuals matter. Don’t over-emphasize one over the other.
• A team should collectively decide how to approach its work; but then individuals perform the work and interact as they need to.

On transformations:

• Transformations are mostly a learning journey—not a process change.
• Never use a framework as defined: treat it as a source of ideas—not an Agile-by-numbers process.

Conclusion

Agile is not a single theory or approach. There is great diversity of thought within the Agile community. When choosing consultants or an approach for adopting Agile methods, be thoughtful about who you choose. Ask yourself, are they interested in putting people on the ground to deliver a commodity service? Or are they deeply thoughtful about what they do, and represent mature and effective viewpoints? And will the people they provide be as up-to-date and astute about the nuances of old versus new Agile ideas as those who have had conversations with you? Because it matters.