Traditional Agile is now missing the point

The Manifesto for Agile Software Development is pretty long in the tooth. That transformative document was created in 2001, 18 years old at the time of this writing. The resulting humble web page ignited a conversation which ultimately changed the way software is written and delivered.

Agile techniques have leaked successfully into other types of work, like HR or content development. And other ways of doing work have leaked into Agile, like Kanban. Mixing these ingredients can be quite useful for teams, and even helpful for longer-term planning because we base forward progress on history and the longer-term evidence of a team’s throughput, be it Scrum or Kanban (or pick your process).

Enter DevOps

So, most shops now “work in an agile way”, often confusing poorly executed Scrum with Agile. And increasingly that is becoming okay. When a team is focused, close to the customer, cross-functional, and self-organizing, you have an Agile team regardless of what process they are using to get their best result.

Traditional practices branded with Agile usually focuses on the ways people work together. DevOps is practiced by teams focused on the product with patterns, solid practices, and creating engineering systems created with the customer in mind.

DevOps practices are often based on Continuous Testing and Continuous Deployment as far to production as is good for your product and your customers. It also makes for faster changes and release cycles. Teams are delivering bits through automated pipelines that build and test their solutions, ensuring high quality throughout the development process.

DevOps is the modern realization of Agile.

– Me

It focuses on destroying the breakdown in communication between development teams and operations teams. DevOps technologies, patterns, and practices bring a team closer together using the product and delivery system as the unifying contract. The processes used to manage work, like daily standups, become more and more about the product and delivery system and less about how the team goes about its work.

Bringing developers closer to the deployed product and including operations staff in software development ecosystems was a truly novel idea and one that grew out of Agile practices. Now, operations staff get a say in the product development and not just the underlying system the solution runs on. Software management features can be requested by operations representatives and added for runtime management support. Simple examples include having the product write custom logs or use a monitoring agent to instrument the application at runtime.

DevOps has opened the focus of software developers. It’s no longer just about the code. Instead, work encompasses the software and the entire delivery pipeline ensuring high quality, and finally the infrastructure upon which the software will run.

The poly-level developer

Now introduce the cloud. Product development in the cloud typically starts with defining network components, like VNets, Subnets, load balancers, and application gateways. Developers suddenly care about things like “what is the underlying technology I will use to scale?” and “What instrumentation agent should we run on our solution?”

Developers are learning by necessity more about networks, deployment techniques, security, and patterns of scalable architectures like those found on Microsoft’s Azure Architecture Center.

Next Steps

The Agile Manifesto laid out great principles for how people work together to succeed in software development. It also encourages the unifying shared goals focused on product delivery. Shared goals are more likely to be met when the focus of cooperation is not human process, but tested, efficient, fast, well-crafted, and secure software products, all of which are the building blocks of a genuinely Agile team.

What can you do?

1. Create an automated build system.
2. Declare a level of unit testing that should be measured in your builds.
3. Create integration tests. They can get big and may need to run on a timer instead of a check-in event, nightly perhaps.
4. Steer conversions toward the product, rather than how we set up a Scrum board.