In the last post we introduced the Agile approach and gave a brief history with a current status, which is pretty messy. How do we navigate this messy scene? The answer (or at least a big part of it) lies in understanding the difference between “Being Agile” and “Doing Agile”. And that’s what we examine in this post.
Agile is simple, except for all the tricky bits
A key attribute of the Agile Manifesto is that its values and principles are all expressed as heuristics: simply-phrased guidelines that help solve problems rapidly, in the right circumstances.
At one level, this approach is inspired: heuristics inform the team members and the team works out the practical detail, bound together by the principles of social cohesion and known best practices. This is how an agile team works.
In practice, however, this creates numerous issues:
- Many people find these confusing, high-level and lacking detail. The problem starts when “more detail” becomes “more prescriptive detail” instead of “finer-grained understanding”.
- An agile novice can confuse an expert’s guidance to “do this step, practice or technique”, with “do this and only this, always”.
- Rules that tell people to be self-reflective and to promote process improvement are highly ineffective.
- Many people are just more comfortable with prescriptive instructions because it sets clear accountability boundaries. “I did what you said. Don’t blame me if it didn’t work”.
Ultimately, agile teams can too easily develop a “this is how we do things around here” set of processes. Such teams extract only the codified parts of agile literature and training, and align around practices that they perform religiously, or worse, water down these tools and/or introduce processes from traditional project structures.
In this way, they achieve the status of “OINA”, which is short for “Agile in Name Only” and find that they are “doing agile” processes, but it’s not improving the result.
Why is this so?
Understanding Agile - without all the detail
Firstly, the best agile methodologies are simple by design. Consider Jeff Sutherland’s description of Scrum:
”“… not a development method or a formal process, rather it is a compression algorithm for worldwide best practices observed in over 50 years of software development. The Scrum framework is simple to implement and automatically unpacks and encourages a software development team to deploy best practices …”
Jeff SutherlandThe Scrum Papers: Nut, Bolts, and Origins of an Agile Framework
There’s a lot that goes into the apparently very simple Scrum framework. All these best practice patterns and practices are compressed into this beautifully simple “shape”.
The “shape” of Scrum is easy to understand and should be easy to do. But unpacking the patterns and practices of Scrum generates a lot of detail very quickly and expand into many domains beyond the areas of expertise or interest of the intended users, e.g. Psychology, Sociology, Anthropology to name a few.
Thinking of an agile methodology in this way is very useful, because we realise that these frameworks tap into something very powerful and generic: the natural ways in which people work together to solve problems.
It is for this reason that teams adopting an agile approach understand both the explicit process codification of the methodology as well as the underlying principles.
Agile projects are driven by the interactions between team members and other stakeholders: this fundamental aspect of agility is the most documented but probably the least understood aspect of the whole agile approach.
Being Agile – a Mindset not a Prescription
To “be agile” is to start with a high-level “mindset” and work through operational details as they work towards their goals. This relationship between the Manifesto and the “real world” context is shown below.
Each artefact of any given methodology is a tool to aid in that process; but it is only one instance of any number of tools that could also be applied to the same function.
Agile has been designed to be adaptive: to change and be changed by each team in order to respond to each team’s unique situation. Agile adaptiveness works at two levels:
- Firstly, adapting the in-progress development in response to feedback from the user stakeholders about a delivered increment of capability; and
- Secondly, adapting team processes to enhance performance by reflecting on past activities and identifying areas of improvement.
So the “agile mindset” for practitioners is the mindset that is willing to be guided by heuristics and to adapt at these two levels.
There’s an assumption that nobody gets it right first time but that by adaptive response the team will continually and sustainably improve both the developed outcomes and the team itself.
It’s very common to see questions put to well-known and reputable agile experts on very fine points of practice and to have the answer come back “here are some thoughts … but do what works for your team”.
In order to successfully guide an agile implantation, you need to have a solid understanding of all four of these aspects, not just the methodology, plus a clear understanding of the knowledge and practices that underpin them
The mindset is more important than the methodology.
So, how does this all help us manage Open Networking projects better?
We’ll tie this all up in our next post.
Stay tuned.
