Delivering Less means you Deliver More – the benefits of delivering in smaller batches

Let me tell you about I had a conversation with a friend, about the most efficient way of delivering software.

My friend loved taking on new pieces of work. She has an excellent work ethic, and hates not having work to do.

If her work became blocked – BOOM – she would find another deliverable to work on

If she had finished developing and testing something …. WHAMMO – straight on to the next piece of work

Her work efficiency is very impressive, however, how can I tell this person, who is so focussed on being busy, that by doing less, she can deliver more?

So I created a little game.

I got 20 pens (10 for her – 10 for me).

I broke up the pens into their individual components – the body of the pen – the ink cartridge of the pen, the lid, and the small plastic base of the pen.

I asked my colleague:

Is it quicker to build one pen at a time, or is it quicker to begin work on all the pens and focus on one part at a time for all the pens?

“DEFINITELY working on all pens, building one part at a time”

Just as I expected! The challenge was on!

• I was going to build one pen at a time
• She was going to complete all of the components before moving to the next component
• We would see who was completed first

Aside from learning which technique was faster, we also learned some really interesting things.

1. Within a few seconds I had a pen to Sell – Ship – Make Money faster – KA-CHING!
2. Immediately after selling the pen I could get customer feedback
3. After each pen I could check the quality
4. I could learn about how I was building the pen after completing each one and alter (In fact, midway, I began testing the ink earlier in the process to eliminate waste)
5. I had less inventory to manage

Lastly (and to her great surprise) – the big learning point for my friend

6.  I WAS FASTER!!! I WON THE RACE!!! GET IN!!!

(subsequently I have run this game a lot of times – the lean approach of delivering one pen at a time is always faster by ~ 20%)

So by focusing on one deliverable at a time I delivered quicker, and delivered more, I delivered in a more efficient way, I had less risk of a flawed product, and I made money quicker.

I could sense my friend was beginning to waver on her stance.

I wanted to hammer home the point, so I drew two very simple Cumulative flow diagrams, for two hypothetical Software delivery teams both building an identical product at the same rate.

The first cumulative flow diagram depicts a team delivering less frequent, larger batches of pens		The second cumulative flow diagram depicts a team delivering more frequent, smaller batches of pens

To finally convince my friend, I illustrated through these charts that, even when we build at the same rate, by having more shipments, and less work in progress, we simultaneously reduce the risk while increasing the value we can reap from our product.

With my friend convinced, our conversation turned back to our pen production line race. We applied what we learned to a software development team. We believed:

• We could build faster when we had less deliverables to manage.
• We could release easier with smaller releases
• We could reduce risk by having less moving parts in each release
• We could learn more responsively how our application performs in production with frequent, smaller releases.
• We could have a shorter time to market
• We could add value earlier by releasing an MVP earlier.
• We could get feedback from our customers earlier
• We could tune how we build our software with a shorter delivery feedback loop.

This is something my team put into practice, and the rewards have been hugely beneficial. To get to this point we have had to remove a number of obstacles that were in our way. Waste work and blockers become magnified with frequent releases and this has fostered a leaner way of thinking about our delivery process.

Working with a bottleneck – capturing an opportunity

Most teams I have worked on have a focus on maximising throughput. My team calculate how much work it will take to complete a goal or a set of goals. We chart how much of the work we complete week on week accumulating (burning up) towards the goal that we are trying to achieve. We can usually trend this progress quite well, and achieve good predictability as to when the work will complete.

We prioritise our work based mainly on what feature will give most value. We try to identify a way of incrementally releasing value to our client with each story. However pragmatism allows us to span more than one feature at a time if we are throttled in any way on the highest priority, and in this way we can continue to release value to our client.

Recently however, the team I was working on were facing a real world deadline. We had to deliver a feature in time for an immovable date, and delivering would generate a huge opportunity for our company.

The problem for us was that part of the deliverable included building a new panel on a screen. Experience had told us that for this work it was in-feasible to develop more than one story at a time.

THEORY OF CONTRAINTS: every process has a single constraint and that total process throughput can only be improved when the constraint is improved

We had a naturally occurring bottleneck: Development of a new panel on screen.

