Dave is an experienced Agile Coach and Practitioner. For more insight, please see Dave’s presentation on Agile for non-IT executives.

The Fear

When senior managers hear about “Agile” many tend to recoil because they equate it to “no documentation, anarchy (through self-organizing teams) and cowboy coding practices.”  The Agile movement itself is mainly to blame for this, especially when hard-core agilistas promote “the code is the documentation” and “we deliver to production every 2 weeks whether the users are ready or not,” ideas untenable in large organizations rife with diverse stakeholder groups, regulatory/compliance requirements, enterprise architecture standards, hundreds of interconnecting systems and production support divisions founded upon ITIL practices.

The Reality

All software projects are governed by constraints, whether project teams think of them as constraints or not.  Take, for example, a software startup.  At the very least it is constrained by four different factors, as seen below:

For startups to be successful they must consider each of these factors when developing solutions that fulfill the opportunities that startup is exploiting.  Making a choice that violates one of these constraints, such as selecting technology for which no skilled engineers are available, limit the chances of making any startup successful.

Software projects within large organizations are constrained even more heavily, as depicted below.  Some of these constraints, such as regulatory compliance, are imposed upon the organization from external sources, while others evolved within the organization (simplistic explanation: as a reaction to things that went awry in the past).

No matter which methodology is used on a project within an enterprise, to be successful a team within that enterprise must work within the additional constraints imposed upon it.  In fact, project managers who consistently deliver successfully are those who understand the importance of these constraints and actively seek guidance on how to ensure that they can meet all key requirements.

It does seem very daunting!  It also becomes clear that the mismatch between the constraints described above and the misconception that Agile means “no documentation, anarchy and cowboy coding practices” is in fact quite a natural reaction… images fly to teams BBQing in the office while coding Python/Cassandra solutions in a .NET shop (or worse)!

What Agile Really Means

In 2001, the authors of the Agile Manifesto established four values and defined 12 principles that they agreed were the bases for effective software engineering.  They did not make these things up – the values and principles represented the common ground of the authors’ experience.  Kent Beck’s XP already existed at the time, as did Ken Schwaber and Jeff Sutherland’s SCRUM.  Nowhere in either of these approaches did the inventors advocate “no documentation, anarchy or cowboy coding practices;” in fact, XP requires a high degree of discipline and technical craftsmanship while SCRUM is a fairly prescriptive management approach that requires specific behaviors of team members.

Whether at a startup or in a large enterprise, agile teams are constrained in at least 2 ways:

  • Team behavior.  Depending on the flavor of agile being practiced, the organization in which the project is being run and the values of the individuals making up the team, “acceptable behavior” emerges.  Examples include:
    • “We always ensure that all automated acceptance tests pass before we check new code into the mainline”
    • “We don’t change a use case story during an iteration after the team has agreed on it (unless the whole team agrees that it can commit to the change).”
    • “We don’t cook fish in the team room.”

Having written that, acceptable team behavior emerges and evolves in much the same way the solution does.  Retrospectives and team consensus guide this evolution (more on retrospectives later).

  • Technology.  This is where startups differ greatly from large enterprises in that they are not typically constrained by Enterprise Architecture standards, Project Governance, Production Support requirements or Regulatory Compliance.  But even at a startup, if one of the team members starts coding in Ruby after everyone has agreed that they will use Scala, there is a problem.  On projects within large enterprises, agile teams depend upon external groups to provide the necessary standards and guidelines, and they must treat these requirements in much the same way that they treat requirements from their primary stakeholders.

I like to draw these as two boxes, with the Mission underlying both.  This emphasizes that decisions the team makes regarding the way they work and the technology they use are driven by the need to create value for the business according to the project’s mission.

Perhaps most interesting is that the boundaries of these boxes emerge and evolve over the course of a project as the team learns more about the problem being solved, the solution needed to solve it and the way the team has to work together to achieve that solution.  During the retrospectives that occur at the end of each iteration, the team tweaks (or sometime makes wholescale changes to) their approach in order to work more effectively.  In addition, agile teams demonstrate their solutions to stakeholders often, adapting and adjusting based on stakeholder feedback to drive the technology choices of the solution.

From time to time (and quite often on a team new to agile development), team members make “excursions” outside of the one of the boxes.  The team must itself monitor these excursions and decide whether:

  • the excursion was valuable (and to then expand the box); or
  • the excursion was ill-advised (and then bring the traveling team member back onside).

Adventurous developers who continuously deviate from what the team itself has decided in terms of either behaviour or technology probably aren’t great team players as they have trouble respecting the direction that the team itself has agreed upon.  No matter how technically skilled these people are, the team is better off without them.

A Final Word

A project manager I once coached told me of his experience at the hospital when his wife arrived in labour with twins.  An experienced dad, my friend said that he took a step back and observed while the team of doctors, nurses and technicians took charge and focused on the safe and healthy delivery of his boys.  He remarked that while it was initially loud and seemingly chaotic, there was a calmness and purposefulness to the chaos; this was an intense and risky situation but my friend’s overwhelming feeling was confidence in the ability of the team to deliver.

In my experience, organizations of all sizes ask their software development teams to deliver miracle solutions to problems whose root causes are not yet known, all with incredibly short deadlines.  The fact is that there will be chaos, at least initially, but letting a motivated team decide on the best course of action (keeping in mind both the mission and the constraints) almost always results in the best architecture, requirements and designs.

But in order for this to happen, senior managers must give up some control to a team of people with no single “neck to wring” or “throat to choke,” and this frightens them.  Consequently, organizational agile “transformations” have a tough time getting off the ground and rarely exercise the effective agile values and principles that could truly align technology and business.  And add value.

Hopefully, knowing that agile teams are not running amok in a vacuum might help!