workshops

Value Stream Mapping

First time I discovered Value Stream Mapping was when reading the very interesting “Lean Enterprise” book by Joanne Molesky, Barry O’Reilly and Jez Humble. The final version of the book will be released in December but the early release version is available for download at a lower price since a few months now.

A Value Stream Mapping is a method from lean-management that allows you to quickly visualize the flow of value delivered from the genesis of a project until the customer delivery. It has originated from manufacturing but it can easily be applied on software development as explained in “Lean Enterprise“.

The exercise is pretty straightforward, you just have to write down all the stages that are necessary to bring an idea to its delivery and write under each steps the Lead Time (LT) and Value Added Time (VA). The Lead Time is the elapsed time needed to arrive from a stage to another and the Value Added Time is the amount of time really spent on that step where value has been added (the real work)

When working with huge companies where there are a lot of processes and departments, the exercise might take some time to accomplish as you’d need to meet people from all the different department involved in order to collect all the data. For us it was quite easier as it took us only one and a half hour to end-up with this:

(Pink post-it notes represent process stages, LT and VA are written under each)

First thing to do is to select a recent representative project (the kind of project your company is used to do in terms of size, people involved …) and obviously one that has been released to the customer! Invite enough people to be able to determine all the steps and find out corresponding LT and VA. We were only 3 to perform the Value Stream Mapping (a Business Analyst, the Head of Development and myself). As soon as all the steps have been found out, we used time tracking and reporting tools to get the exact amount of time spent on each steps (the VA) and when exactly those started. Some of the steps might be done in parallel and iteratively, that’s why some sticky notes are under other ones (in that case the corresponding VA is the sum of the whole column).

As soon as you have written down everything, just sum up all the VA’s and LT’s (some conversion might be needed here as some figures might be in days and other in weeks or months) and divide the total VA by the total LT to find out the Value Stream efficiency rate. The lower it is, the bigger is the chance to easily find some process improvement ideas!

The very interesting part starts at the end of the exercise! Well, you know, everyone might have in mind where usually things are stuck and where you might need some improvement to speed the value flow. But having the Value Stream in front of you clearly helps to focus.

The Value Stream is the perfect medium to start collaborating. Invite a couple of key people to join (from development and business side) and talk together in order to find out what could be improved in order to speed up the flow of value delivered and avoid wasting precious time. List out all the ideas and try them! Redo the exercise later on and check if the efficiency rate increased!

You will get a better understanding between all the stakeholders of how work moves through the company. People from different departments and having different point of views join together and collaborate to improve the whole company’s efficiency.

Mission accomplished!

This article is the third out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

Written so far:

Event Storming

In the previous post you read how Impact Mapping gives you the goal to reach and what are your options to do so, now it’s time to get more into how the system works.

An Event Storming session will involve almost the same people as for an Impact Mapping’s one but the aim is quite different!

Event Storming is about to find out all the events that occur in the system -> the business processes.

As Alberto Brandolini says:

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

Domain experts, the business people, know the system by heart and their job here will be to answer to a lot of questions! Those questions will be asked by a mix of different people (including developers, team leaders, testers, …), bring the curious ones!

After an ES session, everyone should be able to share the same vision on how the system behaves and the icing on the cake: everyone should share the same language to describe this (see the Ubiquitous Language).

First of all, you’ll need to find a big wall that you’ll cover with plotter paper or electrostatic sheets in order to be able to put sticky notes and maybe draw some lines and write text. Get some markers and different colors sticky notes. Decide to focus on a particular part of the domain (unless this could last more than a day!) and start by asking this simple question to your domain experts: “What’s the most important event that should occur in the system?”. If you’re working for a company that sells things on the Internet, and that you’re focusing on the ordering process, the answer should sound like “Cart checked out” or something similar. Now that you have that specific event, act as a time machine and try to find out together with the domain experts, what happened before this one. Write every single event on sticky note and put them in the right order.

Follow Alberto’s advice: Here’s the dogmatic color coding for #eventstorming follow it or perish! :-) (source)

This first part of an ES session really focuses on outcomes. Here’s a simplified version of what you should have:

CustomerLoggedIn->ItemSelected->ShoppingCartValidated->DeliveryAdressConfirmed->PaymentAccepted->CartCheckedOut

Now that you know everything that happens before a cart is completely checked out you can focus on the causality: the corresponding commands that lead to those events. Put another color – blue if you don’t want to perish ;-) – sticky note on every events and write the command name (you can also draw the actor that fires the command – User/Job/Time/…). Here’s another simplified version of what you should have:

LogCustomerIn->SelelectItem->ValidateShoppingCart->ConfirmDeliveryAddress->ValidatePayment->ConfirmOrder

Look what we have here? The method names of the not yet written application code! How could you be more close to business people if even your code speaks business? ;-) That’s the point where your code really brings business value!

And where the magic happens is when the QA tester can even start to write BDD styled tests during the ES session:

Given a Customer Logged In
When he Selects an Item
Then the Item should be selected in the Cart

I must admit this is a too simplistic example but you get the point, right?

At the end of an ES session every people involved knows exactly how the system works and behaves, what are the events that should occur and their corresponding command (and actor). You should be able to point out potential conflicts or missing concepts but new opportunities as well! Last but not least, everyone shares the same language and did speak together!

Mission accomplished!

Bonus: If you’re into DDD, Event Storming can even bring more than that as you’ll be able to find out the Bounded Context and Aggregate Roots of your system.

one.hundred.acorns

Bridge the gap between dev team and business people! – Idea #4

Value Stream Mapping

Bridge the gap between dev team and business people! – Idea #3

Event Storming