A Value Chain Map shows the path to deliver value.

A Value Chain Map shows the path to deliver value.

Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. The value chain concept is generally applied to whole organizations, but can be applied to an individual business unit or can be extended to the whole supply chains and distribution networks.  As with many popular analysis techniques are there are myriad variations on a core set of steps. The steps I use are:

  1. Define the goals of the Value Chain Mapping exercise.
    Defining the goals serves several purposes.  First, it sets the goal posts for defining when the analysis is done.  Second, the definition identifies any modifications that are required in the process. The reason that variants on the core steps exist is address specific questions.  For example, if we are interested in the speed of the flow we will need to capture measurement data specific to step duration.
  2. Define the core process categories.
    Develop a list of the core processes from the entry of raw material through the final consumption of the end product.  For simple products the process should be represented in six or seven steps that are directly involved in the creation of the product.  Remember that the Value Chain Map is a high level view of the transformation process.  More complex scenarios that need to represent multiple products or multiple transformation channels will more steps.
  3. Map the main actors.
    Actors are the groups of people that are involved in the process.  In our ongoing example of publishing a book, the main actors might include authors, editors, proofreaders, printers, marketers, distribution personnel, sales people and consumers (not a complete list). I generally suggest creating a second, actors map that is presented either as an overlap or directly below the map of the processes (step 2).  I have also seen actors shown as swim lanes overlaying the process map.

    • Variant: A table could be developed showing a breakdown of the core processes into the specific activities for each of the classes of actors.
  4. Identify the products for each set of the core process.
    Identify the outputs of the process steps as they are transformed from raw materials, to intermediate materials and to final products. Integrate the outputs identified into the core flow. The goal is to refine the Value Chain Map to show how the product is handled, transformed and transported at each process stage.

    • Variant: Identify the information and knowledge capital flows that are generated and integrate those flows into the Value Chain Map. Information flows are often bi-directional.
  5. Optional: Map process measures and metrics.
    Information like step duration, product volumes, counts of actors (five editors) are often needed to address the goal of Value Chain Mapping exercise. The measures and metrics required will be a reflection of the goals identified in step one.
  6. Map the linkages between steps and actors.
    Map the linkages (how the steps and the actors are related) then classify the linkages (temporary, network or long term and influences). Show each type of relationship differently.
  7. Identify and map support activities.
    Add supporting steps to the core map.  In the publishing example, IT and HR would be examples of supporting activities.

    • Variant: Add influence from the environment surrounding the organization.  Examples might be industry associations, government departments or other organizations that exert an influence on how the product is transformed.
  8. Optional: Identify constraints for each step.
    All steps will have constraints. I generally present these in a matrix appended to the map.
  9. Develop a solution that satisfies the goal of the analysis.

Developing a Value Chain Map requires an investment of time and effort, however the formal process of generating the map provides a substantial amount of structure to identify bottlenecks and areas for further investigation.  The first step of process, defining the goal of the exercise, is critical, as it will help you determine how to craft the value chain so that you know when you are done and so that you ensure that there is value in the Value Chain Map that you document.

Scaffolding forms an obstacle to entering.

Scaffolding forms an obstacle to entering.

The power of a retrospective to improve a team’s ability to deliver business value is hard to deny. Given the demonstrable power of the technique, why does it occasionally fail to live up to expectations? Three (ish) primary issues that affect the value of retrospectives are ritualization, lack of follow through and management interventions.  These issues can cause the team or organization to enter a downward spiral of disillusionment that will inevitably end with the abandonment of the technique.

The ritualization of retrospectives occurs when the process becomes more important (or at least as important) as the results.  There are numerous reasons for this issue, but we’ll tackle two here: overcommitted teams who don’t have time to reflect and boredom (wake me up when it’s over).  Teams that are so overburdened and can’t find a mechanism to get un-overburdened will always stay that way (a Catch 22). The ritual of the retrospective will usually be fulfilled so that they team can start planning the next sprint or iteration.  In essence, they need to check the process box so they move to the next step. The Scrum Master or coach needs to help the team address the root cause of the problem, whether that is team-driven over-commitment (taking too much work) to being told to take too much by management.  If a team is in an over-committed position more than occasionally, the Scrum Master may be part of the problem. That means that outside coaching is needed. If the root of the problem is technique boredom, the Scrum Master or another team member should learn another technique (such as timelines, the Sailboat, de Bono’s Thinking Hats or the 4 L’s).  All Scrum Masters should know at least nine techniques for retrospectives.

Lack of Follow Through:
The worst mistake any team can make is to perform a retrospective then do nothing with the results.  While the discussion itself may have been invigorating or cathartic, in the end the team wasted its time.  Consider that if you held a two hour retrospective with a team of eight people and then did nothing with the results you would have cumulatively wasted two full days of effort that could have been used to deliver value to your organization. Every retrospective should identify at least one goal or idea for improvement.  That goal should be added to the sprint backlog and addressed just any other piece of work that the team has committed to deliver. As soon as a team feels that their time is being wasted, they will begin looking for a reason to abandon retrospectives.  Teams that fall into this pattern should seek external coaching support to get back on track.

Note there is a specialized example of the “lack of follow through” syndrome that occurs occasionally.  Teams focus on issues in the retrospective that are outside of their ability to control. For example, I recently observed a team that was letting the fact that their office environment was noisy and that they could not have a dedicated team room consume them.  The organization had grown substantially and was attempting to find additional office space, but the process was taking longer than the team liked. The Scrum Master should have helped them understand that there were other process improvements that could be made or alternate mechanisms for addressing the issue, rather than fixating on an issue they could not control.  In the end, the team had a heart-to-heart discussion with the owner, which mollified the team (they did understand the status of the expansion plans).  The team also received training on retrospectives and facilitation.

Management Interventions:
Retrospectives, are a team exercise.  In a sprint retrospective the team is comprised of a Scrum Master (or coach), Product Owner and development team.  No one else, with the exception of an occasional outside facilitator, should attend. As soon as managers or other outsiders begin attending the conversation will change to become more guarded and territorial.  In my experience when outside observers are included, the goal often shifts from process improvement to position improvement.  The Scrum Master must make every effort to police the team boundary and ensure the free flow of information within the retrospective.

The retrospective can’t become ritualized to the point that it lacks meaning.  Each retrospective needs to provide a platform for the Agile team to reflect on their performance and to determine how they can achieve more. This is a team activity that requires a free flow of conversation and ideas in order to maximize effectiveness. That means someone needs to facilitate the process and police the boundary.  No team is perfect and all teams can learn and improve on a continuous basis.  Most obstacles to effective retrospectives are solvable with a bit of coaching and education if you recognize the obstacles before you abandon the technique.

Related Entries

Retrospectives: A Basic Process Overview

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event