What does “finished” look like?

My family (the one I grew up with – Mom, Dad, brother) is absolutely amazing.  I am not being sarcastic!  I have watched them design and build multiple houses, create furniture, install hardscapes and water features, and even start successful businesses.  We all have an ability to do what needs to be done.  But, we have a flaw – finishing.  I don’t know how many projects that I have started that were ‘lived with” at 90% complete until some critical deadline came up and then, “BAM!” go into overdrive, burn the candle at both ends, over-caffeinate, and punch it out.  Oh, how I wish I would have taken the advice I give to teams on a daily basis!

I recently was working with a team that just couldn’t get over that “sprint” finish line.  They had good intentions, good work ethic, and a willingness to finish, but it seemed like every sprint  something would happen that would interrupt progress.  Sometimes it was even them that did it to themselves.  They showed typical antipatterns that I want to talk about here and some possible fixes.  If you are looking for advanced agile, move along.  This is a return to the basics!  But these basics will help us finish the work we consumed in the sprint.

Fixing Equitable Exchange

In the last retrospective the team, mentioned above, talked about how they employed equitable exchange with the stakeholders.  But in listening what I actually heard was, “customer wants y but we are working on x, so I dropped what I was doing and worked on y.  But it’s ok, I moved x to the backlog!”  While it almost sounds like equitable exchange, it really is just an interruption.   What does good equitable exchange look like?  First, a product owner must also be protective.  There is a reason why the work agreed upon for the sprint was there in the first place – it was highest priority; it has the MOST value.  There will be emergencies, but most of the time, customers are simply reacting to their needs.  The product owner has to weigh this out.  Second, the team and the product owner have to understand the “cost” of the exchange.  It is generally not simply changing an “8” out for another “8.”  There are possibly dependencies, features, and planned work that agreed upon.  Throwing a new story or bug in could be a three-fold disruption.  EE should be used cautiously and shouldn’t be entered into on a whim.  Remember, a whole new sprint isn’t months away, it’s probably days away.  And Josh didn’t say never do it – just understand the cost.

Plan for Acceleration, Don’t Just Hope for It

I have a good ScrumMaster friend that repeated this over and over – “you won’t have problems if you right-size the sprint.”  Honestly, it used to annoy the crap out of me, but I have to admin, Jeremy was right (and I can see his bald head growing right about now).  The above awesome team struggled to right-size.  They always tried to one up their previous sprint despite technical debt, carried over work, upcoming team member absences, and holidays.  Where they missed it is that it isn’t enough to will yourselves to a higher velocity, things have to change to get there.  Many teams are “hoping” for acceleration rather than making the substantive changes necessary to achieve it.  And this all starts back with the retrospective.  Are your retrospectives identifying issues with environments?  Then look at ways to implement Continuous Integration and Continuous Builds.  Are you struggling to finish testing?  It is time (probably past time, if you ask ardent agilists) that the team start automated testing (functional and unit).  Are you still struggling to simply complete everything thrown at the team?  Then consider heavy-duty swarming and focusing on one-story-at-a-time.  Whatever it is, the idea is that a team must “break” habits and formed concepts in order to achieve change, and thus acceleration.

Make Retrospectives Your Best Friend

Ah, the oft overlooked retrospective.  That “complaint” session that has been relegated to almost no longer an event/ceremony/meeting/whatever.  But those who shy away from these miss the point.  This isn’t a complaint session.  In the same way the Sprint Review is a time to make sure we are doing the right work, the Retrospective is a time to make sure we are doing the work right.  We make changes based on the team, environment, work, timelines, need, and effectiveness – something that traditional projects simply can’t consume.  And we do it to deliver greater value to the customer, make our time together more productive, and increase the all-important “fun” level.  Another aspect is that Retrospectives aren’t simply for the last hour of the sprint, but can be used when the brick wall is full of forehead shaped dents.  I have called a quick “stand up retrospective” when I heard rumblings of the daily stand up no longer being effective.  The retrospective is a time to focus on two questions – “what does this mean,” and, “what must we do.”  Again, this isn’t a gripe session and should never, ever, ever, ever be shortened to make room for more important things like “status meetings,” but rather are key to identifying and setting corrective action for issues that are keeping the team from finishing.

All in all, we should be focused on getting the right work done in the right way.  Our primary goal is the provide working software each sprint, every sprint (even if we don’t release it).  When our focus is on work in progress instead of work done, things can slip in that keep us from just getting done.  Sort of reminds me that I have to finish up the front flower bed I ripped apart the other day. . .