Agile has been an enigma to a lot of people except for the geeks and evangelists.. And even they all had their own interpretation of ‘what is agile’.
Some say it is about ‘teamwork’. Some people swear by its technical practices that bring about the best in class product quality. Some talk about how the features are managed in chunks to bring about maximum business value and quick delivery.. In the end, the question, is ‘is it about being fast, is it about bringing high quality, is it about better managing client’s needs, or is it about building a high performing motivated team” ?
Every agile practitioner has a different answer. Sounds a bit like the proverbial blind men and the elephant, isn’t it?
Product quality, motivated teams, happy client, fast-paced delivery – that all sound like a lot to achieve… The Utopia? I swear it can be achieved!
One of the main reasons why people get confused about Agile is because it is spoken in many dialects like Scrum, XP, FDD, Kanban … And most of the time, the people who speak these dialects forget to mention how all these can in fact, co-exist beautifully.
I remember once when I attended a scrum training (mainly out of curiosity) few years ago, the famous trainer refused to even address basic questions from the participants saying “that term doesn’t belong in scum!” Needless to say, there was lot of confused people who came out of the session including yours truly. It may not always be easy for a newbie to connect the dots.
It is only when I started practicing agile ( I prefer to go by ‘Agile’ -I wouldn’t use the dialects here), and literally inventing practical agile solutions to every day issues faced by our technology teams that you sort of put all the jigsaw pieces together and realize that, it all fits in perfectly well in the big picture!
In any software development scenario, the distinct sets of questions we try to answer are: (note they have been grouped into four sets)
- How do you achieve best product quality?
- Did we not have it before, why is the need to re-invent the definition of product quality?
- What was wrong with what we have been doing so far?
- How much engineering really is there in software engineering?
- How can IT become true enablers to business rather than a bottleneck?
- How can we work closely with business where we understand each other?
- How do we prioritize what is most important to business and commit on that?
- Can IT and business speak the same language?
- How do we re-invent Project management in IT?
- What are those PM practices that enable a self-running team?
- What would be the role of a project manager in an agile team?
- What all behavioral practices need to be inculcated for the team to be really agile?
- Are agile teams a bunch of cowboys?
- Can we see and measure the progress of agile deliveries?
- Can agile be done at an enterprise level, or is it only confined to small teams and small companies?
Well, of these questions are deep enough be answered through an elaborate white paper…. what I am trying to do here is to attempt to uncomplicated agile in a simple way so that it can be understood equally by all stakeholders and they are able to unfold the blind and see the ‘elephant’ for what it really is J
If I were to go back to the set of questions above, I would categorize them into “Four Quadrants”:
- Ensuring Product Quality ( through engineering practices)
- Managing the Client/Business needs ( through product Management practices)
- Building self-running motivated teams ( through redefining project management practices)
- Ensuring performance management and enterprise-wide scalability (through Agile PMO practices)
While this could very well represent the Four Quadrants© of enterprise agile implementation, are we missing anything ? What could be the other enabling factors ?
There are three other important aspects to have a real success with Agile. They are :
- Agile Infrastructure
- Human Capital development
- Thought leadership
Which brings me to the below ‘Total Agility’ model:
This would be our interpretation of ‘Total Agility’, or rather how the elephant really looks like…
It is easier said than done. When it comes to execution, each of these blocks are equally important and requires specific attention. That is exactly the reason why many transformations fail. We tend to focus only on very few topics (normally easy rituals like standup meetings, poker planning etc). The tough ones are left for later, and the important engineering practices get ignored. Another common mistake is the inability or reluctance to measure. Anyway, will get into pitfalls of agile implementation at a later stage.
If we were to drill down into each of these blocks, we end up with specific value-added practices as shown below. Note the importance of CRM, Infrastructure and Human capital development in the overall framework. Also note how thought leadership and Agile PMO becomes important pillars in the success of the agile delivery.
Needless to say, each of these practices requires skills and expertise across all the stakeholders.
Feel free to share your valuable thoughts.. Adios!
It’s really superb visualization of TAVA- Total Agile Value Addition…
I like the detailed diagram at the bottom. It wasnt until I saw it that I could tell the rest of it wasnt neglecting design/code quality, and making the artifacts the artifacts themselves be easy to change.
But until I saw that, nothing in your earlier “quadrants” pictures gave me the impression that practices like Refactoring, TDD, DDD were included in your quadrants.
It looked like integration, build, and test where being emphasized but that code/design quality (and its flip-side, technical debt) were being neglected. I would suggest modifying your description of your quadrants so that its clear this is not the case.
Thanks for detailed the feedback, Brad.
The Quadrant 1 (top right) is focused only on engineering practices and software quality. We are big advocates of TDD, refactoring, BDD, DDD, Continuous integration, continuous deploys, design and coding best practices and eliminating technical debts. We practice the same for all projects and closely monitor the debt indicators on a daily basis.
I will look into it, as we definitely wouldnt want the core practices to be misunderstood 🙂
As a product owner, I am going to assume that the area of Feasibility assessment is where the user needs get compared to the business needs and prioritization occurs. Without getting into a huge discussion of who the customer is, or who constitutes a user, a key role the Product Owner needs to fill is that of the arbiter of what makes sense for the business, and how best to match that with user needs.
I love the framework and I am sure it will spark more discussion, but it does provide an excellent framework to use as a starting point. As you describe, part of being Agile is to address your needs on a daily basis, and figure out how to make this work in your situation. Having that agility will remain key to the success of any given instance of Agile practice.
Thanks for sharing.
Thanks for Good article.
wondering where in this framework Lean software dev and Kanban practices will fit in? maybe those will be one layer up and work as trigger for agility.
Kanban would fit in the Quadrant 3 (Vusual management practices) and Lean software development practices obviously would apread across the quadrants 1,2,3 depending on which practice we are talking about…