Impact mapping

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…

Impact map

 

  • 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.

Posted in Agile, Lean Tagged with: , , , ,

Continuous discovery

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.

Posted in Agile Tagged with: , ,

Effective retrospectives

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…

Iteration/Sprint time-line

* 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.

Burndown chart

* 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 fluency

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: ,

Improvement theme

In a typical Scrum retrospective, the team identifies remedial action and then tries those in the upcoming sprint. But sometimes, the teams encounter large issues for which the solutions can span over multiple sprints. For example, the team might encounter an issue which needs a fix in how they do requirements, develop and release. It might be difficult to do it all in a single sprint.

Jimmy Janlén at Crisp has created a simple tool to deal with these kinds of situations wherein improvements span multiple sprints. It’s called an “Improvement Theme”. It’s inspired by Toyota Kata (which prescribes a systematic method to create a culture of continuous improvement and coaching in an organization). Jimmy describes the usage of poster in great detail in his blog.

Here’s an example poster
As part of the retrospective, once the team’s reflections are on the board ask the team to group them into topics. E.g.: comments related to bugs discovered during end-user testing could be put under a topic called “Quality”.

The team votes on their favorite topic. And creates a theme based on the topic. E.g.: Improve the quality of the product

An example improvement theme poster

An example improvement theme poster (Click on the image for better readability)

Deviations from the original poster

  • Not using the heading “Definition of awesome”. As cool as it sounds, I think there are already too many “Definition of…” in our community.
  • Added a new review date section to highlight the commitment the team has made on when to meet again and review the results.
  • A Done section to move all the post-it notes from the “Next steps” section when the actions are completed.

Some things to keep in mind

  • The team should not jump into solution after identifying the topics (as typically done during retrospectives)
  • Ensure the next target is actionable
  • Ensure the team agrees upon the next review date
  • The criteria should be good enough to ensure the verification of goal completion
  • We added the action items on our scrum board, so the status of each action item was highly visible
  • Once all the “next steps” are completed, verify the goal is actually met
  • Do not forget to move on to other goals on the same theme
Posted in Agile, Lean Tagged with: , ,

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.