New to agile? Work at a sustainable pace

Question:  Which is better: a) Working nights and weekends to meet iteration commitments, or b) Admitting the commitment was too much and working normal hours regardless of the commitment?

Many people would say answer (a) is better.  I might even say that if it were a one-time anomaly, but too often it doesn’t happen just once.  The team ends up setting an artificially high velocity and are then asked to keep a similar velocity in the future.  As a result there are more and more iterations with impossible deadlines and the agile team begins to feel they are on a death march.  I even had one person in a course tell me their management had them all sign a document saying they would work nights and weekends as necessary because the company really needed the product as soon as possible.  Seriously?!?!  On an agile team???  Ouch!

99 times out of 100 my answer to the original question would be (b).  Work at a sustainable pace (no sandbagging allowed), determine a realistic velocity, and go on from there.  During the iteration retrospective an obvious discussion question would be why such an unrealistic commitment was made in the first place.  Sometimes it is just an anomaly caused by uncertainty.  That can happen occasionally and is no cause for alarm.  However, more often than not it is caused by a team trying to meet an artificial deadline and convincing themselves they can do it.  Don’t fall into this trap.  Death march projects are no fun and they may even be less fun when done in an agile way.  Seeing failure or ridiculous overload every two weeks can get to be horribly depressing!

Remember, a sustainable pace is one at which the team can perform for very long periods of time – forever basically.  I like to add the team takes pride in how much gets accomplished each iteration.  This helps prevent sandbagging because you can’t take pride in the amount completed if you sandbagged it.  Also remember sustainable doesn’t mean no vacations!  It is necessary for downtime to recharge.  Sustainable could even mean occasional overtime if the team chooses to meet their commitment in order to help them feel proud of the iteration – however this should not happen very often – if ever!

Project managers and Scrum Masters need to watch the mental and physical health of the team.  Be the conscience of the team when it comes to maintaining a sustainable pace.  Re-read that last sentence and ask yourself when the last time a project manager asked a team to reduce their hours because it wasn’t healthy!  If the pace of the team is not sustainable several undesirable effects are likely to occur:

  1. Defects will increase.  Tired teams let more defects through.
  2. Work output will decrease.  Tired teams do less work in more time!
  3. Morale will drastically decrease.  This may lead to employee turnover at a most unfortunate time in the project.
  4. The blame game will become common.  (Not our fault you didn’t say X.  I said X.  Did not.  Did so…)
  5. The team starts to abandon good practices for those that “seem” faster.  Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA!

Do you have any funny stories about sustainable pace or a lack thereof?  If so, please post a comment.  I’d love to have examples to use in the future!

Until next time I’ll be monitoring teams I coach for use of a sustainable pace because there is no other way of Making Agile a Reality® for the long term!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Thanks for this post. I think sustainable pace is very often overlooked and misunderstood. The tricky part is that an organization cannot achieve sustainable pace without serious prioritization. It is a lot easier to ask for all features and make teams work more.

Bob Hartman

Known as Agile Bob, brings over 30 years of experience and broad industry knowledge cultivated by serving in almost every role in the software industry including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager and executive. Over the past 15 years Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer® (CST) and Certified Enterprise Coach℠ (CEC) and an expert in training, coaching and mentoring across all areas of Agile development. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops and user group meetings where his engaging style, holistic view of development and personal anecdotes are always well received by attendees.

Connect

bob.hartman@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author