Over the past few months as I have been writing broadly about ‘Agility’ I have been interweaving my reflections on the Agile Principles with my thoughts about some of the specific development issues we face as a firm.  As I wrap up this loose series and prepare for the next arc of blog entries about the Agile planning process I wanted to share some thoughts on what can sometimes become a contentious principle of Agile.  Hopefully as I write about some of the ways we wrestle with this idea the important elements of balance and nuance will diminish some of the tension that can arise around this topic.

The principle in question is this one: “Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”  The idea of a constant pace of development that can be sustained indefinitely sounds appealing at first glance; but in truth it’s not that simple.  Talking about and encouraging a sustainable development pace raises a number of questions: Who determines what the ‘acceptable’ pace will be?  What happens when you ‘need’ to get extra things done to meet commitments?  How do you measure ‘velocity’ in development, and is faster always better?

There have been lots of pieces written about these issues (here’s one from a few years back that captures the heart of the matter well: http://bit.ly/15tJ47i).  Over the next few blog posts I want to share some of what I’ve been learning about promoting sustainable development.  Like many of the Agile principles, this is one that appeals to me at a deep level, and I try to structure my life as well as my work to promote a pace that can be sustained over the long haul.  Here I just want to lay out two core aspects of an environment that fosters sustainable software development over time.

First of all, to encourage teams to function at a long-term sustainable level these teams must be comprised of motivated people.  Motivated teams work hard and produce results they can be proud of – in both quality and quantity.  One of the key responsibilities of the product owner (in concert with the product manager) is to keep the team motivated.  I take this aspect of my job very seriously, and though it’s something I need to get better at doing I think regularly about ways to encourage the teams I work with.  One key way I do this is by sharing; I share successful client stories, thrilling sales interactions, and the credit when things go well – while also trying to shield the team from unnecessary distractions and discouragements (more on this in a later blog post).  Here’s a link to a challenging article from Marty Cagan on the role of strong product owners in encouraging the product team and fostering the passion needed to maintain a vibrant development pace over the long haul: http://www.svpg.com/product-evangelism/.

If there is a second key besides product passion it is working in an atmosphere of mutual trust.  Teams on which there is not mutual trust among the sales, business, coding, and testing teams will regularly clash about the definition of a ‘sustainable’ pace – in fact they are likely to clash over other things as well.  This is why the principle of sustainable development is so closely linked to the following principle: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”  A trusting environment with motivated and self-organizing teams promotes higher quality development at a faster velocity, all leading to more and better software over time.  That’s the environment in which most of us would like to work and the kind of results we’d all like to see.  Promoting that atmosphere is fundamental for fueling a motivated team toward sustainable productivity.

Hopefully this post gives you an idea of the issues I will be writing about over the next few posts.  Living and working at a sustainable pace makes a lot of sense to me, and I hope to provide some encouragement and helpful suggestions as I talk about what we’ve been learning over the past few years.  I think both our development team and our client consultants are happier with the quality and quantity of our software development since we embraced an Agile approach, and I think our clients are getting more great software than ever.  Hopefully my reflections on this will be useful for others.  Of course, in truth it’s not that simple.