While our general trend indicated that we would be confident of hitting the dates needed, we realised that the sequential nature of the GUI work would push us well past the date.

We had to find a way of working through this bottleneck in order to successfully deliver.

The solution came from our understanding of working with the theory of constraints

We had already pinpointed our constraint, Next step was we needed to find a way of maximising this work, even at the expense of the teams overall throughput.

Once we cracked this, the implementation of the solution was straightforward yet difficult;

• We paired on these stories throughout, allowing one person to peel off and prepare the path ahead for the card when necessary.
• We kept the next piece of work queuing before the development phase to enable this work to begin from the moment the previous card had moved on (thus keeping the development phase of the new panel for the screen constant.)
• Finally, immense dedication and sterling effort from the team seen them work extremely hard, and for long hours.

Our focus on general throughput was replaced with a targeted feature delivery. Our option of working on multiple goals was removed and we understood that streamlining anywhere other than our bottleneck was not going to increase our supply of this work. It is clear that our application of the theory of constraints facilitated our successful delivery.

Liberation through Kanban

It is just over a year since my team began its transition away from Scrum using Kanban. It has seen many rewards and in my opinion it has been an unheralded success.
Seeing the successes and gains that my department has had in this transition, I frequently question why it is still a minority of software teams that even attempt this transition.
Obviously a lot of Scrum teams are getting a lot of value and producing a lot of value at high quality, so it deserved a closer look.

The first element we tried to change was the removal of the sprint planning meetings. This was often quite painful for us;
First of all we had to rush to prepare at least enough stories to fill our sprint.
Second of all we would spend quite a lot of time deliberating exactly what and how something had to be built in order to debate how many story points a card should be.

After over a year of these planning meetings, there was a growing feeling in the team that there was very little value in these estimates. We attempted to fit our story points into a velocity of Story points, which is calculated based on the number of story points achieved in previous sprints. (a made up number that matched a made up number – seems self fulfilling)
We felt it was flawed scenario that was of no benefit – it didn’t help us get more done and it didn’t help us understand how close we were towards completing our goals.

Furthermore, by having variable sized stories we were able to mask the immaturity in our story refinement, and in breaking down the goals we were working on.
After a number of weeks into our transition away from this planning session, I noticed that we missed something from our Scrum days – there was more confusion around what the team were supposed to build.

The planning meetings were creating a by-product of valuable discussion about the teams work.
In a separate initiative, we had started to move to bring in acceptance test driven development, with a huge emphasis placed on a discussion of the behavioral change that was being introduced with each story.*
Using specification by example we also gave extra clarity on what was the changing behaviour. This encouraged collaboration with the business at a feature level for the sake of the feature and not for the sake of a plan. Furthermore this healthy Collaborative discussion helped increase questioning of WHY and allow value to be scrutinised. We ended up with a far more effective story to allow us deliver business value.

This breakthrough became a huge lesson for me. I took two key points from it.

1. We could always define our own way to work through problems, without resorting to a defined process in order to solve our problems
2. By removing a set of rules, it empowered the team to be more creative in finding solutions.

Work through problems without defined process
Another example of where the team initially lost out by abandoning scrum was through the absence of a sprint goal. I always liked this idea in Scrum. We would set the goal and it helped the team to focus on a milestone for the sprint. By going completely scattergun with the set of live priorities for the team it meant that there were times when team members were silos each working on unrelated work items.
Was there another way to maintain this? Well, one of my colleagues on another team set out goals for his team. We defined Business driven goals and to deliver these goals we defined stories that released the value of these goals. and would attempt to limit the team to 2 rolling concurrent goals at a time. It was a simple yet elegant solution which gave us back the benefit of scrum goals without needing to enforce the iteration.

No rules = more creativity towards solutions
A short time after we transitioned away from Scrum, I began to read about Douglas McGregor’s Theory X and Theory Y. Theory X is based on the idea that workers do not want to work, and need to be controlled. Managers that subscribe to this belief adopt a command and control style.
Theory Y assumes that workers are self motivated and gladly take on responsibility.
My experience is that in knowledge based work, the participants are overwhelmingly Theory Y based.
It is my opinion that by holding the prescriptive set of rules regarding planning, estimation, artificial sprint deadlines, the enforced sprint review and sprint retrospective, it stifles the theory Y based worker. Our planning meetings were so painful, the result was the plan – not about creating value for the company. Our sprint was about standing over our plan and an artificial deadline emerged as we tried to justify our commitment.

