The product backlog is boring. After all, it’s just a list, albeit an ordered one. Hence we do things like user story mapping, which makes it a more presentable way at looking at requirements. Nevertheless, more and more teams (and even stakeholders) get detached from the the actual business goal that is to be achieved. We get lost in the minutiae of the backlog. Try this – ask any team at the end of the sprint, what business objective did the sprint contribute to or achieve?
One of the techniques for both discovery and visibility of goals, outcomes etc is Impact mapping. Impact mapping uses a very simple technique to find out the following…
- Why are we doing this? What is the goal you are trying to achieve? (Goal)
- Who can affect that goal? (Actors)
- How can they affect the goal? (Outcomes)
- What can we do to realize that outcome? (Features/Actions)
- So you start with the question why (do we want to do this)? Jot that down the goal on the white board or post-it note.
- Then ask the questions, who can affect the goal (either positively or negatively). List down all the actors.
- For each actor,
- ask the question how can this actor affect the goal. This gives us the desired outcomes.
- For each outcome,
- enquire what can be done to realize that outcome. We now have actions/features
Once you have this mapped out, the stakeholders can decide which outcome will have the best chance of achieving the goal. Order the features/activity for that outcome.
Execute the highest priority activity/feature. Once done, introspect if the outcome has been achieved. If it has, introspect if the goal has been met. Of course, if the goal has been met, then we are done. If not, move to the next activity, next outcome, next actor.
As we learn after each execution, revisit the impact map to apply what we have learned. If you are using, story mapping you could add the outcome to the “rows” of stories that you map out. This way, everyone knows what outcome we are working on.
We have successfully used this technique for goal oriented activities – strategic planning, marketing campaign design and of course need finding.
The agile way of ensuring level flow is via slicing of the backlog. However, this is not easy to do. We do spikes to learn more and then use that information to create roughly equally sized chunks of stories. I think this is where the struggle is. Uncertainty freaks out people and we go back to what we know – try to figure everything up front before starting the work. Of course, that does not work either. What is not well appreciated, is that, slicing the backlog is one of the key criteria to be agile.
I think the reason why we struggle is that we have missed another key piece to be agile – learning. Running spikes (experiments) to learn more, which in turn helps us to un-bundle, a need into chunks; which, when built chunk by chunk, indicates predicable progress to the customer. We may sometimes do this instinctively, but we may want to be methodical about it.
Why do we need to learn? Because there is no perfect solution. There is only a possible right solution given all the constraints (time, money, limited understanding, unpredictable future etc.). The customer, the development team have to discover this right solution. And that can be done only by experimenting, which leads to learning.
Once we let go of the myth of the perfect solution and the unhealthy assumption that we will get it right the first time every time, we can can start looking at solving problems as a never ending series of experiments. And therein lies the crux of continuous discovery.
As time goes by, one key observation from team retrospectives is – the core issues do not seem to surface during retrospectives. Most of the issues are superficial or “it was all the the other teams fault”.
Two key reasons for this lack of insight seems to be …
* Lack of data or not using the data from the just concluded iteration/sprint
* Do not remember important events from the just concluded iteration/sprint
So it’s important for the facilitator to guide the team to get to these insights. Here are some techniques to try…
* Create a time line on the board for the just concluded iteration/sprint
* Ask the team to remember events that happened from the beginning of iteration/sprint and post them on the time line.
* Bring up the burndown chart for the recently concluded iteration/sprint
* Ask the team on reflect on the ups and downs of the graph
This should help the team to reflect more deeply on what truly occurred during the iteration/sprint. Once the team has those insights and have voted on key items (if there are too many), try root cause analysis. This almost always help identifying dealing with the real problem rather than a symptom(s) of a problem.
Posted in Agile
Tagged with: agile
Recently saw a video of a keynote speech at XP2013 by James Shore, wherein he described the Agile fluency model that Diana Larsen and he put together.
One of the key things James emphasized is, this is NOT a maturity model for agile. Fluency at any level is a good thing. The key is to ask ourselves – are we fluent at what we do? One maybe at “1 star” or “3 star” level, but are we fluent at those respective levels?
Fluency is doing things well and gracefully even under extreme pressure. So if one believes they are “2 star” team, and you drop writing unit tests because you have a pressing deadline, then you are not fluent.
One key take away was, if you want to be a “3 star” team, then begin working towards that from day one. i.e.: Start practicing both the basic and advance practices rather than the traditional easy to difficult progression. Fluency is about habits, so the more often one does it, the more effective it would be.
Per James, majority of the companies are struggling to be fluent even at the “1 star” level. We are increasingly in danger of being perceived as snake oil salesman, if we continue to promise “3 Star” agile benefits, with “1 star” level of training/coaching. The transformation to agility is not easy (and we should not sell it as anything else), but once realized you cannot imagine working any other way.
I found the presentation very inspiring and also a call to action . You cannot be agile by certification. Yes, one needs to be well versed with practices, but no methodology/framework can save you from bad code. To be agile, one has to be fluent with all the practices of software development.
Posted in Agile
Tagged with: agile