Note: The SmoothApps website will be down for maintenance on 21 Jan 2017 (Saturday) from 7:00 pm EST for 6 hours. Please contact us for further information.


The Agile Trojan Horse - Covert Appetizers for Agile Discovery: Part 1 - Empiricism

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

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.


In organizations that are learning averse, responses typically fall into three broad categories …


“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!”


“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.



“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

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

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…

  1. 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.
  2. INSPECTION: Empiricism requires the ability to frequently inspect the product and process to identify deviations from the desired outcome.
  3. 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

Getting Team Inputs


OK, so let’s apply it to our design documentation decision. We have three options to choose from

    • 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


    • Complete design documentation for all requirements, with the start of coding contingent upon receiving approvals and passing through Design Complete Gate


    • 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



Applying the EmpiricalTrojan - Design Doc or Not?

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

Applying the Agile Trojan


Try this out, share your thoughts and let’s continue the conversation.

Keep calm, and Scrum On!

-Ravi Verma,

The Org Whisperer


Let's Talk

Let’s Talk

About Ravi Verma

Ravi Verma is a Public Speaker, Agile Coach, Professional Scrum Trainer, Evidence Based Management Consultant and Blogger with a passion for helping teams recapture the magic of making I.T.

4 Comment(s)
  1. Margie Elliott January 9, 2015 at 8:36 am

    Please add me to your distribution. I look forward to your future publications/blogs.

  2. Steven Gordon February 4, 2015 at 6:28 pm

    In this case, “just the right amount of documentation” is a silly option. Everyone agrees with that idea – the original disagreement is over how much IS the right amount. Some people think no documentation is the right amount. Some people think detailed specs are the right amount.

    Is writing self-documenting code considered no documentation or just the right amount? Is BDD considered no documentation or just the right amount? Are UML diagrams considered full documentation or just the right amount? Are digital pictures of the team whiteboard considered no documentation or just the right amount?

    The answer is not the Trojan Horse, but the 5 Whys: Ask why have design documentation, and do not accept platitudes. Ask for specific reasons – who would use it for what and when? Ask about what would truly support those purposes and what it would take to really provide it?

    If the answers to these questions correspond to my 30+ years of experience, it will be that unless we keep the technical documentation correct and up-to-date, it will not actually serve any specific purposes. It will just be a CYA exercise that is a big waste of time and effort, decreases value delivered and increases the cost of change.

    Text and even diagrams are ambiguous. Documentation that cannot be verified automatically is likely to be wrong and even more certainly to become wrong as things change. The amount of review to make sure everybody reads them the same exact way is quite large. Does wrong documentation serve the needs, especially when it appears to be correct?

    I have found that digital pictures of the team whiteboard taken after every design session implies the correct lack of precision, is inexpensive, and still puts the appropriate pressure on writing expressive code and tests (because that is the only place to go when precise design issues have to be resolved in the future).

    • Ravi Verma February 5, 2015 at 2:51 pm

      Thanks for your insightful comments.

      We could integrate the 5 why’s approach with some of the elements in this blog…

      1. Why should we document? To provide transparency into how our product has been designed.

      2. Why? So we might inspect it

      3. Why? So we might adapt our product

      4. Why? Because the product in its current form is not meeting business needs

      5. Why?

      Thanks again for making the time to read the blog and share your perspective.


Leave a Reply

Your email address will not be published. Required fields are marked *

« Previous « How The Road to Agile Coaching Made Me A Gambling Addict! | THE TROJAN RETROSPECTIVE – FROM CRICKETS TO CONVERSATIONS! » Next »