Thinking about Business Value

Alexander Nowak of the Microsoft Community of Practice of Cap Gemini Belgium has written a description of the tryout of the “Agreeing on Business Value with Systems Thinking” that will be re-run on April 1st at Mini XP Day Benelux.

In his post he describes the following main points:

  • Business Value is multi-dimensional and not always easy to express. The key lies in the measurability of things.
  • The “Business Value Model” is a technique to set the context of the “big” why and communicate this across the organization (small or big).
  • It is built around the concepts we are mostly familiar with (and borrowed from other techniques).
  • The “Systems Thinking” part comes into play to discover relationships between goals, capabilities, stakeholders and measurements and risks. When you turn a knob here, something will happen on the other end… and vice versa.
  • A business value model is not carved in stone. You must always evaluate if what is described (or better drawn) in the model actually reflects reality.
  • This visualization is important for communication. Doing the value exercise can be an eye-opener for the people in the project and/or organization.
  • The “Business Value Model” should be the origin for all user stories.

Yes. That’s it. Couldn’t have said it better myself 🙂

You can see the outputs of the workshop in a previous blog entry. Read more about it on the AgileCoach site.

Hope to see you at the conference!


Avoid Change

The thing I hate most about myself is that I don’t want to change

The first XP book was very important for me. It changed the way I work. It changed my life.

I still apply the practices to improve the way I work. The principles have helped me to make my work more fun, sustainable and successful. The values have helped me to do worthwhile work that delivers value.

But “Embrace Change“? I don’t like change.

How to avoid change

I avoid change on my projects by

  • Really understanding the needs of customers, stakeholders and users. Those needs change from time to time, but not very frequently if we really get to the core of what these people value. I get accused of doing Big Upfront Design or Analysis, even in companies seemingly doing Waterfall. Why waste so much time upfront, can’t we start building yet? Customers don’t know what they want anyway, so why try to discover what they need?
  • Not committing to decisions too soon, applying Real Options. If we commit later by delaying decisions to the last responsible moment and gather more information, we need to come back on fewer of our decisions. I do get called a procrastinator. Real leaders take charge, take decisions!
  • By not being distracted by useless technology churn. Simple, reliable and known tools and technology in our toolkit let us concentrate on adding value. I do get called a dinosaur, not up to date with the latest framework or fad du jour. Real geeks only work with the latest 0.1 version of technologies that are so complex that we can spend months unraveling their intricacies (and bugs). I need a well-padded resume with all the latest technologies to get that next job when the shit hits the fan on this job.
  • By making sure we consider supporting processes and users in our value analysis. All too often we focus on the shiny business value generating processes but forget that these can’t work unless people can perform the unglamorous supporting jobs that make these value streams possible. I do get called a Waterfall analyst, who wants to explore every nook and cranny of the system before we can start building. Real Agile teams deliver Business Value, cash quickly. Why waste time with non-business value-adding processes like getting the product into the hands of the user or managing the system to keep it relevant?
  • By making a plan (not a schedule) of the goals we want to achieve in the future so that we have a guiding vision when we travel the path. I do get called an old-school project manager who wants to control and stifle the creativity of his “resources”. You can’t be agile if you have a plan.

Projects with fewer changes are a lot easier and less stressful than those with many changes. These projects implement Heijunka. They deliver value surely and steadily. I like that.

Embrace risk reduction and new information

I welcome any change which reduces risk. We continuously identify our main risks and find ways to avoid them. For example, we discover that there’s simple alternative way of doing something. We can use that as our backup strategy if the planned way of doing the work doesn’t get ready in time. For example, we first implement a very basic implementation of a business process and iteratively refine it, so that we’ll always be ready to release by the deadline. Of course, we have to use that extra time that Real Options gives us to actively seek out information and reduce risk.

Embrace increased flow

I welcome any change which can increase flow, get us to release faster and get the cash flowing sooner. For example, we can start by statisfying a subset of stakeholders and users. We can focus on on value stream at a time. We can mercilessly pare down what is really needed to achieve goals. We can get rid of wasteful checks, approvals and delays. We increase quality to decrease changes due to rework.

