Being vs. Doing Agile

I have the privilege to manage several high-performing teams of USGS software developers. The stereotypical sloth-like delivery of outdated technology attributed to federal workers does not apply. Embracing an agile philosophy, these teams deliver quality high-value features continuously. They don’t simply “do” Agile, they “are” agile. They are able to quickly pivot, adopt technology, innovate, and respond to the increasing rate of change required to support the USGS science mission.

Marketing hype has led to a multi-billion dollar business that seeks to help organizations do Agile. There are many vendors who will train your staff, coach, and certify your Agileness. Software can be purchased that will further increase your Agile awesomeness. The popularity of Agile and its promises of improving just about everything having to do with software development has led to many maladroit Agile adoptions that has turned “Agile” into a dirty word for many managers and developers in both government and commercial organizations.

The Project Management Institute (PMI) writes on their website that their PMI Agile Certified Practitioner (PMI-ACP)™ “is our fastest growing certification”. They provide a range of courses that certify Project Manager Professionals (PMP)s in popular development processes such as Scrum, Kanban, Lean and extreme programming (XP). The obvious point being that if one learns to do Agile, not only will you be more marketable but the projects you run will become more responsive to market dynamics.

Our USGS teams have found that leveraging processes developed under Scrum and Kanban can improve the quality of delivery, but are often reminded to return to the Agile Manifesto and its very first edict: Individuals and interactions over processes and tools. Learning the processes to earn a scrum certification does not make you agile. The Manifesto is a brilliant bit of work. It exhibits a philosophy that can guide software developers in making the choices that lead to better software. It does not tell anyone what those choices should be. In building an effective agile organization, the Manifesto needs to permeate the very DNA of every team in order to become agile.

I am an agile evangelist. I’ve experienced first-hand a number of agile transformations in both commercial and government development shops. My experience has been that Agile works. But, it can be very difficult to sustain a pocket of agility when the rest of the organization follows a more traditional process-oriented, big plan, document heavy style to support the broader business effort. When the organization hosting the agile development team embraces the agile philosophy, the productivity and happiness of the development team increases.

In my experience, Agile adoption often begins with a demonstration of Agile’s merits on a specific project. USGS leaders showed the courage eight years ago to award a sole source contract to an agile development team of contract staff augmented with government developers. I helped lead that team to a successful implementation that delivered an application ahead of schedule and under budget. I was offered a chance to help transform a group of USGS developers into an Agile practice. From the very beginning, the team sought to become agile, not simply do Agile. The team evolved their practice through the use of retrospectives - sessions that identified what worked and what didn’t. Processes that didn’t work were discarded and those that did were refined. The practice and associated processes were developed deliberately. They continue to evolve to this day.

Once there is a functioning Agile practice, it needs to be sustained. This means working with managers and collaborators to ensure that they understand the benefits they derive from interacting with an agile team using Agile techniques. Teach them and have patience, but protect the teams at all costs.

Sometimes circuit breakers must be set to protect teams. This is particularly a problem for schedule driven projects. If something cannot be done by a certain date, don’t make promises that it can. Work with collaborators to reset the focus from schedules to delivering value and to ensure that the team is always working on those efforts that result in the most value. Transformation of the parent organization into one that itself becomes agile is not guaranteed, but nothing succeeds like success. Working high-quality software delivering value as early as possible is a very compelling outcome to promote agility throughout the organization.

I love to hear stories about agile transformations. But with the commercialization of Agile, many of those stories are about doing Agile, not becoming agile. These stories are sometimes referred to derisively as “cargo cult agilism”.

During the second world war, south seas Melanesians experienced what for them was unbelievable wealth descending from the skies. US cargo planes delivered tons of goods to support the war effort. Some of this treasure - spam, coke, fuel, tools - made into islander’s hands. When the American’s departed, villagers adopted rituals such as building runways and waving flags in control towers in the hopes that the planes would return with the desirable western goods (cargo). Practitioners of these practices have been referred to as belonging to a “cargo cult”. Similarily, teams can perform Agile rituals, but not be agile.

Agile is not about isolated teams doing sprints, daily standups, retrospectives and planning poker. Agile seeks a better way to develop software with a focus on people, working software, collaboration and a willingness to change. To gain the benefits of Agile, organizations must actively seek to become agile.