Posts Tagged ‘agile’

Effect maps

October 29th, 2011 No comments

I just read a copy of Gojko Adic’s Agile Product Management using Effect Maps because I too still find high-level product visualisation problematic when trying to do iterative product management. Adzik explains “Effect Maps” (which are structured mind-maps) which allow for design, priorisation and scoping. It well worth the read. Here’s a few thoughts I had while reading:

Simple technique for a working meeting

It brings people together and always has at its base of discussion to the business value/problem to be solved. The mindmap starts from the question of the goal: Why are we doing this? What is the desired business change? I could see structuring early discussions with senior people. Likewise, I could all stakeholders in the room and use the technique.

How to get see the whole and defer ambiguity

The four-levels in the mindmap is detailed enough to move through the Why, Who, How and then detailed What. But in practice, there is loads of detail still to come in the What (the features) that the team will need to work. Be able to defer with the implementation details to when starting on the specific is an important strategy to avoid wasteful work and delays.

Good for Target Cost development-type contracts

I tend to work on Target Cost contracts but always struggle with what that end goal and target cost is. Few can articulate what their break-even (or often opportunity) cost is. The effect map should provide a good way to identify needs and the potential investment required. Usually, in the end, while I might suggest a cost clients also usually have a sense of what they can afford against there (often implicit) view of its value. Interestingly, investment is the correct vernacular over cost. Most of my clients want to capitalise my work rather than pay for it out of operational budget.

Avoids lists of stories

If you really wanted to get me started of a rant then start sputing that user stories are the technique to counter requirements documents. In my experience, this assumption always leads you back to the same root-cause analysis: the analysis wasn’t refined enough (ie the story was too big, not well defined, could have been broken-up more). Although all those reasons are true, I tend to see that there wasn’t enough context because the stories while grouped (into themes) they really didn’t have good prioritisation, scoping at a higher level. Or as he puts it, user stories are being used for managing long-term release planning. The effect map helps by not using the user stories at level. This is nice because it keeps in the front of our mind that user stories are a merely rubric, albeit a very useful one. The effect helps us keep user stories at the outmost leaves of the map and not toward the root. As he says,

User stories are de facto standard today for managing long term release planning. This often includes an “iteration zero”, a scoping exercise or a user story writing workshop at the start of a milestone. During the “iteration zero” key project sponsors and delivery team together come up with an initial list of user stories that will be delivered. A major problem with the “iteration zero” approach is the long stack of stories that have to be managed as a result of it. Navigating through hundreds of stories isn’t easy. When priorities change, it is hard to understand which of the hundreds of items on the backlog are affected. Jim Shore called this situation “user story hell” during his talk at Oredev 2010, citing a case of a client with 300 stories in an Excel spreadsheet. I’ve seen horror stories like that, perhaps far too often.

Categories: Uncategorized Tags: ,

Naked Planning – Arlo Belshee from Agile 2008

November 11th, 2008 No comments

There is a nice pod cast (Agile Toolkit Podcast) by a guy Arlo Belshee on Agile Toolkit Podcast, Naked Planning, Promiscuous Planning and other Unmentionables (sorry don’t have a url). He has a couple of points that are interesting (around 17-23mins). He is basically using Lean-type queuing for planning. I am interested in his ideas around prioritisation and estimation. He is basically arguing that in prioritisation having estimations creates a selection bias. That is, the business does not necessary choose the options that are best for them (ie delivering business value in the form of cash or a long-term differentiator). He argues against a traditional cost-benefit analysis. This analysis is a 2 × 2 grid – cost (x) by value (y) as scatterplot as below:

high   |                                    long-term value (market differentiator)
       |    short-term value (cash)
       |    low-cost/low-value (death march)
low    |                                       never done (expensive and little value)
           low                    (cost)                 high 

In this approach there are four main positions: (1) top-left is the short-term value options that are cheap and easy to do but provide high value. These tend to get you cash in the market place. But competition can also copy and innovate at the same rate. So they are valuable only in the short term and are also known as cash cows. (2) top-right are the long-value options. These are the market differentiators that you want to build. Because they high a cost, they are harder for the competitions to create. (3) bottom-right are the low cost and value. These are the items that we tend to think of as quick wins. He points out that they are the death march. They merely distract from delivering value. (4) bottom-right are normally thrown out and not a problem.

He argues that we need to remove, the x axis, cost. Prioritisation should only be about business value and lined up in order. In fact, he points out that when you take away the cost, his group opts for high value propositions. This mixture of short and long-term value propositions is a better product mix. But if you leave in the cost, people do tend want to include the death march items.

Therefore, do value-based analysis. Rather than cost-benefit, do benefit-benefit analysis. This approach hide costs, or in fact never does the estimations in the first place. Because having an estimation is a negative business value proposition and actually has a positive cost. It is negative business value proposition because it creates a selection bias that people select non-business value options. It has positive cost because someone has the make up the estimations. It has the other cost that the made up part is just that – made up. Better to work with a queue of real wait time over the duration of the project.

He continues on to talk about estimations as wait time before starting the next MMF.

Categories: Uncategorized Tags: , , , ,