Embrace value increase

I welcome a change that increases value. For example, “Exchange Requests” let the customer increase the value of our work. If the customer wants to add a feature to a release, they first have to remove an equivalent amount of work from the release. The customer will only perform the swap if the new feature has more value than the one swapped out. So, for equal (or lower) cost, we deliver a product with higher than initially expected value.

Embrace cost and investment reduction

I welcome a change that reduces cost or investment. I welcome a new, simpler way of achieving a goal. I welcome reducing scope as we discover that we can simplify business processes. I welcome a reduction in “dimension” as we discover that we can satisfy user needs (for now) with less exhaustive or refined implementations. I welcome a way to reduce the amount of work in process.

I’ll get me coat then…

Can I be Agile if I don’t Embrace Change? Can I be Agile if I value people and their interactions AND processes? Can I be Agile if I insist on customer collaboration AND a contract?  Can I be Agile if I only want to respond to beneficial change AND follow a plan? Can I be Agile if working software is not the solution or only a small part of the solution? Can I have my cake AND eat it too?

Where do I go to hand in my Agile badge?

If anybody needs a Waterfall coach, let me know. I can change. I’m agile 😉


Estimating Business Value

Business Value

Business Value is one of those terms that’s used often but rarely defined or explained.

I use “Business Value” like “Story Points”: a unit-less, relative, leading indicator of the value that will be generated when we’ve delivered the piece of the system that we’re estimating. When we’ve got this nice one-dimensional Business Value and Cost, we can quickly create a plan in two steps:

  1. Maximise delivered value by prioritising by Value/Cost
  2. Adjust the ordering to take various constraints into account: dependencies, promises that need to be honoured, risks that must be explored… This re-ordering necessarily decreases the amount of value that’s delivered, so we try to avoid dependencies, premature promises and unexplored risks that will force us to reduce value.

Estimating Business Value

But how does one estimate this mythical “Business Value”? There are a number of techniques I’ve used successfully:

  • Sort the items by value, from low to high. Don’t allow items to be given the same value, otherwise everything will end up with a high value (otherwise known as “MoSCoW Hell”). Start with the lowest value items and give them a base value, ‘100’ for example. Give all higher-valued items a relative estimate. This is exactly the same technique we use in the XP Game to teach how to estimate cost in Story Points.
  • All new items are estimated relatively to previously implemented items.
  • Build a set of representative items to estimate relatively against.
  • Don’t make your items too small. I intentionally speak of ‘items’ here, not User Stories. It’s often easier to estimate the value of a larger chunk of functionality like a Minimal Marketable Feature (MMF). When you split the item in smaller parts, divide the Business Value among them or keep the Business Value at the higher level item so that you only earn the Business Value when you implement the whole item.
  • Don’t take Business Value too seriously, it’s just a prioritisation tool.

So, we work with Business Value like with Story Points. On some projects we display this in a “burn down/up chart”. Cost burns down, while value goes up. I find this useful to break people’s (well, mostly managers’) instinctive idea that value is just the inverse of cost. Value and Cost are independent variables! It’s not because we spent 50% of the effort that we delivered 50% of the value.

The big difference between Business Value and Story Points is that I haven’t come across any company that calculated its “Business Velocity”. Velocity is measured to tie the unitless Story Points back to something tangible like man days. Velocity calibrates our story points estimates and improves its accuracy as a leading indicator of cost. Business Velocity is the same concept: if we delivered something “worth” 1000 Business Value points, how much did we actually get in something we value, like money? I have hopes that one team will actually calibrate their Business Value as that’s the business they’re in: modeling and calibrating to predict.

Improvement: build a Business Value Model

The simple process described above works well when the situation is relatively clear: one customer, one or a few sources of value that are easily identified (e.g. you sell custom software development). What if the situation is a bit more complicated? What if there are more stakeholders, each with their own definition of value? What if you value more than just money from project sales? Where does that prioritisation come from?

