Essence and Problem Solving Blog

January 30, 2017

Avoiding two common software project troubled paths by “being agile” rather than “doing agile”

This week I want to talk to you about two common troubled project paths, and give you some simple tips to avoid both.

The first troubled path is putting too much effort into documentation. When you catch your project heading down this path stop and ask:

What is the driving need behind our documentation requirement?

Often there are two driving needs. First, your customer or senior management may be looking for some kind of assurance that the software team is doing the right things.  The second reason is to help users and maintainers once the software is deployed.

Unfortunately, traditional documentation isn’t very good at meeting either of these needs. It isn’t good at helping users and software maintainers because often it isn’t trusted to be kept up to date after delivery.  And, historically, documentation hasn’t been very useful to software teams at helping them create high quality software.

The second common trouble path is reacting to the first troubled path by declaring “we’re agile!” –and throwing out the essentials for high quality software along with the documentation.

Now, today, it is a fact that we are seeing more and more organizations trying to increase agility, but many of these same organizations are struggling to figure out how to “become agile” without jeopardizing essentials for success.  And in a moment I am going to explain more what I mean by that phrase “become agile” because I may not mean what you think.

But first, a little background. You may know that in previous blogs and publications I have talked about Essence.  Essence is a framework that captures essentials for high quality software in a simple way—and most important to today’s topic—those essentials are independent of the degree of agility you are driving for with your teams. Essence also includes a simple language to express practices on top of the essentials to give guidance to your teams.

Today I want to talk to you about three simple parts of an Essence practice and how these parts can help your teams find their right level of agility while not jeopardizing essentials for success and help you avoid both common troubled paths.

Those three parts are:

  • the purpose–or goal– of the practice;
  • the activities conducted as part of the practice;
  • the work products produced.

Activities in an Essence practice are what people actually do when carrying out a practice.  They can vary greatly in prescriptiveness. In other words, you can provide activities in your practice that just specify “what” people must do or you can be much more prescriptive specifying in detail the “how to” side of your practice activities.  Similarly, the degree of detail specified in a work product can vary greatly.

Now, let’s look at some examples from my “Upside Down” book.

In Story Two in Part I of my book you learn about a team that came up with an innovative approach to achieve the goal of their sprint review practice when they learned a key stakeholder could not attend the meeting. They actual got on an airplane and went to the client’s site to engage that customer and get their feedback.

The point I want to emphasize here is that the real goal of the sprint review practice wasn’t holding a meeting called a sprint review which is what too many teams get overly focused on when they blindly zero-in on following specified “how to” activities in highly prescriptive practices.

Stated differently, what we are seeing too often is teams falling into just “going through the motions” of prescribed activities. Other authors have referred to this as the difference between “being agile” and “doing agile”.   And, to be honest, I really didn’t understand this difference until I observed it in one of my own client organizations.

What you learn from that story I just referred to is how a team stays focused on the real goal and figures out a creative way to achieve that goal which is gaining the buy-in of key stakeholders—not holding a meeting called a sprint review.

In that same story you learn about a challenge the team faces with a tester having difficulty communicating with developers.  In this case, the team came up with an improved testing practice that included the activity of developers placing a note in the ticket to the tester.  The note in a ticket could be viewed as an example of a very lite work product—not a heavy documentthat helped the communication problem.

In this story it is important to understand that the goal of the testing practice wasn’t to create a note in a ticket.   The real goal was improving communication between developers and a tester. Placing a note in a ticket was just one possible activity that could help the team achieve the real goal of the practice.  And in this story you learn how the team understood that in certain situations if it made more sense to just get up from their workstation and go over and talk directly to the tester that was an option they could and should use.  This is a perfect example of “being agile” rather than “doing agile”.

What you learn from these stories is that where teams often get in trouble is when they start confusing the activity they conduct as part of a practice, or the work product they produce with the goal.  One simple way to help yourself is to keep asking yourself are we are getting too much into “doing agile” –  or just going through the motions of our rituals, such as sprint reviews even when the key people can’t attend?

Or are we “being agile” by keeping focused on the real goal and coming up with innovative solutions when necessary, such as finding creative ways to engage our stakeholders when they can’t make it to our sprint reviews, and getting up from our workstations and walking over to talk to a tester when their might be some risk of misunderstanding.

One caution here, if you decide to allow more choices in your team’s practice activities by making them less prescriptive– it is also highly encouraged that you provide clear limits to the activities, and coaching in these limits, so the team does not fall into chaos.

Always keep in mind that activities and work products are important parts of a practice, but they should never be confused with the goal of a practice.

When we see this confusion starting to happen it is often a sign that an organization is falling too much into the “doing agile.”

Use these simple practice tips when you are developing your practices and coaching your teams, and you might just find it easier than you think to avoid both common troubled project paths and find your right level of “being agile.”


  1. Nicely put. In Essence, Agile as well as CMMI, activities (or subpractices as they are known in CMMI) and work products are but a means to an end (the goal).

    Comment by Winifred Menezes — January 30, 2017 @ 9:46 pm | Reply

    • Thanks Winifred. What you say I have found no one (or very few) seem to disagree with. But in my experience, in far too many organizations, this simple, seemingly accepted idea, gets turned “upside down” when implemented. .

      Comment by pemcmahon — February 1, 2017 @ 12:30 am | Reply

  2. Nice blog clearly showing difference between “Being agile: and “Doing agile” with good examples.

    Of late I have been spending a lot of time in my work as an Agile & WoW consultant going deeper behind the activities (actions, reactions, and interactions) to look at the decisions we make explicitly or implicitly. This further leads to understanding our opinions (assumptions, beliefs, and values) along with the emotions we experience as we are going through our activities. When we really understand our opinions and learn how to change them, then only we can effectively move from “Doing agile” to “Being agile”.

    Details can be seen at

    Comment by Prabhakar Karve — January 31, 2017 @ 5:21 am | Reply

  3. I agree the focus needs to be on the goal (s) and agile is doing whatever necessary to achieve them

    Comment by tom gilb — January 31, 2017 @ 12:42 pm | Reply

    • Thanks Tom. While I agree the thinking behind agile is correct related to “doing whatever necessary to achieve the goal(s).” Today, unfortunately, I am finding too may consultants/coaches who are stuck in the “doing agile’ mentality, such as holding meetings called sprint reviews, and therefore losing sight of the goal despite their best intent.

      Comment by pemcmahon — February 1, 2017 @ 12:38 am | Reply

  4. Now you can get on to the important goal of ‘creating agile.’ Doing agile does not result in an agile system. Selecting the wrong trajectory of goals does not result in agile system. Creating agile entails playing the non-deterministic opponent without losing.

    Comment by jring281 — February 2, 2017 @ 5:12 pm | Reply

    • I had not heard the phrase “creating agile” before receiving this comment to my blog. I had to read the comment multiple times before the meaning sunk in. But now I think I get the point and agree with it. It is yet another important dimension required to really build high quality software. From the Essence framework perspective “creating agile” gets at progressing the Software System alpha whereas “being agile” and “doing agile” focus more on progressing and keeping healthy the Way of Working alpha. Thanks for the insightful comment. Do you have any further references you can provide on “creating agile”?

      Comment by pemcmahon — February 3, 2017 @ 4:57 pm | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: