This article was originally published on Scrum Alliance website on May 2011
Most of the time, “selling” Agile is easy these days. Everyone agrees that iterative and incremental development is a better alternative; more user interaction is better; so on and so forth. At some point, I will talk about the importance of a sustainable pace. At that point, most will gloss over and some will simply say that it is nice! When I insist that it is not just nice but it is essential, some will respond: “Manoj, there is Agile and then there is reality” (That is actually a quote). Really? Is sustainable pace just a nice to have?
Sure, part of the reality is that our customer always wants to do more than we are able to deliver in a given time period and with a limited amount of money available. But isn’t that true with most things in life? When most of us (regular folks like me!) go shopping, we would like to buy more than what we are able to afford; but, then we settle on what we can afford based on what we have the money for and what our priorities are. Sometimes I need my wife to bring me back to reality! Shouldn’t we do a similar favor for our customer? What happens if we don’t realize our limits? Well, in the case of my shopping, I will get my credit card in high gear and buy all the golden eggs that I can at once. Eventually, reality will show up at my door step as a bankruptcy notice. Eventually, the goose that was laying golden eggs one at a time will get tired and die – or perhaps the goose might produce more eggs under pressure but those eggs will quickly start to deteriorate in quality.
Of course, there are some marketing folks who are going to promise more than the IT division can produce in a given period of time. Now, it is the IT team who will have to live up to their promises. How do we do it? Well, there is the scope, which we cannot go back and negotiate once it is promised. There is the schedule; also already promised and non-negotiable. There is cost; we have the maximum number of people already. There is only one way — our team will have to work more nights and every weekend. But, let’s be nice, during the weekend, the team should only work eight hours.
When we start a project, most of the time the team figures out that we are trying to accomplish a lot more than what we can do. Many a times, anyone who points out that fact will get a briefing on the reality that we don’t have any other way out. At this point, our optimistic nature takes over and we tell ourselves there will be a way to do it.
During the iterative/incremental process of working, we will start realizing very early in the project that the team can not complete all that we have promised. Our first reaction: try to stuff more and more into every iteration. We will avoid talking about how many hours team members are working and adopt the “Don’t Ask, Don’t Tell” policy. The team is smart; let them figure out how many hours they need to work – as long as they complete everything in the scope. Well, who decides what is in the scope for each iteration? Someone outside the team?
If we are to work this way, among many, I’d like to point out two impacts; one affects the short term and the other affects the long term prospect.
We have too many things on our plate in the current iteration. This means there is no time to look at what is ahead. Because of that, we begin the next iteration unprepared. We spend too much time figuring out what we are suppose to do and by the time we figure it out, the whole team would have wasted a significant portion of that iteration. No wonder we are not able to get everything done that we have committed to during the iteration.
When the team says they are not getting much sleep because we have a lot going on or in order to meet our sprint commitment, I start worrying – both for team members and for the system they are building. Late in the night, when that developer is trying to finish the code so the team can claim that story point, which task receives lower priority? Refactoring the code? Automating the unit test? Testing for all the alternate flows? Well, all of the above become a nice to have and quality is sacrificed to meet the schedule. A few iterations in that mode will create fragile code that will easily break. More on how to avoid messy code can be found at Uncle Bob’s article in January newsletter (see reference below).
Sure, the customer may not care if your employees are working long hours every day but have you talked to them about the quality of the code as a result? Try telling them the downside and they may start to care. In the long run, the customer will be the one to pay when they want to change the code for next release. Do you still think sustainable pace is a nice to have? Maybe we should check with our customer. Maybe they would agree that quality is nice to have too or maybe not. One thing is for sure, we shouldn’t make the decision for them.
Additional reading on Sustainable Pace
- XP’s description and discussion on sustainable pace.
- Vikas Hazrati in an infoQ article discusses whether Sustainable Pace means a 40-hour work week.
- Various snippets about Sustainable Pace
- Bob Hartman (Agile For All) writes about Sustainable Pace.
- George Dinwiddie’s comments on Sustainable Pace
- Uncle Bob’s article on avoiding messy code with strong engineering practices.
– See more at: https://www.scrumalliance.org/community/articles/2011/may/is-sustainable-pace-nice-to-have-think-again!#sthash.NjoHdgCg.dpuf