Agile Your Agile: Changing Process One Step at a Time
This article was originally published by Steve Persch on Dec. 11, 2015 on the Pantheon blog.
In my position as an Agency and Community Engineer at Pantheon, I talk with a lot of development firms about their practices. In nearly every conversation I hear about the “Frankenstein Agile” or “WaterScrumFall” strategies in use. It is ironic that a project management philosophy that emphasizes flexibility has so many agencies wringing their hands about Agile orthodoxy. On top of that tension Drupal and WordPress shops often serve clients that need a guaranteed website at the end of a budget. That is a very different world from the “this project could be ended at any moment so do the most valuable stuff first” mentality that gave rise to Agile.
In that fluid situation where agencies are not even sure if they want “pure” Agile I recommend that they use Agile itself to slowly train their teams on Agile practices. Agile suggests working in small steps. Adopt Agile methods for your project processes through the same kinds of baby steps Agile recommend for doing client projects. In other words, Agile your Agile.
Organize Your Team
Agile encourages appointing a product owner capable seeing the big picture, balancing competing interests, and setting priorities. An agency’s product is its team and process. To improve that product into one capable of executing “pure” Agile projects, an agency will need a product owner to oversee the transformation. This person is probably a director or manager who knows the value that agency delivers to its clients, and where that value can be increased.
The product owner can write user stories that identify the value being sought with each Agile practice. For instance, if an agency previously did not have stand-ups, the product owner might write a user story like the following:
As a developer
I want a daily stand-up meeting
so that I have a clear place to raise the blockers I encounter.
User stories force an explicit recognition of why a change is being made. Do you want stand-ups to identify blockers? Are they supposed to engender camaraderie among a remote team? Without stating why a change is being made to your agency’s process (like adding daily stand-up meetings) you risk the change becoming a rotely followed rule. If teams stop engaging in the stand-up meeting, there is a good chance the sprint will fall behind.
Organize Your Time
Sprints define where a team puts its focus, and just as importantly where it does not. If agility is the hot topic of conversation at an agency, then there will be some pressure to add all of the ceremonies and artifacts of Agile to a project at once. At the agency-wide level, the product owner overseeing the company-wide adoption of Agile should maintain a backlog of practices that increase agility. If your team has never done user stories, stand-ups, or demos then perhaps only one should be introduced per “sprint.”
At this meta level where agility is being used to implement Agile, it may be hard to define a sprint length. A sprint could simply be one client project. It could be a month, it could be quarter. How can an agency know when it can call its implementation of backlogs “done?” How can you do a sprint review meeting demonstrating that the user story covering backlogs themselves is done? Feeling and addressing this pain at the meta level will help solve the same points at the level of client projects. Teams for client projects have to figure out how to call an image gallery feature done so that it can be demoed at the end of sprint. That will be easier to do if your company already has a practice of demoing to itself the ways it has integrated Agile practices like measuringvelocity or continuous integration.
Test Your Progress
Before an agency can call their teams Agile, a strong continuous integration practice is needed. All of the buzzwords aside, running a project with agility boils down to this: identify where you are now and then take small steps in the desired direction. Continuous integration is the way you ensure that the “where you are now” part is accurate. In an Agile project for a client a team might think “where we are now” is at a place where there is a solid REST API and a half-built JavaScript client. Without a well-defined build process, automated tests, and more, there is a high probability that the solid REST API will start to crack and the half-built JavaScript client will spin on a treadmill of regression bugs.
Continuous integration brings a level of automated paranoia that the features built in a product might degrade and regress if they are not specifically defined upfront and tested over time. That same mentality can provide benefits when working at the Agile meta level. Answer just as specifically how a project team is built and bootstrapped. Define clearly what good backlog management looks like so that you can write actual regression tests that query backlog tickets that go without update for some number of days. Periodically, send a small internal project through your process to validate that your clients will get the experience the company-wide product owner envisions.
That vision for what clients should experience when working with your agency should be captured in a Minimum Viable Product (MVP). Just as Agile client projects need MVPs to guide them so too does the increase of agility itself within an Agency. How fluent does your team need to be in Planning Poker or Test-Driven-Development before the MVP of Agile itself has been met? I wish I had magic tool that could answer those kinds of questions for any agency but as the Agile Manifesto says, individuals and interactions are more important than process and tools. If you can handle the manifestos guide of prioritize “responding to change over following a plan” at the level of evolving your own project teams then those teams will be able to do the same for clients.
