If I had a penny for every minute I sat in a meeting where teams argued about what was and was not “Agile” I would be a gazillionaire by now. Sometimes, the most vocal and dominant voices are the least aware of the fundamentals of Agile. To many, Agile is a buzz word and does not mean more than what the English dictionary says…
Dictionary Agile
As a coach, this is the point where I usually suggest some form of Agile Learning – whether through training, self-study, book-clubs, discussion groups, etc. In organizations that are open to learning, the response is positive and we usually agree on some kind of path forward – brown bag presentations, book-clubs or Agile Workshops.
BARRIERS TO LEARNING:
In organizations that are learning averse, responses typically fall into three broad categories …
- LACK OF BUY-IN:
“Agile is just a passing fad. We are forced to use it because of pressure from leaders / customers.
I am going to do the bare minimum to stay out of trouble, but I’ll be darned if I waste time learning any more about it than I absolutely have to!”
- LACK OF SELF-AWARENESS:
“I am already an Agile expert, not sure there is anything else left for me to learn.”
I usually get this response from people who are clueless about the fundamentals of Agile – empiricism, the Agile Manifesto or the Agile Principles.
In some cases I point them towards the Scrum Open Assessment to validate their level of knowledge. However, there are times when some team members neither feel the need nor make the time to test their knowledge.
- LACK OF TIME / TRUST / DELEGATION:
“Maybe I could learn more about Agile. But there’s simply too much going on now. I’m too busy for Agile Training or self-study.
My team cannot survive if I am not fighting fires even for a couple of hours. There is no one else on the team who can do what I do.”
The lack of time for learning may be a variant of Lack of Self-Awareness. Or it could be a situation where a team-member overtly or covertly enjoys being the only person who can keep things going. Such people often struggle with trusting and delegating to team members so that show can go on, even if they are not available.
Learning Averse teams typically spend more time arguing about what is and what is not Agile. They spend more time and effort cleaning up messes created by lack of Agile Awareness, than they would have spent in creating a shared and accurate understanding of Agile.
Agile Awareness
So I have been deviously plotting how to covertly increase Agile Awareness and reduce needless waste in such teams. And I think I have come up with an idea – an Agile Trojan Horse that can be secretly let loose in meetings to increase Agile Awareness and whet the appetite for more learning.
I have no clue if this is going to work or not. We will just need to try it out, see what happens and inspect and adapt
So here is how it might work (or not)…
Pick a particularly contentious, hot-button decision that needs to be made on your team. This decisions should have 2-3 available options to choose from. A good candidate for this experiment would have been generating long, furious, inconclusive, debates about which of the option is “more Agile”. These discussions should have spilled across multiple long mail threads and long, mind-numbing meetings.
Some possible candidates…
“Why should we have actionable requirements before a sprint begins? Isn’t it un-Agile to spend time on requirements creation and review? Agile means we should just do it!”
“Why should we design or document our solution? Isn’t it Agile to spend time on documentation? I thought Agile meant that we should just do it!”
“Why do we have so many meetings? We know what everyone is working on. I thought Agile was supposed to make us faster not slower. These meetings are killing us. I thought Agile meant we should just do it!”
Agile Arguments
Now that we have created some TRANSPARENCY into lingering, time-consuming decisions, let us pick one upon which we will unleash our Agile Trojan horse. To illustrate this technique, let’s pick one of the examples we listed above…
“Why should we design or document our solution?
Isn’t it un-Agile to spend time on documentation?
I thought Agile meant that we should just do it!”
So here is how we introduce the Trojan – the next time you are part of this debate, ask the question…
“Which of these options might better enable empiricism?
Why do we think so?
How might we verify our assumption once we have made our decision?”
At this point, it is possible that some of the participants will ask two extremely pertinent questions…
“Who or what is an empiri-whatever?”
“How in the heck is it related to what we are talking about?”
Great! The Trojan Horse is working! This is where you respond…
Empiricism is a scientific approach to decision making based on what is happening in front of us. Empiricism is used in Empirical Process Control, which is the foundation for Agile Software Delivery.
Empiricism has three pillars…
- TRANSPARENCY: Empiricism requires transparency – a shared visibility into and a shared understanding of the current state of the product and process at all times. All team members must be able to see what is going on at any point in time.
- INSPECTION: Empiricism requires the ability to frequently inspect the product and process to identify deviations from the desired outcome.
- ADAPTATION: Empiricism requires that the team minimize undesirable variations in the product or process by frequently making adjustments as soon as they notice deviations from the desired outcome.
What if we put up a flip-chart if we are co-located, or an excel grid if we are remote, that helps us compare our available options from the perspective of empiricism. Let us capture the thoughts of each team member in the form of color coded post-it’s or colored cells as follows:
Getting Team Inputs
OK, so let’s apply it to our design documentation decision. We have three options to choose from
- OPTION A:NO DESIGN DOCUMENTATION AT ALL
- Only way to find out is to execute the code to see what it does
- Or to ask someone who has written or executed the code to find out how it works
- OPTION B:COMPLETE DESIGN DOCS BEFORE CODING
- Complete design documentation for all requirements, with the start of coding contingent upon receiving approvals and passing through Design Complete Gate
- OPTION C:WORKING CODE WITH JUST ENOUGH DESIGN DOCS
- Working Code with Just Enough Design Documentation to minimize waste…
- Catch invalid assumptions
- Increase team’s ability to understand and adapt the solution
- Increase team’s ability to document the solution for customers and to support the solution in production
- Working Code with Just Enough Design Documentation to minimize waste…
Applying the Empirical Trojan – Design Doc or Not?
There is nothing exotic in the table. It merely restores the focus on empiricism in Agile conversations, which can sometimes get lost in the absence of subtle guidance.
Applying the Agile Trojan
Try this out, share your thoughts and let’s continue the conversation.
Keep calm, and Scrum On!
Let’s Talk
Comments