The ominous looming of a deadline reduces options and causes people to panic – this effects quality

By freeing ourselves from rules and by visualising where we had bottlenecks and blockers, the energy in the department became focused towards creating flow for the work and eliminating waste.

Conclusion

I understand that people can be quite partisan towards the way they work. People are emotionally attached to the way they work because they have invested so much. I don’t believe this is the case here. I am a Certified scrum master, and received a lot of Scrum training and read a number of books about Scrum. When my team practiced Scrum it was far from being a flawless process.
Some people will argue that we weren’t doing Scrum right so no wonder we had problems. But this is the crux of my problem with it – so much effort goes to doing scrum instead of channelling that focus to building better software, faster.
For my team, using Kanban to liberate us from a prescribed process and visualising the way we worked allowed us to have this focus.
I think there is a misconception that Kanban is a process and directly comparable to scrum. I don’t see it like that. I see Kanban as a set of practices which helps teams define their own way to work with absolute freedom. It wraps around your way of working and helps you refine it.

Certainly the results were powerful for my department.

In February 2013 A single card averaged 29 days to get acceptance from the Client

By August 2013 that average dropped to 5 days.

In the same period the average days days to production went from 53 days to 19 days

(These measurements were made on a legacy application, beginning a few months after already starting to use Kanban, and stop using Scrum. Some of these improvements had already started to manifest in lower cycle times. We stopped measuring these particular values after September 2013 as we had stopped getting value from the measurements, but on newer applications I have seen regular stories drop to prod in one or two days.)

Teams will use what works for them, and rightly so. Change for the sake of it is not good. I completely understand successful Scrum teams not attempting this approach, however I believe there should always be a focus on improvement. We have gained  a lot by making this transition, and would urge other teams to experiment.
With Kanban the ethos of continuing to strive to improve is one of its most valuable attributes. Liberating workers from a set of rules regardless of how light they might appear can have a big impact.

*Gojko Adzic describes a story as a promise for a conversation – a cracking way to open up potential for every desired deliverable.

Whats done is done …. sometimes

Ah the age old discussion – what is the definition of done. Everyone’s favorite subject!

I know a lot of software developers have been through the debate of whether a card done when the code is committed? Or when the tester has finished testing? Or is it when the client has given the thumbs up? Even then a lot can go wrong before it is live. Are the release notes sufficient? What if there needs to be a rollback?

I remember when my team started to count done as being deployed on the production server. It felt like a really progressive step. As if we had started measuring ourselves (be that poorly or well) against the highest of standards.

Over the last couple of months I have seen that to be shortsighted.

This week my small team has released a very small minimum viable product of 10 stories to a live product server, fully exposed to our client.

A Triumph!!! This means those 10 stories are done surely?

Well perhaps not though when we scrutinise the circumstances

First of all our client upstream is not yet ready to use our application … OK so maybe there will be a little bit of tweaking for integration – that’s no problem, so we take care of that and we are done, right?

Well no! Even though our application is correctly receiving input and producing the correct output in a production environment – everything the MVP was mandated to do, our downstream consumer is not ready to accept our messages. If our messages are going nowhere can we really say that the cards are done?

Finally when our downstream consumer is feeding from our applications output correctly, we have to be able to say that our cards are done – case closed -nothing more to see here – move along.

No disputes???

Well how much value are these cards adding? If we don’t know and haven’t looked to measure its success are we really done with that card? If we have not added the required value are we really done with a business goal? Clearly not.

In my opinion, done needs to be measured and success proven before we finish a card, otherwise we are blindly adding unused functionality that may be building incredible efficient and stylish waste.

Why should we care about cycle times?

What on earth do a development team care about Cycle times? After all what is it really for?

What do I care if it management want some bullshit metric to measure teams with – that doesn’t make it valuable to us. We can’t do our jobs better because of that.

OK so management can use cycle times for planning – but I don’t need to know about that. I just want to get on with developing the product.

