On Sustainable Pace

I was just at the Agile Tour at Research Triangle Park in North Carolina. It was a very good event. (Kudos to Catherine Louis and the other organizers!)

Laurie Williams, who is a great person and a great Agile researcher, has done some work recently. I should use her words for it but don’t have them handy. Something like: “How do we feel about the Agile Manifesto and the Agile Principles now?”

One general reaction I had:

When push comes to shove, what should give way: Agile principles or our local organization?

In my view, almost always the problem is ‘us’ and not the Agile values, principles and practices.

Almost always, we make the Agile stuff ‘give right of way’ to what we call ‘reality,’ but it is not ‘reality’ as in the law of gravity, but only reality in that these are the (stupid) ways our organization is doing things today.

Example: Sustainable pace.

Some people complain that the principle of sustainable pace means that managers can whip us to stay at 30 Story Points per Sprint (after the team itself volunteered to go to 30), and that it does not allow us to fix the technical debt or do the broader range of work that must (at least eventually) be done.

This is my view:

• Sustainable pace is very important in many ways. The main point I like to make is that it is no longer about ‘hard work’; it is about ‘creativity,’ ‘innovation’ and ‘inventive’ solutions to difficult technical problems. Our brains have to be fresh to be creative as a team.
• Sustainable means we treat people as human beings. They have a life outside work. They are not machines for us to use up and throw away. We ask people to work roughly 40 hours per week.
• Sustainable pace (as measured via Velocity) quickly becomes less valuable unless we are doing virtually everything possible never to allow technical debt to grow. Let’s be professional. Let’s not pretend we are going fast when we really are not.
• Sustainable pace does not mean that the team ‘must’ maintain the same Velocity every Sprint. (Yes, Virginia, stuff does happen.) And, the team should always be challenging itself to remove impediments so more ‘work’ can be accomplished in the same amount of time. In other words, on average, ‘Velocity’ should be upwardly sloping, but NOT by working harder.
• An empirical process requires transparency (or a high level of it) and any pretending or hiding of ‘undone work’ (as Ken Schwaber likes to call it) is not helpful at all. Sustainable pace quickly becomes meaningless if we do this (Cf Technical debt above).
• Bad news does not get better with age. So, sustainable pace must be immediately linked to a strong and improving ‘definition of done’ for normal stories in a Sprint.
• By sustainable I also mean doing everything we professionally can to assure we are keeping each sprint up with ALL the different types of work needed to keep the system or product fully ‘done.’ This includes fixing all bugs, refactoring, building all the truly useful documentation, refactoring the architecture or design, visioning of future sprints, and Release Plan Refactoring, etc., etc.
• As soon as we discover some undone work (and we as humans will typically forget something and thus it is undone, and then discover it later), we must address it professionally. Do it immediately or put it on the Product Backlog to be done soon. Consider how much it makes our previous information about Velocity and progress a lie. (Always, to some minor degree, and possibly to a significant degree.)
• Just because we will always be imperfect does not mean we should give up on Agile or Agile principles or practices.

Can you put these ideas into action real soon? (Today is a good day to start.)

P.S. I am not saying the Agile Manifesto and the Agile Principles are perfect. Maybe I am saying that our real worlds are messier than those ideas, or so I see.