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:
- Mail 100 letters
- Wash all of the windows at my house
- Cut the grass
- Feed the dog
So you take these jobs and decompose them into tasks:
- Get envelopes
- Get stamps
- Fold letters
- Put letters into envelopes
- Take to post office and place into mail
- Get cleaning supplies
- Treat each window
- Wipe each window
- Get gas for lawnmower
- Start lawnmower and cut grass
- Do edging
- Blow grass clippings off pavement
- 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:
- Fold all the envelopes
- Go to the store and get cleaning supplies
- Pickup some dog food
- Fill your gas can with gas
- Get your stamps
- Fill the lawnmower
- 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:
- A full lawnmower but the grass is still not mowed
- Letters in envelopes that sit not mailed
- Plenty of cleaning supplies but dirty windows
- A dog with a bag full of food but very hungry
So what if you had:
- Gotten the stamps and envelopes and ensured the mail got sent.
- Went to the store, got dog food and fed your dog
- 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:
- Their skill level does not allow them to pull more advanced tasks
- 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:
- 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)
- Assisted in testing, maybe writing scripts or unit tests for the code under development or helping to write test cases
- Performed the “just needed” level of documentation for the project
- 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!