In response to “Shoulda, Woulda, Coulda, Did…”

In the above linked blog post, the concept of a 51% solution is brought up:

I am a big fan of making informed decisions, embracing the 51% solution, committing to action, and collaboratively addressing the remaining 49% during execution.  Those who prefer the 100% solution before taking action continue to hold the rest of the team back.

The idea made stop and think about what a 51% solution really means…

• More than half of a solution

• The majority of the solution

• Less to go than already completed

• Not committed but heading in a direction (notice I didn’t say the ‘right’ direction)

Not brain surgery here, folks.

This concept reminds me of my latest professional deep dive, Scrum (go here for my threads on being Scrum Master).  More specifically, it reminds me of the third principle of Agile software development:

Responding to change over following a plan

Agile (Scrum is an implementation of Agile) is all about being flexible and Scrum is all about a team of individuals building a product over iterations.  In Scrum our team works in two week iterations.  We define the direction we are spending our two weeks heading in, and then we ask the product owner to give a little slack on the leash.  Then off the developers go, coding while breathing freely.

This is because we have a 51% solution at the beginning of each sprint (sprint = two week iteration).

At the end of the sprint, we have a working product that is more functional than it was two weeks prior.  If the product owner and the stake holders decide they sent us (me being the Scrum Master and the rest of ‘us’ being the development team) down a slightly crooked path, well guess what, better to find out two weeks later than at the end of the whole product development cycle.

There is no way we could define everything up front at the beginning … there is no 100% solution that is 100% what would fill every desire at the end of the product development.

== Update 01MAY2012 ==

So I don’t think I really finished this post.  I’d like to take a few paragraphs to tie how the 51% solution is really implemented through Scrum.  In the 51% image above, we always take about half of the distance to the ‘goal’ in a single leap, or sprint.  That is not how Scrum works.  Sprints are set periods of time.  A more Scrum/Sprint-esque image would be:

A few key points here are:

• The goal is a cloud, no hard set point in the future the Scrum Team is aiming towards, but rather a vision.

• Each line is (supposed to be) uniform in length.  Sprints are set length iterations.

• As the path veers right, a major change in direction occurs sprint 3.  For the rest of the Sprints shown, the Scrum Team continues that direction.  Change is ok!  But all the lines are straight, change in the middle of a Sprint is possible but definitely not encouraged.

The 51% solution with regards to the Sprint showcases a Scrum Teams ability to create potentially releasable products at the end of each Sprint while still being able to course correct for the next Sprint.  51% means that there is a direction, not necessarily the exact same direction you will be going in the end, but a direction for progress.