Scrum-It's not about completing the sprint

This week, I was reading "Agile Principles, Patterns, and Practices in C#" by Robert Martin.  In one of the early chapters, he talks a bit about Scrum, and mentions that working overtime (excepting the week of the release sprint)  is a big antipattern. 

Now, I've been on a team that practiced Scrum, and we worked at least some overtime fairly regularly-our single goal was to complete our chosen tasks for the sprint.  We felt that we'd made a solid commitment that because we'd said we'd do those things, we'd do them.  On my team, overtime was a good thing if it allowed us to keep our word and finish the sprint.  In fact, finishing sprints was the whole key to our version of Scrum... the company expected us to finish our sprints, and in return, we got to have sprints.

How does the team's regular use of overtime mesh with Scrum? It doesn't.  We had it wrong.  Scrum's not about completing sprints, it's about learning how your own team works.  When I read about overtime was pretty much forbidden in Scrum, I finally got it-if overtime is forbidden and you're behind, sometimes you just don't get everything done.  If you couldn't get everything done in the time allotted, something is *wrong*-and whatever it is, you've gotta bring that out into the open so you know about it, as soon as possible.  If people work overtime every sprint, you may not even know that the team is consistently unable to finish in the time allotted, and the root problem may compound over time.  Whatever it is, be it an increasingly degraded/unreliable codebase, team disagreements,  an underperforming team member, frequent interruptions, or tasks that just ended up being a whole lot more difficult than expected, if you don't know about it, you can't fix it. Forbidding overtime and allowing the sprint to finish uncompleted when things don't work out keeps the need for introspection on and resolution of the underlying issues at the forefront. How you fix the problems is up to you and isn't specifically addressed by Scrum-it may involve team building, examining distribuion of work, taking aside some people to find out why their velocity is down, or focused efforts to increase team velocity such as training or bringing in some XP(Extreme Programming) techniques.  Whatever you try, Scrum can be a companion in making sure you know how you're improving.

In the end, consistently completing sprints is really kind of a side affect, a wonderful reward that comes from the hard work of building and understanding of the truth about your team, and then making the tough changes based on that knowledge.  Sure, completed sprints is what you hope for, but overtime isn't the answer-it's just a short term solution when what you're dealing with is a long-term problem.  If finishing the sprint tasks becomes more important than understanding the team's weaknesses, then Scrum becomes simply a way to organize tasks-you've lost all the introspection and growth, leaving just an alternate form of Microsoft Project.


Posted 03-26-2009 11:18 PM by Anne Epstein
Filed under:

[Advertisement]

Comments

AllanN wrote re: Scrum-It's not about completing the sprint
on 03-27-2009 11:24 AM

Regularly working overtime artificially inflates the team's velocity.  This artificially high velocity is then fed into the planning process.  By doing this, the team has told everyone - "See, we can complete X much software every sprint - Bring It On!"  Why should anyone argue with them?  Now, it's a different problem if the team isn't the one making the sprint goals/commitments.  I've seen this willingly delegated to scrum masters, dev leads, product owners, etc.  But if this dynamic is driven by the team itself trying to meet the commitments that they've made, there's only themselves to blame.

There's nothing wrong with a team focused on completing as much value as they can - increasing their velocity over time.  I think this is a first-class goal for any professional development team.  It may seem counter-intuitive, but I think regular excessive overtime is just the lazy solution to meeting those high expectations.  It's actually harder to figure out how to improve the entire process, their personal coding/testing practices and skills, quality, refactoring, better architecture/design choices, etc, etc in order to increase their productivity/velocity.  This is why great technical leads/managers, scrum masters, etc can make such a huge difference for the entire team.  They don't just deliver more than average amounts of their own work, they make their entire team better and more productive.

Troy Tuttle wrote re: Scrum-It's not about completing the sprint
on 03-27-2009 4:09 PM

Hey Anne,

I would just add a couple of points.  As you mention, it's not about 'making' an iteration.  But it's also not just about fixing team/project problems so folks don't have overtime.  It's about delivering value to the customer, the others are side-effects.

If we follow that thought to its logic end, you can quickly get to a point where iterations are relatively meaningless, and that's where some are exploring Lean or Kanban:  availagility.wordpress.com/.../kanban-flow-and-cadence