You build a “Business Value Model”. You make a list of all the things you value, which could include:

  • Money you get paid in the short term
  • Money you could get paid in the future (which is of course less valuable than money in the short term)
  • The happiness of your customer
  • The happiness in your company
  • New information that can be obtained
  • More visibility in the market
  • Increased reputation, prestige of the customer
  • Other sources of income
  • ….

You also list the things that you fear, that would decrease the value of what you build:

  • Technical risk
  • Market risk
  • Competition
  • ….

Select the parameters that are most important for you. Give each parameter a weight. For a start, each parameter could have the same weight. Now you can evaluate each of your projects (and maybe MMFs) against the Business Value Model to see which ones are most valuable.

The value of the Business Value Model lies not so much in the model itself but in the conversations to create and use the model. These conversations might uncover some “unspeakable” facts. For example, there might be an unspoken hierarchy among customers: those customers who have the CEO’s phone number get higher priority.

Everybody uses a Business Value Model to prioritise. You can choose to make it public or keep it unmentionable. In the companies with a Business Value Model it’s easy to see and explain why the high priority projects are high priority. Everyone knows what value they’re adding.

Playing a few rounds of the Business Value Game is a good intro to start this conversation.

The techniques above help, but estimating Business Value isn’t easy. Getting someone to estimate is like getting blood out of a stone. Doing it at or before every planning meeting takes time. What if we stopped estimating Business Value of projects, MMFs and user stories, yet retained our ability to prioritise and evaluate value delivered?

Stop estimating implementation Business Value

Project have stakeholders. Stakeholders have goals. Now, don’t ask stakeholders “What’s the value of this piece of functionality?” Ask the stakeholders: “What’s the value of achieving that goal?” What’s the value in terms of the parameters of your Business Value Model: how much new income will we generate, how much money will we save, what important information will we have gained, how will this improve our reputation and brand? We can start asking why this stakeholder needs to achieve that goal.

Now we’ve moved the conversation away from implementation issues and are firmly in business-issues land. We can value goals and their sub-goals and start prioritising them early, before we start thinking about implementation. We start the conversation about value before we can even start to talk about cost.

We can derive the required features from the goals. The business value of the features is derived from the value that’s generated when the goal is reached.

Start writing User Stories differently

I’ve found it a lot easier to start with Business Value and to derive User Stories than to create the User Stories and then add Business Value, as the conventional advice goes.

This is Agile (Business) Analysis. Continuously:

  • Create a clear vision
  • Identify the stakeholders
  • Identify their goals
  • Determine the value of the goals
  • Prioritise the goals according to value
  • Determine the capabilities needed to achieve the most important goals and to realise their value
  • “Pull” information about the needs to estimate cost, prioritise and plan
  • Let the implementers pull information about the needed capabilities
  • Track value delivered.
  • Improve the process and the model.

To reflect this process we use a different User Story format:

TO <achieve a goal>
AS A <stakeholder>

I NEED <a capability>

Liz Keogh described a similar User Story format in her blog entry about  “Feature Injection”. We start with the goal and derive the need from that.

There is one difference: we don’t use “I WANT”, but “I NEED”. When we derive capabilities from goals, we only consider those that are really needed because we use a “pull” perspective, not a “push” perspective.


Relinquishing the illusion of control – one small step at a time

Bart the BA had just joined the large organisation where I was coaching. He asked me to help do the business and functional analysis of one of our largest projects. He had several years of experience analysing large systems. I tried to teach him how to do Agile analysis, convince him that he didn’t need every last detail before development started.

I failed.

The result was a thick document that described the processes and business rules in excruciating detail.

That won’t work!

There are a few ideas in Agile methods that are almost always met with incredulity and disbelief. The reaction ranges from a puzzled “Hmmm… That’s an interesting/unusual idea” to “Are you crazy? That’ll never work!”. What’s so hard to believe?

  • Project managers can’t believe their project will run more smoothly with less detailed planning upfront and detailed controls on what the team is working on.
  • Architects and designers can’t believe the application’s architecture will be more appropriate and easier to understand and change with less detailed design up front.
  • Analysts can’t believe the team will understand what the customer needs with less detailed analysis up front.

The Waterfall dies hard

