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 document— that 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.”