Monthly Archives: June 2012

Release Dates in Agile, Not Taboo

I’ve heard a lot lately about how it’s not-so-Agile to set release dates for major features, epics, and projects.  Some are uncomfortable being given a date (mainly teams) and others are uncomfortable without a date in hand (mainly, Product Owners, executives, and stakeholders).

This very much a myth to be dispelled.  Dates do not go away with Agile!  Rather, it is how we predict and communicate dates that should change.

With Agile, release dates are fixed based on time-boxed iterations.  In our case, we tend to release after every sprint, so there is always a release date every two weeks.  Therefore, by nature of time-boxing, the schedule is a fixed constraint.  With the schedule being a fixed constraint (as is cost based on team size), it is scope that remains flexible.  So, the scope that is included in any given release is flexible based on what the team was able to accomplish, what stories get dropped, what natural disaster impeded the team, who was out sick, and so on and so forth.  Whether that scope accomplished is acceptable for release to production is always a Product Owner decision.

Second, what’s critical to understand is that in Agile we PREDICT.  We predict dates for major features, epics, and projects.  In fact, everything we do in Scrum is in support of us all getting better and better at predicting or being predictable rather … Capacity, story points, velocity, release planning, etc. Furthermore, the closer you get to any given date, the better you are at predicting it and the greater the confidence too.

With that understanding, how we communicate dates needs to be adapted for our Agile world.  First, we should modify our language.  Rather than say “Project X will be released on 7/1” let’s say “Project X is predicted to release on 7/1 and the team has an 80% confidence in that date”. Second, we should always remember that with schedule and cost as fixed constraints, scope is flexible. So, we might say “Project X 1.0 with A and B features is predicted to release on 7/1 and the team has an 80% confidence in that date”.

With some education around this topic we will all be better able to talk dates without the taboo of it not being Agile.


Our Evolution of Sprint Reviews

Since going full-fledged Agile in the Fall of 2011, Valpak’s approach to Sprint Reviews has evolved.  Towards scaling Agile, we’ve been regularly inspecting and adapting (as you would expect) across our 9 Scrums and 1 Kanban team.  Today, we have a Sprint Review approach in place that operates like a well-oiled machine and also scales well as you add more teams.   Let me share with you the evolution of our Sprint Reviews.  But first, some background on our Scrum process …

At Valpak, we sprint in 2-week iterations running from a Monday to a Friday across 9 teams and 50+ team members.  Because of heavily integrated systems and environments, all teams sprint on the same common sprint schedule.  This means that all teams hold Sprint Planning and Sprint Reviews on the same day.

Sprint Review 1.0: The Every-Team-For-Themselves Approach

Our first take at Sprint Reviews was pure madness!  Each ScrumMaster would schedule a separate 1 to 2 hour meeting on the same Friday for each Scrum team.  That’s nine 1 to 2 hour meetings within an 8 hour business day and on a Friday no less!  That approach works fine for Sprint Planning, which doesn’t involve the stakeholders, but royally sucks for Sprint Reviews.  As much as the ScrumMasters tried to coordinate the independent Sprint Reviews, stakeholders would receive overlapping meeting notices and were forced to decide which Sprint Review to attend and which to miss.  With much confusion and chaos, we quickly discovered that teams had many stakeholders in common and that we needed a Sprint Review approach that allows stakeholders to see demonstrations from all the Scrum teams they have a stake in.  It’s just not possible to be in two, three, or even nine places at once!  Logistically this approach just didn’t scale. 

Sprint Review 2.0:  The 180-Minute-Marathon-Mob Approach

Our second take at Sprint Reviews solved the logistical problems of the 1.0 approach and scaled much better, but still wasn’t quite right.  Our 2.0 approach was basically a single Sprint Review across all 9 Scrum teams.  Quite frankly, it was an exhausting 180-minute marathon with a mob of stakeholders in the biggest room we could find.  Each team would go up to the front of the room and present for about 20 minutes.  This included a review of the Sprint accomplishments and metrics from the ScrumMaster followed by a demonstration of working software by the team members.  This approach certainly proved that we can successfully aggregate the Sprint Reviews across all teams for all stakeholders, but it had some challenges of it’s own.  First off, trying to pay attention to anything or anyone for 3 hours straight is a challenge; even more so when you have people that aren’t necessarily professional speakers.  Second, there was just too much dead air and awkward pauses with constant switching of speakers, teams, laptops, decks, etc.  The result was a disengaged audience of stakeholders.

Sprint Review 3.0:  The Science Fair Approach

The challenges of the 2.0 approach to our Sprint Reviews led us to a modified approach we call “The Science Fair”.  Our 180-minute marathon of Sprint Reviews was shortened to 90-minutes with each team presenting for just 10 minutes each.  Within that 10 minutes, the ScrumMaster provides a condensed version of the Sprint accomplishments and metrics and the team demonstrates only the sexy stuff (via live demo and/or presentation format depending on the feature).  Oh and, we now incorporate handheld and table-top microphones to better project the voices of the speakers.  Following that 90-minute period, we hold a one hour Science Fair in the cube areas where the teams sit.  Just like parents viewing student experiments at a school Science Fair, this hour is for stakeholders, at their own pace, to make the rounds to each team they have an interest in for any given sprint.  Stakeholders can informally visit with each of the teams (and their ScrumMaster and Product Owners) at their everyday work spaces to ask questions and see greater detail on what was accomplished during the sprint.   This might be in the form of casual Q&A or real life demonstrations of working software.  Over time, we have found the shortened Sprint Reviews keep the audience engaged and the Science Fair meets the needs of stakeholders wanting greater detail or more personalized attention.

One thing is for certain … that is change!  We are bound to further evolve our approach to Sprint Reviews again and again and again.  That’s right, we most certainly will inspect and adapt and, this time next year, we might be doing something completely different.  All in all, we are doing what works for us today in keeping with our Agile ways.


Valpak’s Agile Transformation Video

I know I’ve been promising this for a while, but now I’m delivering on that promise.  I have for you the world premiere of Valpak’s Agile Transformation video.