Granted, if we have short cycle times we can release the software more quickly then the company can make money on it sooner. But its not like the money wouldn’t be made eventually.

Yeah – I suppose if we released regularly then my jerk of a boss would see what we have done and wouldn’t scream at me for building the wrong shit.

Then my jerk boss makes us hack in the right solution at the end of the project for 3 weekends straight. If the code wasn’t full of last minute hacks then my boss’ precious cycle times wouldn’t be so long!

Alright Alright I admit, by having shorter cycle times then I am probably going to have less things at any one time to work on, and my focus and attention can be given to one work item and prevent context switching.

FINE!! – short cycle times mean that the client will see our progress and have faith in what we do, but does that help me do my job? Trust between my team and the client is great but how does that let us build something better?

Alright – fair enough – I guess by having the clients trust I won’t have to listen to them tell me how to do my job and have them constantly checking up on my every move.

Okay Okay okay – other than quicker releases, better return on investment, fast feedback, cleaner solutions, less context switching, gaining the trust of the client, what have the Romans ever done for us?

The Story of Why

In Order to <INSERT BUSINESS VALUE>

As a <INSERT BENEFICIARY>

I Want <INSERT BEHAVIOR>

Seems obvious doesnt it?

Apparently not!

I think it is easy to fall into the trap of stating…

What Who and How 

….instead of…

Why Who and What

All too frequently Client stories are missing the Business Value

• If we cannot visualise the Value of a story then we are powerless to prioritise the work.
• If the Value of a story is not apparent then we are unable to know if our teams are helping business to make more money

 

To take a highly disguised example, which is somewhat typical on many teams  :

 

This reads to me as What, Who, How

Basically we are looking for Why, Who and What

First thing to scrutinise is, whether it is clear to all parties how is this offering business value?
“filter stuff based on a specific value flag” doesn’t clarify that in my opinion.

Second of all having the “As a” section as another application is a big warning sign that the story may not be cross functional

Last of all for the “I want” section it is clear in this case there is a clear instruction of how this should be implemented, and this eliminates the freedom of the developer to identify the best solution

 

An arguably better version of this could be:

In order to prevent the overhead of processing superfluous messages
As a consumer
I want to filter messages based on a specific value flag.

Perhaps a lot of people think ‘So What!!’ about the fastidiousness of this, but it IS Very important for a number of reasons:

1. By revealing the business value, you are enabling the team to have the potentialto identify a better solution
2. If the team clearly understand the business value, they can be ruthless in not creating wasted gold plating.
3. By removing the HOW part of the story, you are giving the freedom to the team to implement the solution in the way they see fit.
4. By stating the direct business Beneficiary, you are creating a vertical slice of the application instead of a horizontal slice.
5. Visualising the value gives clarity for providing clear prioritisations.

Sorry Eric, you are a genius and the King, but we will engage our brain before doing anything thanks!

Business Driven Goals – Why > What > How

 

​

Whenever I am presented with a problem I usually jump straight in and start to think about the solution. It is a natural inclination I have to create a link between my knowledge and understanding, to the solution. I think that most people behave instinctively in a similar manner.

 

In that regards, I think it is very natural that when presenting a team with a feature that is to be developed, the language used is often based around HOW to create the solution.

 

A recurring problem that the teams I have been on, and our customer faced was to make sure the requirements defined WHAT is needed, and not HOW it was to be built. Over time this approach has been cemented, which was a very positive step forward.

 

It has allowed the team the ability to collaborate and Identify how best we can create a solution.

 

More recently we have started to be much more focused on defining stories based around the business value. It allows all members of the team to be conscious of the exact value being added with the work being done and keeps the work on focus. 

However, the feature that is being delivered is specific in its definition, so any attempt to define the business value for a story is inferred by the team. With a small amount of luck, the business value of the story will match the business value of the goal that the feature is trying to satisfy. 

But …the team has not been told WHY the feature is to be built.

 

Quite possibly, the feature selected is not the best way to satisfy the business goal. 

Just as there is cognitive bias attached to presenting HOW to build something ahead of WHAT to build, there is a cognitive bias in presenting specifically WHAT to build ahead of WHY there is a need to build something. In each of these scenarios we are narrowing the scope of ideas.

 

