Tag Archives: sprint review

The Sprint Review Rut

After a full year of back-to-back sprinting  here at Valpak , the teams fell into a Sprint Review rut.  It’s my job to coach, inspire and motivate them right out of that rut.  So, here’s the approach I took …

As we head into our 25th Sprint Review tomorrow, I realize that it may feel like Groundhogs Day for some.  With that mindset, I think we may have fallen into a rut.  The last few Sprint Reviews have had some noticeable issues (not just noticed by me, but by our stakeholders) … team members arriving late, awkward hand-offs between presenters, dead air due to apparent lack of preparation, etc.

That said, I’d like for us to be thinking about the Sprint Reviews a little differently going forward.  Let’s all channel our inner entrepreneur and think of our team as our own company and our stakeholders as our clients.  So, you are presenting to your clients and you want them to renew/continue their contract with you for another sprint.  This is precisely what companies like AgileThought go through with each Sprint Review and we can learn a lot from them.  Remember, your team is your company, your stakeholders are your clients, and you want your clients to continue to do business with you.  With that kind of mindset you are sure to deliver a successful Sprint Review each and every time.

But, it didn’t end there.  Our Agile Coach, Ryan Dorrell (CTO of AgileThought) provided more words of wisdom …

25 Sprint Reviews?  Wow – congratulations again!

But you’ve done this meeting 25 times now…is it getting boring?  Is it getting old?  Feeling stale?  Feeling like the same thing over and over and over?

Let me tell you the story of what I’m working on right now.   About half my time right now is spent working on a project for a client where we are building two mobile apps for the – one iOS, one Android.  We have a sprint review meetings every two weeks.  The product owner sees the builds all throughout the sprint – he downloads regular builds, gives feedback, and we’ve worked with him to define acceptance criteria.   There should be no surprises.  But yet I’m always a little anxious about sprint reviews.  I want it to go well.  I want the product owner to say “wow, this is really awesome – amazing work” at the end of the review.   I want to exceed his expectations, even when we’ve been setting his expectations all sprint with complete transparency.  He knows what the product looks like, and knows what he’s going to see.  My anxiety is probably based on the fact that he’s our customer – his company pays good money to hire us to do work for them.  They don’t have to use AgileThought as a development firm.  It’s our teams job to have there be no doubt that they should use anyone else.

Compare that situation and mindset to the one you may be in.   In an internally focused role, it’s very easy to fall into the trap of not seeing your internal business customers and stakeholders as actual customers.  It’s easy to think of them as just other employees that work with.  It’s easy to miss the fact that for each team, for each sprint, there are significant dollar costs.  Customers, even internal ones, need value for the dollar.  To echo Stephanie’s point, I want you to see your customer (product owner) as the customer whose expectations you need to exceed.  Have the mindset that your product owner could go find another team to do the work that you are doing.  Maybe they can find someone who can do it faster or better or cheaper.    If there was a chance that, after each sprint, the product owner would decide whether or not to keep using your team…would that change your mindset?   Product owners are partners but also customers with the team – we owe it to them as customers to treat them as if they have a choice.  They very well might have a choice and you might not be aware of that (I’ve seen this happen).   In your next sprint review, if you aren’t a little nervous – I would ask yourself why.

If you to have fallen into a rut when it comes to your Sprint Reviews, consider this way of thinking to up your game.

Advertisements

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.