Agile Mastery –
Doing, Understanding and Being
by Alan S. Koch, Certified ITIL Expert, PMP, CSM, CTM
It is not unusual for organizations to struggle with the transition from a traditional project approach to an Agile approach. Agile methods appear deceptively simple, but present real challenges in many contexts.
Chuck Cobb started a very interesting discussion about Levels of Mastery in Agile on the LinkedIn group Agile Project Management. (Have you joined that group yet?) He posits three levels of mastery:
- Practices (Doing)
- Principles (Understanding)
- Values (Being)
This is a useful way to think about your project teams’ use of Agile techniques. Indeed, I have observed that the teams who struggle with Agility tend to be singularly focused on the doing, while the teams that epitomize Agile Clockwork don’t merely do Agile – they are Agile!
Let’s take a look at each of these levels of mastery so we can understand where our teams are on this scale, and what steps we can take to move up.
1. Practices (Doing)
Every Agile method defines practices that we should follow. For example, Scrum tells us to identify a Scrum Master and a Product Owner, to hold Daily Scrums, to estimate in Story Points, and more. And Extreme Programming tells us to do Continuous Integration, to do Pair Programming, to Refactor regularly, to practice Test-Driven Development, and more.
Adopting these practices is the obvious starting point for beginning to use an Agile approach. But there is serious risk of implementing those Agile practices in ways that are counterproductive. When you have not understood the Agile Principles (Mastery Level 2) and embraced the Agile Values (Mastery Level 3), your implementation of the practices can fall flat.
Examples of Agile Practices Falling Flat
Many teams struggle with keeping their Daily Scrum to 15 minutes or less. They either waste a lot of time in 30-60 minute meetings every day, or they fall back to meeting less often than daily. With a good understanding of Agile Principles and Values, they could do a true Scrum each day, instead of trying to hold their normal weekly status meeting every day.
In some cases, the Project Manager or Business Analyst creates all of the User Stories for the team, following the traditional pattern of throwing the requirements and/or plans over the wall to the developers. With a good understanding of Agile Principles and Values, they would know that both the customer and the developers need to be intimately involved in the requirements and planning activities.
Some teams consistently reach the end of their Sprints with testing unfinished. Performing a mini-waterfall within each sprint shows a misunderstanding of key Agile principles.
2. Principles (Understanding)
The 12 Agile Principles provide a good basis for interpreting every Agile Practice. They can lead you toward the level of understanding that is needed to avoid the pitfalls mentioned above.
For example, the first Principle begins with, “Our highest priority is to satisfy the customer…”. That single phrase should inform and define how we implement each and every practice we undertake on our Agile projects. It points to a relationship between developer and customer that is unique to the Agile approach and that results in most Agile methods including a customer as a full member of the team.
Another principle says, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This principle underpins a large number of Agile practices and results in vast differences between Agile projects’ documentation and that of more traditional approaches.
Another principle takes that one even further by stating that everyone on the project “must work together daily throughout the project.” Separation of duties? Silos of activities? Hand-offs? No thanks!
The principle that speaks to the efficacy of “self-organizing teams” clarifies many Agile practices. The role of “Manager” is transformed when an organization and every team in it understand this principle!
And one principle states, “Simplicity … is essential” and defines simplicity as, “the art of maximizing the amount of work not done”. ‘Nuff said!
Everyone who is involved with Agile projects should take it upon themselves to internalize and fully understand the 12 Agile Principles. That will enable them to implementing the Agile practices as they were intended.
3. Values (Being)
The Agile Manifesto articulates the 4 Agile Value statements. Being Agile is a matter of internalizing and living by these values, because when you do, the Doing and the Understanding flow automatically.
“We have come to value individuals and interactions over processes and tools.” The Agile Practices (Mastery Level 1) are all about processes and tools. You can’t talk about a new way of doing things without discussing processes and tools. But this value statement makes it clear that the Agile Practices are not the point! The Practices have been created to help every Agile team member value every other individual on the project and interact with them effectively. Any implementation of the Practices that does not have this as its primary effect is wrong-headed.
“We have come to value working software over comprehensive documentation.” Agile projects produce documentation, but it is quite different (and leaner) than documentation from traditional projects. This value statement gets to why those differences show up. Someone who has embraced the Agile Values only wants to spend time on documentation to the extent that it is helpful in doing what the project is mainly about – building good, proper, correct working software.
“We have come to value customer collaboration over contract negotiation.” All human relationships are built upon norms, rules and agreements. Whether they are formally written contracts or mere understandings among players, they help us to navigate the challenges of interpersonal interactions. This value statement focuses our attention on one particular player (the Agile team’s customer) and the most critical norm (collaboration – that is, working together). Embracing this value means that we rank all opportunities for working shoulder-to-shoulder with our customer as more important than any other standard or expectation.
“We have come to value responding to change over following a plan.” Why do things change during projects? It is because someone learned something they did not know before. The customers might learn more about their needs. The developers might learn more about their technology. Management might learn more about market imperatives. Our plan was made without the benefit of the knowledge that was just gained, so it is clearly inferior to any new way forward that we could forge now. Embracing this value means embracing learning and always making the best use of new knowledge, even if it means changing prior plans.
Mastery is Not a Sequential Journey
Chuck Cobb’s three levels of Mastery may look like a sequential journey we should take; starting with Agile Practices (the doing), then moving on to Agile Principles (the understanding), and culminating with Agile values (the being). But nothing could be further from the truth.
If we are to adopt Agile methods and actually experience the benefits they promise, we must work at all three levels from day one. We must learn about the Agile Values and their implications. We must learn about the 12 Principles and why each is important. And that will enable us to implement the Agile Practices in a way that is consistent with the Values and Principles.
Of course, Mastery will indeed come progressively:
- Doing Agile Practices will be the easiest for us to master – as long as they that have been implemented with the 12 Principles and Agile Values in mind.
- Understanding Agile Principles will come with time and experience as we are engaged in that doing.
- And Being Agile is the state we will achieve when the Doing and the Understanding become reflexive, and we don’t have to consciously focus on them any more.
But our journey begins by focusing on all three.
Doing, Understanding and Being
Nicely written article. Although software seems to be the primary focus of Agile, there are references available showing how it may apply to other types of projects. In each case, it is important to tailor Agile to fit your needs while keeping those core principles in mind.
Thank you for the complement, Walter!
And you are absolutely right, any activity can be done in an Agile way. While the Agile Values and Principles can be adapted to any discipline with a few minor wording changes, Agile Practices for a discipline other that software would require some creativity and trial and error to work out.
But indeed it can be done. I am a consultant, and I approach every consulting engagement as an Agile project. No more big-bang proposals with detailed plans and deliverables! Every engagement is a collaboration that is focused on the number one Agile Principle, “Our highest priority is to satisfy the customer though early and continuous delivery of {value}.”
Have fun. Be Agile!
ask