I’m currently attending a seminar on Value Stream Mapping. I’m also feeling an intense desire for more coffee. The big downside of conferences in your home town is that you have to commute to the thing rather than it being in your hotel, which means (for me) waking up a couple of hours earlier than I normally do.

The purpose of value stream mapping is to understand what parts of a process actually provide value to the customer. The goal is to identify and remove those parts of a process that don’t add value. In software, the goal is to minimize the time between the development of a good idea (process change, etc.) and the time that the business can actually make use of it. The big challenge with lean methods for software is that they derive from manufacturing (where the end result is known).

Briefly, what you do is:

1. Identify each step in the process.
2. Determine how much time each step took.
3. Determine how much time was actually spent working on the step.
4. Identify time delays between steps.
5. Look for loops and rework.
6. (Optional) Identify the typical size of the backlog waiting to be processed through each step (to help find bottlenecks).

You can then calculate the Process Cycle Efficiency (the amount of actual work as a percentage of the actual time taken by the process) which is a good basis for defining a business case to improve the process. For most software process, 50% is pretty good and 70% is fantastic. Actual numbers tend to be much worse than that.

There’s a lot of info on value stream maps available through the internet so I won’t try to summarize the whole seminar. For BAs, I’d suggest that you look at value stream mapping as a tool that can be useful whenever you need to look at a business process. It’s a good technique for identifying parts of a process that can use improvement, or figuring out which aspects of the process are worth automating.

Kevin Brennan, CBAP
VP, Body of Knowledge

Finally back on the air, with the last session of the day. If I get a chance to do so I’ll post up some notes from the ones in between.

As a general note, I’ve found the general tenor of the people here to be much more positive about the role of the BA in Agile development than some of the “extremist Agilistas” would have you believe. I think there’s a growing acceptance of the necessity of the role even if the way the job is done would change in an Agile world. A lot of the content in some streams (like the Customer Value stream, where I’m spending much of my time) is pretty relevant to BAs.

Right now I’m in the Business Value: Soup to Nuts session. Business Value is one of the key concepts in Enterprise Analysis, and in general business value is anything that increases revenue, decreases costs, or protects revenue, and is in alignment with the strategy of the organization.

They then walked through some prioritization models: one based on market maturity and one developed by Niel Nickolaisen.

Business value itself is an approximation of reality and not reality itself. Most estimates of the business value delivered by a project are unreliable and never updated once the project is approved. The most useful part of the work in identifying business value is is developing the model and understanding how the solution is expected to deliver it.

We’ve just gone through a series of exercises on building reasonable business value statements. They provided a lot of examples of statements that are problematic because they only discuss costs or only discuss benefits, as well as ones that sound positive without demonstrating real value.

Chris Matts is now talking about a process they used for handling ideas. As ideas are generated they do some basic analysis and then stick them into a backlog. As people become available to tackle these ideas they used a kanban system to pull out the feaures that were the highest priority at the time.

Session ending now, see you later.
Kevin Brennan, CBAP
VP, Body of Knowledge

I’m spending this week at the Agile 2008 conference in Toronto (I’ll be speaking tomorrow, and here all week). If you’re there, look for the guy wearing the IIBA shirt. I’d say I was the guy with the Mac but there are lots of Mac users here, far more than I’ve seen at other business conferences.

The keynote is James Surowiecki, the author of The Wisdom of Crowds. He’s actually talking without resorting to PowerPoint, which is something it’s hard not to approve of. His argument is that under the right conditions, groups of people can figure out problems that are beyond the ability of any individual in the group to solve. However, he’s not suggesting that any random group is going to be smart. It takes certain conditions to apply for that to be right.

Microsoft and Siemens have been using internal trade markets to allow employees to “bet” on when a project is likely to be finished, and have found that theses methods are better at forecasting actual delivery dates than the project manager’s plans. A big reason for this is that they allow people to describe what they actually think rather than what they would hope or be encouraged by their managers to think. This is the biggest benefit of this approach–the focus for everyone involved is to get the guess right.

Three key conditions to leverage wisdom of crowds:

1. Need a good way to aggregate the individual judgements of a lot of different people.

2. The group needs to be diverse, with a wide range of opinions. If a team is filled with people who all look at a problem from a single perspective they will converge on a similar answer.

The group does need to have some understanding of the problem that they’re trying to solve–the key is to have a bunch of different perspectives.

Diversity allows a group’s mistakes to cancel one another out. A homogeneous group will tend to create an echo chamber that reinforces bad ideas and blind spots. Collaboration helps to make smarter decisions when the group initially disagrees but can make the group dumber if they all basically share the same point of view to begin with. Even one person disagreeing can be helpful, but not if the same person fills that role every time (because the rest of the group will start to ignore the sole dissenter). The best group decisions emerge from conflict rather than consensus (but effective conflict requires trust).

3. Independence. Every person in the group has to be offering up their ideas on their own rather than paying attention to what other people in the group are thinking. The problem is that people often get punished for standing out–you get in trouble for an unusual opinion that happens to be wrong, but not or a “normal” opinion that’s wrong. In larger groups, you may need to make sure that you allow people to be anonymous to ensure that they tell you what they really think.

Kevin Brennan, CBAP
VP, Body of Knowledge