I have been writing in the past two posts about finding and maintaining a sustainable development pace flowing out of reflections on the following Agile principle: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”  I’ve written about understanding and measuring velocity and about the impediments to supporting strong velocity and a thriving team.  Now the time has come to address two fundamental and inter-related questions: who defines what a ‘sustainable’ pace means and how ‘fast’ can a team work for an indefinite period of time?  These are the two questions that make this principle a controversial one for some people.

In a well-functioning Agile environment, the team itself defines what velocity is sustainable.  Agile teams are self-organizing with a regular practice of planning, development, and retrospectives that allows the team to discover a sustainable pace.  It is very hard for someone not intimately involved in the process – including the daily scrum meetings – to evaluate true velocity, much less to dictate it.  As I discussed in an earlier post, the true throughput of a team is a reflection of the story points that the team works through each sprint, and the complexity of both estimating those story points and then working through the associated issues requires personal involvement to appreciate.  This is why Agile values face-to-face meetings and team interactions over written plans and time lines which can obscure this complexity.  Well-motivated teams supplied with a steady stream of input thrive on working hard and seeing results because they want to avoid the extremes of either boredom or burn out.  Maximum sustainable productivity feeds and encourages the team, which means the limiting factor often becomes not how fast the team can develop features but how quickly the product manager and product owner can supply well-articulated user stories and how easily impediments to development can be removed.

Over the past few years I have been regularly amazed at how adroitly the teams I work with have developed solutions to complicated problems.  When a team is involved in product road mapping and encouraged to plan key aspects of their approach in advance, I have seen teams deliver on ‘stretch’ goals with remarkable reliability.  And the nature of the Agile planning and development process means these teams can also respond well to unanticipated obstacles and even pivots in priority.  As teams work together over time, they develop a rhythm to their development process that balances periodic pushes for new features with intervals of sustained attention to clearing technical debt and automated test development.  Over time, consistent teams tend to increase their velocity as they understand the market context for the problems they are solving, the code base and architecture with which they are working, and the optimal ways of collaboration among the designers, testers, coders, and product owners.  A strong team does not need to have outsiders mandate a ‘sustainable velocity’ because the team itself pushes toward maximal productivity.

Which leads to the second question: how ‘fast’ a velocity can a team sustain over the long haul?  The fact is, a strong team thrives on a high velocity.  Marty Cagan talks about this in an article about the need for speed which you can find here: http://bit.ly/1dPjmvL (but don’t confuse this piece with this other one: http://bit.ly/hvBouN).  Cagan talks about the organizational benefits of high velocity (and the support it wins from senior leadership) as well as the motivating impact of quick learning and quick delivery.  Part of why speed is valuable in Agile teams is that iterative development is greatly enhanced by failing – and therefore learning – quickly; in more traditional software development it can take months to discover that an idea was a failure while high velocity Agile development fails and pivots more quickly.  A great example of this process can be found in a story about the value of fast failure at PBS (read it here: http://bit.ly/15Y1Dog).

When a team has the right skill set, a strong product backlog, and the encouragement to fail quickly, the team can sustain a good velocity of development and discovery work for extended periods of time.  There are of course always ebbs and flows in a team’s progress, as well as the impact of team transitions and vacations, but good teams thrive by avoiding both boredom and burnout and they are motivated by thrilling the end users of their products.  The teams I work with and observe often make remarkable progress on complex software development, and the bottleneck usually stems from the product owner not keeping the team fueled with well-articulated user stories or the product manager leading the team into a ‘churning’ process when market needs aren’t adequately understood.  Self-organizing Agile teams truly produce some amazing results when they are supported and encouraged to find their sustainable pace.  Does this mean that the sales team will always be ecstatic about the output of the software development team?  That frequently depends upon how thoroughly they understand the development process since in truth, it’s not that simple.