Is Sustainable Pace Just a Nice to Have? Think Again!

Selling Agile is easy these days. Most people agree that iterative and incremental development is a better alternative; more user interaction is better; so on and so forth. At some point, we need to 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 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 doorstep 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 cannot 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.

Short term

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.

Long term

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.
 
About the Author

Manoj Vadakkan is a Certified Scrum Trainer, and Agile Consultant. In his coaching practice, Manoj uses innovative approaches such as Scrum, Kanban, and Lean to help individuals, teams, and organizations to achieve their potential. He facilitates workshops around the world including Certified ScrumMaster. Look for his next Certified Scrum Master class in a city near you. Or contact him to schedule a class for your team or organization.