Yola & Co. are unDone-Done…

One of the things I see happen a lot, is the inability of teams to deliver the product they build as a ‘shippable product‘. Due to this, there is a gap between what the Product Owner think is ‘acceptable‘ and what the development team is able to achieve to get things Done. So one of the questions I got is:”How do we make a Definition of Done? Do you have an example?” Beside that, Product Owners are wondering how they can get a feature-team while the rest of the company is organised as component-teams. Fortunately there is a way to cover both aspects with a simple visualisation practice. The two practices I’ll use in this blog are practices I learned from Bas Vodde during my LeSS Training. So lets dive into the case and answer the questions:

• What’s Done?
• How to create a feature team?

I’m going to explain the practice by using an imaginary case about the company Bike Inc. This company is designing and building bikes that should be sold in bike shops. The ‘shippable product’ will be the bike delivered to the buyer, a.k.a. the customer. Exactly as we like to see with increments we deliver at the end of a sprint with Scrum. So how does it work:

1. Take a flip-over and draw the biggest box possible and call it ‘shippable increment’, ‘shippable product’ or whatever suits you best. In our case we could use ‘shippable bike’ but I’ll use just ‘shippable’.
2. Now take your team, optionally extended with stakeholders, and determine all the necessary actions to make the increment/product shippable. In our Bike Inc. case that might be; Design a bike, Build the parts, Assemble the bike, Test the bike (on-road, off-road, wind-tunnel, lab-test, etc.), Ship the bike to the bike shops, make Marketing material for the bike, Sell the bike (including test-drive by customer), Customise the bike for the customer and last but not least Deliver the bike.
3. Now pull all the work that can be finished by the team to the lower part of the flip-over and draw a box around. This box is what your team will call Done. So here it is, your initial Definition of Done. The leftovers is what we call Undone. Undone is what separates a Done Increment from a Potential Shippable Increment. In LeSS this also called ‘The Undone Department‘.

Now we know the gap we can start looking into the next step to improve our Definition of Done and become more mature in creating a Potential Shippable Increment. Now we need to create, what is called, a Feature Team Adoption Map (again this is much used in LeSS). To do so, we need to know what our actual product is.

1. In our case it is the bike itself. Now we have to find the smaller components. In our example that’ll be parts and raw material. So a bike consists out of parts that consists out of raw material. The bike itself is part of a bigger solution, namely the transportation/logistical solution. That solution itself is again a part of a even bigger solution. In our case it is the ultimate solution teleportation solution.
   TIP: If you do so, think about a house. A house contains floors that contains rooms that contains furniture. But a house is part of a street, is a part of a city/village, is a part of a country, etc, etc….You’ll end with the whole universe.
2. Now take another flip-over and draw a X and Y-axis on it. The Y-axis is where you plot the product, its super products and its parts.
3. After this step we need to fill the X-axis as well. Use the actions plotted in the Potential Shippable part to plot on this axis. In the Bike Inc. case I’ve merged Build and Assemble as well as Customisation and Delivery into one.
4. At this point you can plot your current state. In our case it is the full bike as product up to and including the Shipping and Marketing (the green area in the chart below). Unfortunately in most cases teams are Building and Assembling only Parts of the product, like backends, websites or databases only (the red area in the chart below). Like teams are building a backend system but acceptance testing is done after the sprint by key users.
5. Now we know the current state, we like to grow our team from a component team towards a feature team. We can do this step by step and we have to determine our first next step. This can be towards sales by creating a webshop and/or towards product extension like extra accessories for the bike.

One word of warning though, don’t lose the balance between span-of-control and the product coverage by the team. If a team can build and assemble the teleportation solution, they are over-specialised. When a team can build, assemble, test, design, market, ship, sell, customise AND deliver just a part, they are an extended component team.