Lacking definition
Lately I have found myself wondering how so many people can work so intensely with a subject like Agile without a common definition. Why does it matter you might ask and haven’t we got http://www.agilemanifesto.org/?
First of all very few people are able to remember the principles behind the manifesto
and though the manifest itself lays out the ground rules for Agile development they tell us very little about what Agile actually means.
The reason why is probably the very nature of a “Manifesto” which is something usually reserved for public declarations of a political nature, a statement of intentions used as a reaction to an existing situation and at least to me spells “change” and “revolution” of some kind. But what is left when the revolution has occurred?
The real issue here is that you will find people discussing Agile from very different perspectives. To some it means doing TDD and Pair Programming while others define themselves as Agile because they have frequent meetings with their customers. Others still use Agile as a term for the constant state of chaos they are in “It’s OK, it is just because we are Agile”.
The principles behind the Agile Manifesto
When reading the 12 principles behind the Agile Manifesto I find they bring me closer to a useful definition of Agile but still they have some inherent problems. There are too many of them and they are too long (182 words in total) for my brain to remember. There are redundant elements (“…early and continuous delivery…”, “Deliver working software frequently”) and some of them seem too inflexible (“Business people and developers must work together daily throughout the project”). With the arrival of continuous deployment at least one of them is outdated or at least too specific (“…from a couple of weeks to a couple of months”)
My first thought was that ten years after the Agile Manifesto was written a large amount of academic research must have dealt with the problem and produced an adequate definition. The best one I found was from the article by Kieran Conboy, 2009:
- The continual readiness of an ISD method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change while contributing to perceived customer value (economy, quality, and simplicity), through its collective components and relationships with its environment.
While serving as a good academic definition and probably something I would have found very useful back at university it doesn’t quite help me in the pursuit of a short clear definition I can use as a daily reminder to keep me on the right track, as well as a base when discussing Agile Software development with others.
My own definition of Agile in 9 bullets
Puzzling with the problem for some month and changing the exact wording a number of times I have arrived at the following 9 bullets which currently serves as my own definition of Agile and the one I use when discussing the Agile framework with teams and business partners I am involved with:
- Satisfy the Customer through Working Software
- Deliver Early and Often
- Create and Embrace Change
- Focus on Quality
- Create Transparency through Visualization
- Endorse Sustainable Pace
- Bring People Closer Together
- Trust in People and Decentralize Authority
- Improve Continuously focusing on Simplicity
While most of them are easy to map to elements in the existing principles from the Agile Manifesto a few deserves a comment to get the meaning right (probably a sign that they could be better formulated):.
4. Focus on Quality
Quality is a key enabler of early and often delivery as well as sustainable pace. Quality problems create distrust and slows down the development speed over time, when it becomes too hard to maintain the system and integrate new features. TDD, code review, refactoring, continuous integration, pair programming, accept criteria and early feedback have all proven to be excellent tools to achieve high quality releases.
5. Create Transparency through Visualization
Though visualization of work is not part of the principles behind the Agile Manifesto or the Manifesto itself it has proven to be a core value of Agile Development and a key enabler of transparency. By visualizing the workflow everybody involved in the project knows exactly what is going on and nothing is hidden. This gives everybody a clear picture of the project’s current status. Whiteboards for collocated teams and online tools for distributed projects have proven to be a key enabler for visualization of work and thereby transparency and trust in the organization. A real problem however is that many Agile projects only use visualization for internal transparency and consciously or unconsciously keep this information from the rest of the organization and the customer. In many cases it is simply a matter of sticking to old ways and the game of “Project Poker” while others simply have not recognized the benefit of openness and total transparency.
7. Bring People Closer Together
Agile is all about collaboration, inside the development team, between the development team and the business, end users etc. Bringing people as close together as possible is the most effective way of sharing information which is what software development is all about. In some cases this might be using the best online tools available to facilitate communication in a distributed environment while other projects are fortunate enough to have the business as well as the development team in the same building. The key principle is to bring people as close together as possible to avoid unnecessary management overhead and handovers.
9. Improve Continuously Focusing on Simplicity
Reflecting on our current situation to do things a little better than we did yesterday/last deploy/last iteration/last release is a core principle in Agile. Before the Agile Manifesto was written in 2001 Agile methods were referred to as “Lightweight methods”. One of the key elements was keeping management, process and technical overhead low to ensure that as much time as possible was used for value creation. When continuously improving our system and process we should always do it with this in mind since keeping things simple allow us to avoid a complexity few of us are able to handle anyway. Complexity, both technical and process, seems to creep in under the radar whenever we are not paying attention and therefore we need to let our continuous improvement initiatives be guided by the will to constantly reduce it to a level where we are keeping our heads above the water.
Using the 9 bullets
I try to make these 9 bullets as visual as I can in my workspace, posting it on whiteboards, walls and doors… to make it serve as a constant reminder to myself and my colleagues in our daily work. As you will probably have notice the 9 bullets are almost practice free which is on purpose. To me Agile is more of a general set of principles I try to follow to enable better ROI (Return On Investment) for my customers, than a set of specific practices I need to follow. Pair Programming and TDD are very useful tools to enable high quality software which again is necessary to deliver often, but while the need for this might be more apparent in Agile projects I think they are as useful with a waterfall approach. User Stories are a fantastic way of bringing the development team and business side “closer together” and making them focus on customer value, but I will never consider it Agile in itself.
Stating that there really are no “Agile practices” have gotten me into some heated discussions from time to time, and though I do understand where the arguments are coming from (after all many of these practices have evolved in the Agile community) I am still not convinced that they are not just tools that should be used according to the specific context. But feel free to prove me wrong.
Explaining why
The next natural step becomes gaining a more in-depth understanding of why Agile principles help us deliver better ROI for our customers. My experience is that many companies follow Agile principles like a checklist without really understanding why they work and are simply trying to copy other people’s successes. While doing ok for a while they often end up making the wrong decisions at critical moments when they are faced with difficulty and consequently revert to former practices.
Understanding “why” might therefore be even more important than the definition itself. In this pursuit I have found the principles of Lean Product Development to be extraordinary helpful but that is a subject for another blogpost and another day. 