Release in Tiny Slices

This is one of the biggest and most common problems I see with software teams.

They try to release too much in one go.  

Problems:

• It takes too long, and always longer than they thought.
• Big Bang releases are hard to test and, therefore, hard to release.
• They also tend to block other items in the pipeline.
• They elongate feedback cycles & reduce learning cycles.

Most of the time, the teams convince themselves they cannot release in smaller slices.

The typical stakeholder in a software engineering cycle will be annoyed by a feature taking too much time.  Also, when the feature comes out, it will not be exactly what they had in mind, requiring re-work and causing frustration.

Their innate reaction is to try to provide tighter specifications next time.  They vow to be even clearer to the software team so they can build exactly what they want.

It’s sort of logical, right? If I asked for X and you built Y, we somehow miscommunicated, so if we do a better job at it, we can make it go faster with less rework. 

Let’s build an ever-more-perfect waterfall!

What they do not see is that they are deluding themselves by stating that they understand the problem.  

They don’t. 

They have some high-level ideas, but if someone else had already built exactly what they wanted, they’d buy it, not build it.

They’re building it because it has never been built before, and they don’t understand it. 

So, instead of just trying to think harder and plan better, they must alter how they think about the problem. 

The goal becomes to create a process where we can:

• learn as we go,
• learn fast, and
• maximize our learnings.

If we do that, we can deliver what we need in the shortest possible time. 

What is the way to do this? 

• Eliminate the pipelines.  Get a small team with all the right specialties in a room - virtual or otherwise - and start working on the problem.  Everyone needed to make a decision should be there and available. Don’t be bothered if some people are low on work. The goal is not to spin in the hamster wheel. The goal is to have them available to provide input and make choices, so you maximize global output, not individual efficiency.
• Rough consensus and running code, as they say at the IETF.  Don’t spend all your time planning ahead.  Build something, learn from it, repeat.  No hypotheticals. Get some running code.  This does not mean shooting from the hip.  It means doing some reasonable planning but err on the side of action, not over-analysis.
• Build in releasable slices. You may need some creativity here. Software feature ordering is not always as logical as building a building from the foundation up. Sometimes, you get creative by building slices elsewhere where there is more opportunity for learning.  

I have a recent example, especially pertaining to the last bullet point: We needed to expose a certain existing feature to a new group of users. We could have first built the access control system and then tweaked the feature to make it suitable for the new user base. 

Access control would be the logical place to start, but there is not much to look at alone.  

So, we tweaked the feature to be usable by the new user group and put that behind a feature flag.  It was pretty easy to do, and we could throw it in production right away and test it by flipping on the FF for individual users.

Once we had that down, we realized the feature was not exactly what we wanted, so we changed it a bit, and only then did we build the access control.

Had we built the access control first, we’d have to go back and change it because of the feature modifications we made.  We also would have delayed the valuable learnings about the feature itself.

That takes a creative leap.  You cannot think linearly going from A to B to C, but you must think of “there is so much to learn at point G - how can I leap ahead and get there?”

With everyone involved every step of the way:

• You are more likely to have output that meets your client’s needs.
• You’ll achieve it in a shorter time.
• Everyone will be focused, in flow, less distracted, 
• Seeing their work have a more direct and immediate impact, you’ll have high team member satisfaction.
• By not pipelining, you eliminate wasteful work. No more WIP that you throw away.