The Myth of No Control

by Jean Richardson, PMP

I have just come from another day of coaching agile teams, and interestingly, the notions of control and communication are hot topics in this environment—or should be. 

As I consider what I know about Agile as a result of my Agile coaching, Scrum Mastering, and Agile PM experiences and contemplate the Agile Manifesto, it baffles me to think that people believe that there are no controls in Agile.  How can one eschew control, or discipline, and still satisfy the following four values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

In one-on-one coaching situations, I often coach that “the best control is self-control.”  It’s precious, requires great discipline, and when it slips away, everything else goes to pot.  Now, it’s worth noting that one can be “over-controlled” and that results in its own set of problems.  First and foremost, creativity and innovation can easily be snuffed out in an over-controlled situation.  People who are too controlled by others easily give up their own initiative, commitment, and sense of accountability and simply rely on someone else to make all decisions—from which flow commitment and accountability.

Various Agile frameworks prescribe certain engineering and group process practices, but all focus on the value of community facilitated by a servant or participatory/adaptive leader to bring social forces to bear that result in collaboration, innovation-inspiring conflict, and critical thinking about work processes that result in high value, high quality products that meet the needs of real customers.  Here are some of the typical controls that Agile Teams use:

  • Iteration increment reviews against a vision, roadmap, budget and product release window
  • Formal commitments or sprint forecasts to Product Owners
  • Definition of Done
  • Version control
  • Timeboxes
  • Story grooming sessions wherein requirements are elaborated and bounded to ensure ease of delivery and high quality commitments
  • A product backlog which is constantly worked in a fashion to welcome change deemed valuable by the customer

 

Perhaps it feels to some people as though there is less control—or no control—in Agile projects because the locus of control is redistributed.  Rather than a project manager who makes the project come alive and be successful, there is a facilitative leader who encourages a healthy and effective tension between the Team and their customer, often called a Product Owner, while keeping an eye on the vision, the target delivery window and keeping data about progress and effective use of all resources very visible to the Team so it can make good decisions in service to the customer.  For those whose primary experience is in the project-manager-as-project-hero role, this can be very frustrating and even frightening.  It takes an entirely different approach to management and leadership.  In Agile the maxim “use systems to manage and people to lead” is more true than ever.

And  -  the kinds of documentation and the duration focus of most controls is shorter than in a traditional project management approach.  Some Agilists will go so far as to say that each sprint is a mini-project, each building on all that comes before it so as to deliver the final product. 

Additionally, there may appear to be more discretion about some kinds of longer term controls.  For instance, if there is a release focus, as in a 1.0 software release, there may be a release burndown—or not, if there is no pressure to deliver a release.

One control that many Agile Teams overlook is the Vision Document, which can be enhanced to function as an Agile Charter.  This is not to be confused with a Team Charter, which is an entirely different product with a different purpose.  This document is quite brief and covers topics such as, what are we building and why; what’s the market opportunity or value to the organization; what are the known challenges with this proposed project; stakeholder goals; features and benefits; what’s the market value; and external requirements and constraints.  Sound familiar?

Usually, when I start teaching people new to Agile about how to use Agile methods to lead Teams to successful product or service delivery, I say:  

“There are controls.  They’re just located in new places.  It’s a matter of knowing where to find them.”

 

About the Author

Jean Richardson is the Agile Community of Practice Chapter Engagement Representative for the Portland, Oregon chapter of PMI.  She is also an agile coach and project management professional with more than 20 years’ experience with clients in the Portland metro area.  Her initial agile training, the Certified Scrum Master (CSM) credential, was provided by Ken Schwaber, one of the two developers of the Scrum framework.  You can read her blog on leadership, agile, and project management at http://azuregate.net/blog-archive/ and link with her at http://www.linkedin.com/profile/view?id=7674981&trk=tab_pro. You can correspond with her at jean@azuregate.net.

See her newly published InfoQ article We Need No Less Than Pervasive Leadership describing an approach to leading that supports agility.