Wasn’t the Waterfall dead and buried? Why do so many people still think that doing more work and more detailed work up front will improve our projects?

It’s only natural.

Projects are scary. There are so many variables. So much could go wrong. Our instinctive reaction to deal with these fears is to nail more down, research in more detail, take decisions as soon as possible and reduce the number of variables and options. Which is exactly what we don’t want to do.

We want our coachees to accept the paradox that to control our projects better, we need to relax our control. If we want to take better decisions, we should take them as late as possible, when we have the most information. Instead of closing down options early, we should instead keep our options open to deal with an uncertain future.

Techniques like “Real Options” replace premature commitments with decisions about the conditions under which we will need to commit. Meanwhile, we can gather information and find more options.

Techniques like “Critical Chain” allow us to deal with the uncertainty of dependencies and estimates by giving us the means to deal with the planning risks as they arise.

Techniques like “Dimensional Planning” allow us to maximise value/effort by giving us the means to take decisions about depth of implementation as we get feedback from the customer.

An investment in code and design quality, automated tests and team skill keeps the system malleable so that we can deal with unexpected requests economically.

Leap of Faith

We must always be aware that to change the way people have worked, mostly successfully, for years requires a huge leap of faith from our coachees. When they first start changing the way they work, their performance will go down, they will feel uncomfortable and they will feel lost. They will want to go back to their familiar way of working.

We need to support them with practical assistance and encouragement, help them through the difficult moments and show them new techniques. We need to acknowledge their fear and address the fear:

  • Yes, emerging design will rapidly degenerate unless we all have the discipline and skills to apply good design principles, practice test-driven design, continuously refactor and continuously improve teamwork. How can we strengthen the necessary practices and skills? How can we trust the team to do a good design job?
  • Yes, just-in-time requirements will fail unless we have close collaboration and communication with customer representatives. How can we ensure that we will get quality information from them? How can we trust the customer representatives to do a good job of describing and validating user’s needs?
  • Yes, “rolling wave” planning will fail unless we receive good credible and reliable information about estimates and status from the team. How can we ensure that the team has the necessary skills and transparency to provide the project manager with the right information at the right time? How can we ensure that the project manager communicates clearly about goals and constraints? How can project manager and team trust each other?

Bart noticed that the developers didn’t really read the requirements document. The developers wanted User Stories, so I helped him to translate the requirements into stories. Whenever the developers had questions they came to Bart. Through his work on the analysis he knew pretty well what the system was supposed to do. When he didn’t know, he knew who to ask.

Gradually, Bart became this team’s product owner. Some expert users were added to the product owner team. For the next release, the product owner team started with stories and elaborated the detailed requirements just before the developers needed them. For the first time in years, users were happy to receive new releases of this application.

What’s common in all of these concerns?

  • Relinquishing control, or at least the illusion of control.
  • Mutual trust.

The best way to break out of the vicious cycle of distrust and increasing control is to inject some trust into the system. Increase trust by the project manager by helping the team to communicate transparently about progress, for example with a burndown chart. Increase trust in the team’s estimates by using historic velocity. Increase trust about requirements by involving users, analysts, testers and developers in the definition of user stories and acceptance tests. Increase trust by showing the working and growing system regularly.

We, as coaches, are sources of trust. We’ve done this before. We’ve done this successfully before. We’ve also failed; but we’ve learned from the failures. An investment in coaching is an investment in trust.

Small Steps

A small step is a lot less scary than a huge leap. Therefore, we try to help our coachees to change gradually. First try a little less upfront work on a small project. Gradually decrease the amount of control; gradually increase the number of projects where the techniques are used; gradually increase the number of people who change their way of working. Small successes increase trust.

But the idea that you can get to your goal in small, incremental steps is another idea that many find hard to swallow.

The alternative is to take the “just do it” route: the team decides they will apply these changes on the next project and see what happens. They trust that the coach will act as their safety net. They trust that the coach will catch them if they fall.


XP Days London 2007 – Day 1

Jeff PatonKeynote

