and achievements didn't come into the development pipeline for the next six months.
Product management using effect maps
Effect Maps are useful for much more than just an initial scoping exercise. I found them very useful as a catalyst in product management. They facilitate the implementation of several very good ideas for iterative product management, crucial for successful delivery of agile and lean projects:
- setting clear goals
- providing a shared understanding of quality
- prioritising based on business value
- iterative long term product release planning
- deriving scope from goals
- focusing deliverables on business value increments
- preventing scope creep
- supporting scope change and reprioritisation
Setting clear goals
If a project succeeds in delivering expected business value, it is a success from a business perspective. This is true even if delivered scope ends up being different than what was originally envisaged. On the other hand, if the project delivers exactly the requested scope to the word but misses the business target, it is a failure. This is true regardless of the fact that delivery teams can blame customers for not knowing what they want. Unfortunately, I've seen far too many projects where this business value is not clearly communicated to everyone. Very often it is not even defined, and in the cases when it is defined it is too vague to be useful. Such definitions make it hard to objectively measure whether the project actually delivered what was wanted. As a consequence, teams focus on ticking boxes by delivering scope as a measure of success.
Effect Mapping helps to define goals because it requires us to identify the expected goal as the first activity. But we can go further. Clear goals help teams design appropriate solutions. A solution to increase the number of players by 5% over 12 months is completely different than one that would increase the number of players by 100% over 6 months. To support the team in delivering the right system, we need to clearly define the business target. A great trick to ensure a shared understanding of the expected business effect is to decide how to measure it. After we have answered the question " Why", we should go further and answer the following question:
- How will we measure how much any future delivery matches the expectations?
Defining the goal in a measurable way requires sponsors to think really hard and define precisely what they really expect out of a software project. That will help to align the expectations of the sponsors, the stakeholders and the delivery team. It will also allow the delivery team to design the appropriate solution and invest effort proportionally to the expected return.
Identifying measurable goals (such as “one million players” instead of just "more players") is key to ensure a shared understanding of what a project is supposed to deliver. Tom Gilb argues that measuring such effects and deciding how to measure them significantly improves the chances of success of a project [Gilb05]. He also presents several techniques for measuring things that do not seem easily measurable. For further examples of measuring seemingly intangible things, see [Hubbard10].
Providing a shared understanding of quality
Similar to the way that project goals are often vague and not universally communicated, software quality is rarely defined precisely. This causes misunderstanding, misinterpretation and confusion about what a project needs to deliver. The interpretation of quality and the argumentation around that is delegated to a quality assurance role without much involvement from any business sponsors.
With an arbitrary interpretation of quality, there is nothing to help teams decide how much to invest in certain aspects of their