Agile was a reaction to the dysfunctional methods that were not working at the time – the late 1990s – but Agile was in many ways an overreaction. The Agile Manifesto did this through two statements:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The best architectures, requirements, and designs emerge from self-organizing teams.
The first statement says to “trust the team”. That is fine, except that it says this without adding any qualification, such as “trust but verify”, or “trust but check on them to make sure they are on track.” Unqualified trust translates into no oversight – any other interpretation is reading words into the statement that are not there. Indeed, the Agile lead at a major US government agency told me that one should always trust the team a priori.
About the author
Cliff Berg is an Agile evangelist
The second statement advocates the use of “self-organizing” teams – that is, teams that have no designated leadership or predefined structure. A self-organizing team might select its leadership from within the team, and define its structure, but none is defined from the outside.
These two statements are often read as: leave us alone.
I should point out that an experienced person will read the Manifesto differently from someone less experienced. For example, an experienced person will read the phrase “self-organizing team” and assume that – of course – some oversight is needed. But someone inexperienced will take the statements of the Manifesto at face value, and in that sense, the statements are very misleading: they are a drastic oversimplification of what is needed. The simplicity of the Manifesto has allowed it to be misused – to be seen as a pure and perfect document, to be followed as stated. But really, it is just a set of ideas and those ideas do not quite work as stated: they require interpretation but the Manifesto provides no guidance on how to interpret its statements.
The implicit anti-management attitude of the Manifesto has been very problematic for Agile. Large organizations have lots of managers, and those who want to use Agile methods do not know how their managers are supposed to interact with Agile teams, except to leave them alone. But what does one do if one needs to create a team? Or decide who on a team should receive a pay raise or promotion or how they should coordinate their work?
There are so many unanswered questions that Agile stumbled when introduced to large organizations. These problems came to be viewed in terms of “how to scale Agile”. Over time, many different people proposed solutions to the scaling problem, but the solutions, while having some overlap, were mostly divergent and irreconcilable and were also packaged into branded “frameworks”.
There are many other problems with Agile besides scaling. One is that it fails to address data, which is strategically important for many organizations and strongly impacts – or should impact – its IT systems and their design. Another problem is that the culture of the Agile community has come to treat teams as the singularly important unit. The role of the individual has been downplayed: Agile favors “generalists” or “generalizing specialists” who are largely substitutable. This is a good practice, but individuals are still important, and so are experts.
Agile 2 attempts to fill the gaps left by Agile, and correct some of its extreme viewpoints, whether those viewpoints were expressed by the Agile Manifesto or evolved among the Agile community.
How Agile 2 changes Agile
The first thing that Agile 2 brings back to Agile is balance and judgment. Too much of the thinking in the Agile community is extreme. The community is dominated by a unidirectional push toward more and more collaboration and face-to-face interaction, with less and less focus on peoples’ need to focus, think deeply, and get work done. This is a relentless cultural theme among Agile coaches. The community has forgotten that ideas come not only from collaboration, but also from individual inspiration and private reflection, and that people are most productive when they pay attention to one thing at a time and have few distractions.
The community is also a slave to Scrum: somehow, organizations that try to use Agile methods think that they have to start with Scrum – demonstrating the success of the Scrum training and certification vendors’ marketing machines more than anything else.
Instead of these forms of dogma and extremism, what is needed is a judgment on each situation. Agile is a set of ideas, and to use those ideas, one must think, and then use judgment to apply the ideas. Agile is not a methodology: it is a philosophy. Agile 2 tries to restore judgment and thoughtfulness, and call attention to the drawbacks of rigidity and extremes.
Agile 2 brings back the idea that one needs many forms of leadership. Simply telling teams that they each need to self-organise, and that managers should just trust the teams – these are not enough. It brings the focus back to the individual, as well as the team. Individuals need attention. They need professional growth and mentorship, coaching, leadership development, opportunities to learn, to try new things, and receive frequent feedback. Individuals also need individual recognition, and they need opportunities to advance professionally.
The Agile culture has become all about the team. Agile 2 says loud and clear that while teams matter, individuals matter too.
Agile 2 covers many other things as well. It addresses data from three perspectives. One is that data is a strategic asset, and must be managed so that one can later correlate it and derive insights. This is a response to the observation that development teams today often fail to catalog the data that they write to NoSQL databases and that gets broadcast to data lakes, resulting in a heap of historical data that is useless for business intelligence or machine learning analysis, or training.
Another perspective on data is that an organization’s data model needs to be understood by development teams. Too often teams are expected to start coding as soon as an initiative begins, but they do not understand the operational data stores or how data relates.
A third perspective is that test data is important. Too often it is expected that developers will cobble together test data. I was once in a client program meeting and a development lead joked to another that his team’s tests always pass because they create test data that they know will pass. The dilemma that teams have is that they often do not have sets of realistic test data. Business stakeholders are in the best position to assemble that, but they often do not take responsibility for it. This sounds like a detail issue, but it is not, because it demands a role for business stakeholders that they seldom acknowledge.
Conclusion
The Agile movement took us away from big up-front plans, autocratic management, and start-stop projects. It shifted the focus from big initiatives to small teams, from big promises to incremental deliveries, and from handoffs between specialists to collaboration and self-sufficiency.
But it dismissed the importance of leadership, structure, forethought, and individual differences. It defined one-size-fits-all practices, often favoring some styles of work over others, and too often defined by frameworks or methodologies that were pushed in an all-or-nothing way by their most ardent advocates. And it did not even mention the importance of data and information, which are critical elements for success.
Agile 2 pivots Agile, informed by what has worked and what has not worked over the past twenty years. Agile 2 is not the last word on Agile, but the Agile 2 team hopes that it adds positively to Agile thinking, and helps to resolve many of the challenges with Agile transformation and helps organizations to attain true agility.