We have previously learned that:

• By presenting a team with the steps to build a solution, it blocks them from creating better steps to the same solution.

To follow that same train of thought:

• By presenting a team with a solution to a business goal, it blocks the wider collaboration in thinking of better solutions.

 

By understanding the business goals that we are trying to achieve we improve by:

• Allowing teams to focus their efforts solely towards achieving that goal, and not wasting time exceeding the goal.
• Eliminating scope creep on features
• Eliminating pet projects
• Letting teams see which actions bring the goal closer
• Letting the team learn from steps that do not bring the goal closer

Lets be real – If a client decides that a feature will be of business value, and is paying for the feature to be built, its simply not feasible to suggest that the business goal be shared and that other solutions be explored. 

 

However, what should always be feasible is that the team can find out the business goals behind each feature, and also find out how to measure when the goal is complete.

So when we are looking at our goals, lets start with WHY, then we can look at WHAT, and eventually move to HOW.

 

What are our Kanban boards for?

Our Kanban boards act as a Kanban system (important to distinguish this from the Kanban method which means something different).

The Japanese word Kanban literally translates to Signal Card.

By extension of this literal translation, the Kanban system is a ticketing system that allows us to manage the work items.

Real World Kanban system

An obvious example (that I think everyone has heard of) is the Starbucks coffee cup

OK so we want a coffee and we pop in to Starbucks, queue up and then order a coffee.

The person with the funny haircut at the counter creates Kanban, of a specific work type.

That is, they pick up the relevant coffee cup and writes down the type of coffee chosen, the milk type, the extras selected, and name of the customer.

When there is a person free to make coffee, she will grab the next empty cup and make the coffee to spec.

Then there is a guy handing the coffees out to the customers – they pick up the next coffee and call out the name of the customer and hands it over.

A nice simple Kanban system in action.

Flow V Pull in Starbucks

Now think about what happens when the shop is not busy – we walk in, give our order and it is made immediately – super quick.

If the shop is busy, then maybe the person taking orders will also help out with making the coffee. That means that we might have to wait a little longer between getting our coffee, but we know we will get it soon enough.

This highlights the importance of flow efficiency and how it is better than an environment where we have to pull work items into progress.

Flow if you can, Pull if you must

Knowledge based teams Kanban Systems

It is similar to how our work should be managed on our boards, however with Starbucks there is an extremely important distinction.

In Starbucks the output is a very tangible cup of Venti Vanilla Soy Double-shot Frappucino. The Kanban is attached to the physical output all the way.

We are lucky enough to be involved every day with knowledge based work. However there is nothing tangible to attach to our work items as they move closer to completion.This is an important distinction.

It means that we should only use the Kanban boards as:

• a communication device
• A tool to manage our work.
• A visual aid to interested parties to the status of the work – a mirror to the state of what our teams are doing right now.

If we have failed to use he board to manage our work cleanly or communicate effectively then we have jumped the shark just like Fonzy!

Flow V Pull in knowledge based work

Going back to the Starbucks example – during a busy lunchtime, Starbucks are forced into a state of Queuing, and that causes delays.

In our environment we can try to control that. We want to have a good flow of our work and increase the efficiency of our working ways

(when I say efficiency, I mean reducing the amount of time our cards are not being worked on. If a card has a lead time of 10 days, and it spend 2 of those days in progress, and 8 days in waiting, then it has a 20% efficiency).

If we have a card with poor efficiency, then it is an indicator that we have not managed our bottlenecks well, and we have not tuned our WIP accordingly.

High efficiency is not the goal we are trying to achieve but can be a measure of how well we are managing our work items.

both the first and last finisher in the marathon had 100% flow efficiency

Going back to the Starbucks example, go into any busy Starbucks at lunchtime and you will never see the coffee machine inactive. They are controlling their bottlenecks to have maximum efficiency. They might even have more than one machine, attempting to reduce the burden on the bottleneck, and improve the flow, getting as many cups of coffee out as quickly as possible and make bucketfuls of cash.

And so it goes for us. We should constantly look to where our bottleneck exists and maximise and alleviate it.