Undone Work

One of the principles underlying the agile manifesto states “Simplicity. The art of maximizing the work undone — is essential“.

This seems pretty straight-forward in terms of wrapping one’s head around things as in software so many of us are very familiar with the general KISS principle.

However, with many teams I have worked with I see a very familiar pattern emerge at times …

Once the team starts the sprint, the developers spread across the tasks on multiple stories (based on skill level or dependencies or any number of reasons). They are working away on the small pieces across multiple features and feel confident in their commitment. Then the clock ticks by …

Then somewhere during the sprint (let’s hope they are coached in the “first responsible moment” approach) they realize that something was much harder than they imagine or someone was sick or generally something derailed their optimistic view of sprint completion. So they take stock of what they have and determine they are going to complete 3 of 6 features but indicate “the others are about 40% complete though so it will take us less time if they are moved forward” or in a worse case scenario they have 6 partial features, maybe not tested or unit tested or whatever …

Sounds familiar to anyone? The value that I referenced above applies to this as well. This is where the “art of maximizing the work undone” also comes into play. All of that partial work (even though it was probably great effort) created absolutely NO value for the end stakeholder.

Let’s use a real world example …

You need to get a few items completed for yourself and your family for an upcoming event. The items are:

  1. Mail 100 letters
  2. Wash all of the windows at my house
  3. Cut the grass
  4. Feed the dog

So you take these jobs and decompose them into tasks:

Mail Letters:

  • Get envelopes
  • Get stamps
  • Fold letters
  • Put letters into envelopes
  • Take to post office and place into mail

Wash Windows:

  • Get cleaning supplies
  • Treat each window
  • Wipe each window

Cut Grass:

  • Get gas for lawnmower
  • Start lawnmower and cut grass
  • Do edging
  • Blow grass clippings off pavement

Feed Dog:

  • Get dog food
  • Put food in bowl
  • Ensure water is in water dish
  • Place on floor for dog to eat and drink

In the course of working on your commitment, you determine that you will spread yourself across all tasks so you do the following:

  1. Fold all the envelopes
  2. Go to the store and get cleaning supplies
  3. Pickup some dog food
  4. Fill your gas can with gas
  5. Get your stamps
  6. Fill the lawnmower
  7. Stuff the envelopes

Unfortunately, you run out of time to get things done (based on unforeseen situations), which can often happen.

So what have you actually accomplished in terms of end value of your commitment?

Let’s look at it from that perspective. You have:

  1. A full lawnmower but the grass is still not mowed
  2.  Letters in envelopes that sit not mailed
  3. Plenty of cleaning supplies but dirty windows
  4. A dog with a bag full of food but very hungry

So what if you had:

  1. Gotten the stamps and envelopes and ensured the mail got sent.
  2. Went to the store, got dog food and fed your dog
  3. Got cleaning supplies and cleaned the windows.

If you still ran out of time, what value have you received? You completed 3 of the four of your tasks leaving only the lawn undone. You maximized the amount of work by moving the tasks to completed before moving on. You minimized the undone work through focus.

How does this apply to teams?

In a sprint, teams often spread out across stories to the individual tasks and when completing all they can complete for reasons such as:

  1. Their skill level does not allow them to pull more advanced tasks
  2. All other tasks are being worked by other team members

Most, then move on to pull additional tasks in another story that they can work on as this seems the most logical thing to do to continue to provide value. But what if I said that we should not do this? What if I said that we should focus on applying our energy to getting items “in flight” to a state of done? Would this seem counter-intuitive? Or, if looking at it from the lens of completed value, would it make sense?

Many people think that people should move on to complete as much work as possible and not become “idle” but I firmly believe that given the focus of completing stories, anyone not “doing” can still find a way to become valuable. What if instead of moving on they did the following things:

  1. Decomposed the next story or stories into tasks (as we could focus on the things we are working on and not try and decompose everything at once)
  2. Assisted in testing, maybe writing scripts or unit tests for the code under development or helping to write test cases
  3. Performed the “just needed” level of documentation for the project
  4. I firmly believe that just like the old adage “if you buy a bigger house, you will find things to fill it” applies to teams. If they are without direct domain work, there are always items to which they can apply themselves to realize the end value.

Why I keep getting told this does not work …

I am often told by teams that this approach does not work as stories have dependencies, it slows them down overall as everyone is “not busy” or creates more refactoring (which is a given in iterative development).

However, in each conversation I have about this, no one is actually willing to try it and see if it actually works or not. Many seemed convinced it will not work.

I speculate that decomposing the work needed and performing this decomposition effort “just in time” coupled with the focus of work can result in a much better end value proposition from a commitment. If a backlog is truly a prioritization of value from top to bottom, I would much rather be informed of the completed value I can receive than the collection of untested (and therefore undone) features I might receive that are “80% complete”.

