Agile software development, based on the concept that a software development process should expect, and respond to change is increasingly becoming the preferred way to create software. I won’t explain Agile here (my colleagues have done so extensively), nor will I lament the fact that so many claims of agile development reflect the adoption of terminology over process. The purpose of this conversation is to discuss how to adopt agile methods after the software is released - how to use agile in an operational model.
We work with a client that uses a CMS platform to support multiple dozens of highly trafficked, highly monetized websites. We built the platform with the client, moving them from a painful multiple-site model in which each site was its own unique flower, to a platform model that provided a single code base to support the common elements to control and support each site’s individuality. This shift alone represented a huge relief to our client, and eased the extreme pain they formerly faced when making changes and updates across all/each of their sites.
They took this opportunity to change their development and release process. They wanted to be able to make bug fixes, new features, and general updates happen more easily - for developers, testers, and the business to be able to know what was in each stage of development so that releases could be as seamless, regression error-free, and easy as possible.
(photo credit Major Mom, http://thevollmerfamily.com/MajorMom/2012/04/in-a-happy-place.html)
Sounds pretty straightforward. Who wouldn’t want - need - simplicity and openness, if you want to release software every day. Here are a couple of the core practices needed to get to that happy place...
1.Get with the program on strong source control, peer reviews, and continuous integration.
These tenets seem like the basis of what we do, but many shops don’t use these best practices. A team insistent on source control best practices, supported and enforced by peer reviews and continuous integration, catches merge conflict overwrites (gah!!!), controls code consistency and regression issues, and allows simpler rollback of feature commits with issues uncovered in manual testing. There is a setup cost, but it’s far outweighed by the benefit of time savings and catching bugs before they’re released.
2. Structure build and deploy to meet your operational needs.
Our client’s operational model was different than the development model. More branches, more build automation, and additional tiers were needed to support merging the production line with the dev line, testing, and staging. Devops was part of the product team.
3. Lessen pain with multiple tiers.
Don’t skimp on servers. The cost of spinning up a new machine to support your need to release well-tested software is small compared to the cost of releasing broken software.
4. Make testing a first-class citizen in your team and process.
To ensure that new features are thoroughly vetted and that regression is solidly covered, our client invested in heavy unit testing, heavy automated testing, and heavy manual testing. When you have an essential web property, wouldn’t you?
5. Linking your repository and your issue tracker makes testing and releasing much easier.
You never want to find out too late that the fix to the A#1 issue wasn’t actually in the build - and why should you, if you marry your tools? (Also, who wants to write release notes anymore, when you can have your tool generate them, and run manual testing from them… ah, consistency.)
We could argue whether all of these practices are “agile,” or just good software development/release management, but let’s not. For our client, putting in place a new release process and dev workflow demanded that the team think and act with agility.
All of these practices set a framework that allowed the product owner to make daily decisions about when to ship. In this case, releases were not planned so much as on-demand - major issues could be addressed and released singly; multiple improvements could be grouped and released; and all of this could flex as needed - they could plan a release of X features, or they could work Kanban style and release whenever they felt like it - or do both. The entire team could easily see the state of the code tied to where issues were in the workflow. Communication is always key, and the visibility their infrastructure enabled allowed and encouraged discussion of what everyone could see. There were no questions, no guessing, just information to respond to and act on. Having a holistic view of the product also reinforced the behaviors that enabled that in the first place - creating a nice agile virtuous cycle to support the needs of a product.