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!
Author
Co-founder of People10, a 'total agile' software development and consulting company.