News Stay informed about the latest enterprise technology news and product updates.

Musings on the connection between Agile, Scrum and continuous delivery

This Content Component encountered an error

There’s one big question at the heart of everything that good software project managers do. How do we develop software better? How do we improve the ways and means through which we develop software? In its time, the Agile Manifesto was a revelation to many developers. It formalized a school of thought about developing software in a fundamentally different and better way. Today, continuous software development seems to be building on Agile principles and pushing them forward. Quicker feedback, tighter cycles, go, go, go!

In comparison to the promises of continuous deployment, the ideal that every code change will automagically be deployed to the end users if it works or kicked back to developer if it doesn’t, the Agile Manifesto seems sort of tame. Maybe the revolution is moving on without it. In her recent article, Jenn Lent asked “Does the Agile Manifesto matter anymore?” Spoiler alert, she decided it both does and does not. On the one hand, valuing flow over planning seems naïve in light of the complexities in today’s enterprise application architecture. On the other hand, The Manifesto really struck a chord with customer focus. It may be cliché, but the customer is always right (even when they’re obviously wrong).

And today’s customers, even internal customers, have been spoiled by incredibly well-designed user experience in consumer focused applications. They expect that enterprise applications will simply work and work simply. They expect intuitive interface design. They expect load times of fractions of a second. They expect applications to keep getting better week after week. The Agile Manifesto embraces that need for constant improvement quite well. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

I think that’s what led cutting-edge developers into continuous integration and eventually continuous delivery. The benefits of simplifying the development process, streamlining the scope of each project, have been readily apparent for years. It makes sense to hone that down until every change is its own tiny project. Automation has also been proving its worth of late. It makes sense to automate just about any test you can write a script for. I won’t bandy over the technical details, but Gerie Owen has great advice for building up that automation for continuous delivery.

But then again, we can’t all be on the leading edge. Many enterprise organizations (maybe most) are still struggling to really get Agile running in their organization. Matt Heusser explained in our first (of many, hopefully) software quality podcast that at every Agile conference about 90% of the people there fall into the “Scrum-but” category. They’re doing Scrum, but they’re not doing all of the scrum processes and they’re not getting all the value. There’s no way to sum up a perfect solution for adopting holistic scrum processes, but Heusser outlines the basis of a solid strategy in the podcast. It centers on finding the core developers, the ones who do the most and the best work, and getting them on one team that can really excel. For more details than that, you’ll have to click through to the whole story.