I challenge people to try this. I may truly be wrong here but I suspect that the focus on the immediate and driving to completion will see things completed and delivered quicker.

Just my thoughts, right or wrong …  A game is always won a play at a time, not the whole game at once. And I think this is the same with our commitments to stories to be delivered.

Until next time … Stay Agile!

Advertisements

Scrum master tips – The burndown

I have been working with several entry level scrum masters over the past few years and have discovered that although they may fully understand the general ideas of rituals and artifacts of the scrum framework, understanding the underlying agile value proposition these things support. Gaining insight into how they can utilize them with continued effectiveness with their teams seems to not be something that many do not often explore initially.

So I thought it might be helpful to convey how I view these items and how they can actually create impact for you as a scrum master to up your effectiveness with the teams.

My personal philosophy when I became a scrum master was that my role was a lynchpin in the process overall and that by increasing my understanding and effectiveness of the roles, rituals and artifacts, I could become a better servant-leader to a team overall.

This is merely how I view and utilize these things and hope that they help you as well.

What is the burndown chart?

The burndown chart falls into a category for me to be viewed as an “information radiator. It provides information in a static way that can allow the scrum master and the team to view the current state of product work within the sprint. It radiates information that can then be consumed and acted upon. It is a great artifact for assessment and course correction as well as allows scrum masters to begin to see items occurring within a team that may not be readily apparent, even to the team itself.

It is a chart that is measured by taking the amount of overall effort to be performed (hours of work) and plotting it across an axis of the total working calendar days of the sprint. Often it is coupled with an “ideal line” that reflects the optimum burn of effort equally distributed among days. As the “task hours” are burnt down, it reflects where the team is in terms of hours remaining to complete within remaining time of the sprint.

A typical burndown might look something like this:

burndown chart

In this scenario, the team has 400 hours of delivery tasks over an iteration of 10 days. This reflects work that may be done by the entire team (coding, testing, design, etc) for the 2 week iteration. So, the ideal line is reflecting to the team that at an average burn rate of 40 combined hours of effort by the team that is projected to complete the committed work within the 10 day sprint period.

Typically  the burndown charts I have used reflect the days of dedicated effort and do not reflect periods of planning, review, etc as these are bookend ceremonies to provide sprint lift-off and sprint landing. The burndown is focused on the time where team effort is directed towards end commitment.

The basic idea behind this chart is that from an agile perspective the highest value is to be aware of the work remaining undone and not to remain focused on the work already completed. So the responsibility of the product team is to reflect the remaining hours daily to represent the actual burn of working on a given story.

This is a very brief and straightforward explanation of what a burndown chart is so let’s delve into the next level of how it is helpful, how we might utilize the information and look at some ways to interpret patterns we may see inside a burndown to better frame questions or make inquiries to the team to help them.

What does a burndown chart do for a team?

As I mentioned before, it is an information radiator to a team. It gives them a snapshot of the past brief period of work and tasks completed and a reflection point for the work remaining to be done within the sprint. This information allows them to reflect a current team state both internally and externally to convey where they are without a “direct status report” to others outside the team as well. Anyone looking at the chart can get a general idea of where the team might be even if they do not fully understand the chart itself. This, however, can also lead to bad perceptions as opposed to informational learning as we will discuss later.

It is incumbent that a scrum master fully understand the purpose of this artifact, the reasons behind how it actually works and to begin to see patterns of work or potential team dysfunction within a burndown chart.

This allows them to not only accurately convey how to use this information and its purpose but frame questions aimed at potentially keeping the team productive or assist the team to be actively  aware of the “first responsible moment” of when a product commitment might become in jeopardy.

Patterns of burndown charts

Visual representation of work often allows an excellent opportunity to the scrum master and the team to reflect on familiar patterns that can be a visual queue to certain information or team dysfunction.

The Ideal Line is merely a Projection

As a scrum master, if you have the belief that below the ideal represents the idea of “being on track” and above the ideal is “being off track” you are taking a far too simple view of the  information that the team provides.

The burndown should be seen as a reflection for consideration of current state of a product development print to make inquiry, not predictive like a project schedule. The ideal is merely a projection of all things working with no issues impacting the team. It is a projection used for comparison. Establishing the thought as a scrum master of anything other than this or reinforcing to the team that it means ahead or behind the curve is a bad precedence to set and can lead to future problems.

Effort Swelling

