Oct
27

Business Value with Systems Thinking tryout

Business Value Modeling is fun

Yesterday, I did a tryout of the “Business Value by Systems Thinking” session for XP Days Benelux.

A “Business Value Model” is one of many models our teams build to get a better understanding of the problems we need to solve. Based on the goals of our stakeholders, it shows

  • what “value drivers” (or dimensions like “income”, “customer satisfaction” or “employee retention”) are part of our shared definition of Business Value.
  • how we can measure that we get closer to (and finally achieve) our goals during and after the project
  • what constraints limit us in our search for solutions
  • how all of these things are related in a systemic model. For example, what do you think happens with employee retention if customer satisfaction goes down? What effect, if any, does shorter employee retention have on customer satisfaction? These and other causal loops may point the way to “leverage points” where we get most effect with the least amount of effort.

By building the Business Value Model we create a shared vision and align the team members. By relating all our work to the value we add, we are more motivated.

Feedback

As usual, there was much too much content. Thanks to the feedback of the participants, there will be more time for exercises and explanation, we’ll go more in depth into the real subject of the session and there wil be more feedback for participants on their model.

You can download the  tryout retrospective feedback and see what the participants thought about it. I’ll publish the output of the session in the next blog entry.

Many thanks to the participants for playing along and giving useful feedback. Thanks to Cap Gemini for hosting the event.

Answering some puzzles

  • How do you prioritise based on the Business Value Model? You start with the lagging (final) goal that you want to achieve/improve first. What would it take to “achieve the goal” or “improve enough” (first define what “enough” is)? How little can we do? Do we need to mitigate some risks? Do we have enough value to release? If yes, start implementing. If no, which other goal do we need to tackle too?
  • Does “Business” Value mean only financial measures? No, we also include other measures like “customer satisfaction”, “employee retention” or “happiness” (we just built a Business Value Model with “Number of people who happily use our product to do their job” as the #1 measurement). Some of those “measures” can’t really be expressed as a number, you can only see if they improve or worsen. On the other hand, Don Reinertsen recommends “if you want to be able to make (quick) tradeoffs, you should express each measure in money” in his book “Flow”.
  • Is our model right? What is the perfect model? What should the final model look like? I really can’t answer that question. Your model is “right” (or: useful) if it helps you to make good decisions, if it helps you to explain the reason(s) behind your project, if it allows everyone on the team to make decisions. In the end, you test your model(s) by building something according and seeing if your hypothesis was correct. And even if it isn’t, you’ve learned something. What we’re doing here is using the scientific method: we build a testable hypothesis, we perform the test and we improve our hypothesis based on the results.

Sep
28

Usergroup meeting 26/10/2010

XP Day session tryout: Agreeing on Business Value with Systems Thinking

Cap Gemini will host the next Agile/XP Belgium usergroup meeting. This session is a tryout for XP Days Benelux.

We talk a lot about “maximizing business value”. We ask business people and product managers to prioritise by estimating the business value of user stories. But what exactly do we mean by business value?

Over the past few years we’ve worked with many teams to define their “Business Value Model”, a clear definition of the value a project will bring to the organisation. The exercise hasn’t always been easy but it has always brought significant benefits:

  • Measurable business value in units that impact the organization (such as revenue €€€, customer satisfaction, staff retention)
  • Everybody involved was more motivated because there was a clear reason for the project and they finally understood what it was
  • The whole team was aligned around one vision because we had clear criteria to define success
  • We came up with more innovative solutions because everybody on the team, not only “the business” or “product managers/owners” could take product-related decisions based on the model
  • We could deliver a lot faster than anybody expected because the Business Value Model allowed us to easily distinguish between value-adding and non-value-adding features
  • We spent a lot less time writing and prioritising user stories because we were able to derive the user stories from the value definitions
  • The Business Value Model guided us to explore new product ideas: the business value model was a hypothesis that we could test and refine each time we released or performed user testing.

In this interactive tutorial you’ll apply some Systems Thinking techniques, such as the Diagram of Effects and Intermediate Objectives Map) to define the business value model of an example project. We’ll show you the techniques we used and discuss how you can apply those techniques in you context so that you’ll be ready to start building a business value model with your team.

Agenda:

  • 18:00 – 19:00 – Welcome with snacks and drinks
  • 19:00 – 21:00 – Session

Address: Bessenveldstraat 19, B-1831 Diegem, Belgium

Register here for this free event

Sep
26

Usergroup meeting 05/10/2010

XP Days session tryout

IHC hosts the next Agile/XP Belgium usergroup meeting. There will be two sessions in parallel

Session 1: “A journey into Database Change Management” by Jochen Jonckheere and Pascal Mestdach. This is a tryout for XP Days Benelux.

Abstract:

We will bring you the story of our journey into database change management. We share our experiences with concrete examples/common situations and explain the different parts of Database Change Management along the way. During our journey we encountered several problems. We let participants reflect on how they would solve these problems, before we show the solution we picked. This is an interactive technical session where you will see 2 developers working together, writing some small sql scripts, breaking and fixing automated builds and even in the end a tool for handling Database Change Management in an automated way in the .NET environment.

Session 2: To be decided

Agenda:

  • 18:00 – 19:00 – Welcome with snacks and drinks
  • 19:00 – 21:00 – Parallel Sessions

Register here for this free meeting.

Address: Legeweg 157 E/02, 8020 Oostkamp, Belgium