Anne Epstein wrote re: Scrum-It's not about completing the sprint
on 03-27-2009 7:17 PM

AllanN,

Thanks, I think you did a great job summarizing what I was trying to get at in your second paragraph.

Troy,

You make a very good point.  I discussed overtime as an impediment to seeing fundamental issues and taking needed improvements, but you're right, the real end goal of those improvements is better value for the customer.

I think Kanban and Lean show a lot of promise.  I don't know them as well (working on that) but I suspect/fear they are similarly open to fallacies of misinterpretation. I'd bet we're seeing it more in Scrum mostly because it's been so widely adopted.  For any of these methodologies to be fully successful, it's crucial to make the mental shift required and not just adopt the trappings of the methodology.

Jack Milunsky wrote re: Scrum-It's not about completing the sprint
on 03-28-2009 12:31 PM

Anne, really nicely written blog post and I agree with you wholeheartedly. Scrum is a learning framework, and overtime is definitely just a bandaid solution.

Thanks for contributing. Do you blog regularly?

Jack

www.agilebuddy.com

blog.agilebuddy.com

Mark Nijhof wrote re: Scrum-It's not about completing the sprint
on 03-28-2009 3:28 PM

Anne, exactly what I have been talking/discussing about lately. Management sees a sprint finished using overtime as a successful sprint, but I say if you have spend overtime during the sprint it has failed by definition.

Also I would like to add that if closing the sprint becomes such an issue that people are working overtime just to finish the sprint you should also worry about the degrading quality of the delivered product. Because then people will also start taking short-cuts in order to make the sprint.

Good read, thanks for sharing

Troy Hunt wrote re: Scrum-It's not about completing the sprint
on 03-29-2009 9:37 PM

Very nice article which raises some interesting points Anne. Whilst I agree we must address the factors which cause a sprint to not be completed on time, I think the sentiment of “consistently completing sprints is really kind of a side affect” is risky in terms of the customer relationship. If a commitment has been made to provide a product on a certain date and subsequently dependencies created on that commitment, not increasing the velocity creates the risk of customer dissatisfaction and a perception of Scrum being an inflexible framework.

I would propose a more balanced approach; work on the continuous improvement aspect of Scrum through regular retrospectives and ensure commitments are kept by regular review of the actual velocity against steady pace. Use overtime if required but ensure the root cause is identified and addressed during the retrospective.

David Warnick wrote re: Scrum-It's not about completing the sprint
on 04-01-2009 1:12 AM

I agree with Troy Hunt.  One of the key principals of Scrum is to treat the commited product backlog as sacred.  If the team decides to work overtime upfront, why not allow that?  If, when going through a sprint, the team realizes "oh man, we're way behind, we need to work overtime or get rid of some of this work" then there's something wrong there.  It's up to the team to decide if it wants to go to the product owner with their collective tails between their legs and negotiate saying "sorry, we can't make these two product backlog items here, is that alright?"  If you wait until the very end of the iteration and the product owner shows up and only sees 80% of the work done without any communication and the team respnds with "oh well, we will never work overtime, because there's something wrong with that" the product owner will then disengage and Scrum will eventually die at that organization since the CUSTOMER isn't getting anything from that team.  

If you take the other approach of maybe (if possible) sucking it up for one iteration and then telling the customer "look, we messed up on our estimations, we probably won't get as much done the next iteration because of A,B, and C" that is a much more effective approach than just "not doing it".  It makes the team look like they don't care about anyone but themselves, and I don't see how that would follow any of the Agile Manifesto principals.

I think as long as the team identifies the root cause and is able to learn from it and not let it happen again while still communicating to the customer/business, it's a win/win situation.

Hanif wrote re: Scrum-It's not about completing the sprint
on 11-01-2012 3:25 PM

What a great summary of Scrum and Agile meloodothgies, Rick! I've been working at a company where we use both XP and Scrum. The collaboration between product owners and developers allows us to get the best product out in very short cycles. While we have the increased responsibility of  doing the right thing , there is no blind implementation of whatever gets  thrown  over the cubicle wall.Mike Cohn and Kenny Rubin are fantastic coaches. The combination of their books, conference sessions and on-site training have proved invaluable to us.Congratulations on your implementation of Agile!

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)