The Eurostar and the underground brought Rob, Gino and me to the Glazier’s Hall in time for the opening keynote by Jeff Paton. This was an entertaining presentation about iteration, with old rockers as personas and including bits of music to underline the message.

The talk focused on iteration as a means to embrace change.

Three strategiesRoger the customer sees each story as just “one more brick in the wall”, purely incremental development. Each iteration delivers a few more working stories. Yes… but what if we discover some new information about these stories? What if the story isn’t really done? Where do we find the time to improve, to iterate? Because we promised Roger to deliver more stories in the next increment, there is no more time to iterate. So, slip the release or make Roger unhappy?

There is another way.

Enter John, Paul, Pete and Roger. Each offers us a handy strategy in a song. John tells us to “Follow the money”: we’re in the business of producing business value. So, ensure you know what value each and every story brings.

Story “depth” heuristicsPaul has lots of ways to leave his lover, and lots of ways to do everything that must be done on the project. He tells us to choose as late as possible, to leave our options open as long as possible (remember: Lean and real options).

Iteration ProgressPete and Roger have a plan and a handy heuristic to slice up quality (see picture above, click to enlarge): they can implement any story up to several levels of quality. First they build based on necessity; then flexibility; then safety; then comfort, luxury and performance. Like in the Dimensional Planning method: build a basic version of the story in the first iteration, improve it in the next iteration. Plan to iterate!

Don’t know what I want. But I know how to get it! Pete and Roger have a good thing going: they always have a working system; their customer is often satisfied with a story implementation that does not have all the niceties; they have time left to ensure that the crucial stories are completed with full luxury; they have enough time to iterate, to embrace change. Those are the stories that delight the customers. Because in the end we, like Johnny Rotten , “Don’t know what we want, but we know how to get it!”.

Cue Sex Pistols!

This was an excellent keynote: questioning common practice, clear slides, a sustained methaphor (old rockers as personas by a User Centered Design specialist), sparing but effective use of music (at least for those in the audience to recognize the old geezers…) and enough humour. This presentation was recorded. I’m looking forward to seeing the presentation again.

Understanding the Organisational Context of Agility

Organisational Context of AgilityMichael Feathers’ session was packed full. The presenters in the Gary Weston room in Southwark Cathedral (XP Days has expanded to fill two more rooms in the cathedral) always seemed surprised that so many people came to their “Peopleware” session. In this session, we explored the important aspects of organisations that impact the introduction and survival of agile. Afterward, each group explored one of these aspects in depth. In my group, we explored the effects of an organisation that is mainly organized around projects vs one that is organized around product development.

Each model has its advantages and disadvantages. Maybe a combination of both can bring us the best of both worlds. Or the worst of both worlds.

I took the notes for our group. These will be published on a wiki. I’ll let you know when the results are available.

And then it was time for lunch and 3 more sessions in the afternoon.

The social nature of agile teams

Elizabeth Whitworth presented the results of her research into collaboration and communication on agile teams. She interviewed participants in agile teams about motivation, excitement, “team chemistry” and positive “team climate”; what makes a great team great? Elizabeth’s presentation could have been a bit more “Zen“: less info (we can find that by reading the thesis), more passion, more fun, more about what the people in those teams said and felt. An interesting presentation, we need to know more about great teams, so that we can create more great teams.

Exceptional ideas: How to get your message through

Lasse Koskela presented a few heuristics for messages that ‘stick’: strong messages are D(eep), I(ndulgent), C(omplete), E(motional) and E(legant) and they are S(imple), U(nexpected), C(oncrete), C(redible), E(motional) and have a S(tory). Okay, the DICEE acronym isn’t the most catchy in the world 🙂

After the explanation, we got to create an exceptional message. We had two rounds. In the first round, each group created a message. In the second round, one member of each team went to another team to hear the message. The team then used that feedback to improve their message. Again, I experienced the power of positive feedback: the second version was a lot better than the first. This was a too short, but fun session.

The yellow brick road

This session, hosted by Portia Tung and Duncan Pierce, was one of the highlights of the conference. I’ll post an entry about this session tomorrow.

Thanks to Lasse Koskela for the use of his pictures.