For instance, in the image above, the team starts on day one burning down tasks and within the next 24 hours begins drifting above the ideal. A simple view might create panic and say “HEY EVERYONE! WE’RE BEHIND ON DAY TWO. WE GOTTA DO SOMETHING!!!!” when the circumstances that cause this picture could result from many potential reasons and should be information we can use as a scrum master to reflect on and potentially frame questions such as:

  • Did the committed work had greater unknowns than the team imagined and tasks are emerging? Normal and very possible. Probably just something to be aware of and see how the trend moves within 24 hours or so. But a basis to have the team reflect on this data maybe as a visual cue to them in your next stand-up.
  • Is the team struggling? Is there a causation? Has the team experienced a drop in overall capacity from the commitment due to sickness, not accounting for a team member vacation, etc? Many modern electronic tools, such as Microsoft Team Foundation Services,  will allow you to adjust the loss of capacity by each team member and the chart will update to reflect this effort recalculated across the iteration.
  • Are they just stuck? Are they mentioning impediments in their daily stand-up? Is there something you can do to assist or coach them to self-organize around solving the problem through inquiry?
  • A common symptom of a potential team dysfunction is that the members are not actually “burning down” their hours. They are pulling a task into a working state and working on it until done, therefore reflecting the total hours when there is actually less to be completed and then moving it to done all at once. This can show work not moving and so the work remaining can begin to begin a swelling pattern. One way of getting some insight into the pattern is if you see large drops of work following a swell.

Effort Drops (“work falling off the cliff”)

This pattern may look something like this:

Burndown Chart 2

Some questions that might happen when seeing such a drastic drop quickly:

  • Was the work committed less complex than the team thought initially and they just hit a “rapid burn” (Go Team!)
  • If following a swell, is the team actually burning down the hours regularly?  Are they perhaps holding on to tasks and not updating remaining hours but just pushing it to done when completed? This might prompt a scrum master to look into this information that the burndown provides in combination with the sprint task board and use it during a retrospective for exploration of “what does this mean to the team”?

Again, the key takeaway here is that these types of patterns provide an opportunity to learn, observe and inquire to assist you as the scrum master to help the team remain productive towards meeting their commitment. This information can help you teach the team to use this information to get some insight as to what is going on either during the sprint or used for exploration with the team within the retrospective.

These are merely some simple examples of how this artifact of the scrum framework can be used. It is best to keep in mind the concept of how it reflects back information to the team. Many scrum pioneers have discussed “BVC’s” (big visible charts) of which this can be one to help teams reflect on their current state of work and make adaptations based on insight. I hope this blog post allows new scrum masters a new way to use this artifact and can help them assist their teams with better insight …

I often consider this quote when thinking of a burndown chart in relation to teams …

“Information is only useful when it can be understood” – Muriel Cooper

 

 

 

Thinking in Moments

“Capturing the moments of today will wow your hearts tomorrow” – Anon

This will be a relatively brief post but wanted to share something that struck me in my early morning reading (which is my habit to feed my mind a little to start the day).

I am currently reading the new Chip and Dan Heath book, “The Power of Moments” in which they explore the idea of what defining moments are in terms of people and how people can make the shift to begin thinking in moments so that they can capitalize of the impact.

Doug Dietz, an engineer from General Electric spent roughly two years designing a new MRI machine. The book describes how he was so excited to see the first patient in a children’s hospital be able to utilize his creation but was absolutely dismayed when the experience was met with fear. He said this was the point that he “saw the room through the child’s eyes” which was cold and sterile and his machine sat inside like a “brick with a hole in it”. As a result, many children had to be sedated to undergo the use of the machine just to allow them to stay still and overcome the fear of the experience.

This heart wrenching experience fueled him to take this “pit” (low point or negative experience) and strive to make it a “peak”. So he worked with a vast cross functional team and was driven to redesign the user experience for children. The end result was he and his team created MRI rooms in children’s hospitals that resembled a pirate ship, a space ship or a amazon adventure (this one encouraging the child to stay still as not to tip the machine painted as a canoe). He careful observed the difference in the experience and was delighted when one small child tugging at his mother’s leg asked “can we come back tomorrow”? He had taken a “pit” moment for these children and transformed it into a “peak”.

I read this and thought to myself, “this is so applicable in organizations”. How may “pits” are we aware of as an organization for people (poor performance, bad service, bad product interaction) for which we have no plan or allow it to sit without putting passion behind turning it into a peak?

Conversely, how many “peaks” (employee first day, retirement, significant life events, transitions in career or life) do we place the minimal effort into a miss the power of creating the moment of connection between people and our organization.

This brief story really impacted me and I began to think (and I feel like I will begin to formulate known moments that I think I am missing for my organization) about what I could do to “think in moments”.

How about you? Are you thinking in moments? Are you turning “peaks into pits” or “pits into peaks”? I have not finished the book so I cannot give you a full review just yet but I can say that this small concept resonated with me and I am sharing it with you in hopes that it might with you as well.

Stay Agile!