In the last post we gave an overview of the Open Network Integration domain. In this post we start by doing a deep-dive into Agile methods of solution development.
Agile is a large topic, so we’ll split this into three parts.
- Introduction (this post)
- The difference between “Being” and “Doing” (next post)
- Making Open Networks Projects Agile (following post)
Introduction
Agile has become very popular and mainstream in the last 5-10 years or so; there would be few organisations with dedicated IT departments who have not at least experimented with it in the last few years.
Properly adopted, the use of Agile strategies can pay big dividends in terms of cost, speed and quality of Open Network Solutions, but only if it is used appropriately, and well.
There is a lot of “hype” that can generate misunderstanding and mis-application. Successfully implementing solutions with Agile is not as simple as just adopting a methodology, e.g. Scrum, and saying “we’re agile”. There’s a lot more to being agile than following a process.
The mixed paradigm world of Open Networking means that certain aspects of the implementation process need to be different from a typical agile project.
Origins of Agile
When the 17 folks at Snowbird Utah composed the Agile Manifesto in 2001, they weren’t just codifying a new approach to software development. They were also capturing emergent aspects of how people in the 20th Century were thinking and going about solving problems.
The Manifesto did not sprout in one weekend gathering. As well as the extensive prior experience and experimentation of its creators, the seeds of agile were sown well before the Manifesto was signed.
As an example, take “Scrum”, probably the most mainstream agile methodology. The concept of a “Scrum” was coined in the 1980’s by Takeuchi and Nonaka who were inventing new models of work organisation at Toyota other places. “Scrum” as a software development methodology was formalised in the 1990’s by Jeff Sutherland, Ken Schwaber and others, and in parallel with other methodologies like XP (eXtreme Programming).
This emergent thinking was much more focused on the dynamics of how people worked together to solve problems, as opposed to the more rigid and static rules-based mechanisms used previously. By enabling a group of workers to control how work got done, this new approach was better able to respond to the accelerating business and community cycles of the time.
Not only did the group work cohesively on a complex task, but the group constantly reflected on their performance and identified how to adapt and improve over time. Toyota considered that the ability of their system to change and adapt as they learned and new circumstances arose was just as important as the system as it may have existed at any given point in time.
These two aspects are the deeply intertwined and inseparable foundations of agile practice.
Current State: Very Messy
Since 2001, the knowledge and use of agile has increased globally. Jeff Sutherland did very well to convince US businesses that “twice the work at half the price” was a very feasible objective with Scrum.
Many businesses have adopted agile approaches, with varying levels of commitment and success. There are a number of mature high-quality options when it comes to methodology frameworks, and many sources of high-quality support and information on practice.
However, all is not perfect in the agile world: we’ve gone from the first value in the Manifesto being “Individuals and interactions over processes and tools” to a market that endlessly promotes tools and processes. There are many implementations that have not paid off as well as Scrum’s compelling but simple slogan would claim.
Over time, the principles and values of the Agile Manifesto and its underlying theories have been eroded by the tendency to make principles more “rule-based” and prescriptive. In many projects, adherence to agile ceremony and process is more strictly policed than in traditional rule-based methodologies; in others, important aspects are ignored or treated as empty ritual. We will dive into this issue in the next post.
Many practitioners, including a number of original Manifesto authors, lament that agile practices have become too over-adorned and that we have lost the simplicity and effectiveness of the original intent. In particular, Ron Jeffries refers to “Dark Scrum” as the result of impatient and poorly-supported Scrum implementations that don’t allow self-organisation to emerge. Martin Fowler coined the term “Agile Industrial Complex” to describe the collection of consultants, experts and managers who try to assert “best practice” rather than letting teams decide how best to do their work.
These issues cannot all be blamed on the “Agile Industrial Complex”: practitioners in user organisations also have to own some responsibility.
Conclusion
Agile is a very broad topic and is subject to much hype and misinformation. It is important to avoid the “Agile Industrial Complex” and other disenabling practices. Adopting an approach and reducing it to rules and processes will create more disruption than productivity.
The important thing is to focus on “being agile” not just following an agile methodology.
We’ll cover this in the next post.
Stay Tuned.
