Revisiting The Agile Manifesto
I had the opportunity early in my career to have a mentor who knew some of the software engineers that created the Manifesto for Agile Software Development. He referred me to their website (https://agilemanifesto.org/principles.html) and to this day, the principles listed have demonstrated what “agile development” means. I think it’s important to revisit this foundational document on occasion and reflect on where your team is and where you should improve.
Agile?
In the professional context of “agile” there is a proliferation of frameworks that try to co-op the term. These frameworks try to package agile concepts into scrum, or kanban, or something like SAFe – while these can be useful, they tend to be geared towards trying to reduce risk on engineering investment cost and demystifying delivery timelines. Important goals, but NOT the actual definition of “agile development.”
I’ll be reviewing each of the manifesto principles over the next few months, adding personal context, sharing stories from my experience, and tying in key lessons I’ve learned. Feel free to follow along and comment – I’d love to learn from you too!
The Highest Priority
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
-- Principle 1 of The Agile Manifesto
What we do as professional software engineers is absurd. Consider that we listen to a person describe a vision they have, solving some problem, or providing business value. We take that vision and implement it in a different language, one that can automate that vision, reliably deliver a service, and provide customer value. So many things can go wrong at the technical level, but at the business level, I think the most important point of this first principle is “early and continuous delivery.”
Time is money and executing an abstract vision into a tangible software product is hard work. Quickly find the critical path to value at the start of the project and focus efforts on delivering that piece of the system. Figure out a way to launch with an alpha product – you can QA all day long, but ultimately, the people using the product are the best point of feedback.
Once you have that initial release, remind the business that this isn’t done (you shared your definition of done with the business at the start, right?), and start acting on the feedback you’re getting from the field. Often this is ignored in a professional context, and that’s a big miss, as you need to dial in the end user experience in order to continue adoption.
Adoption is key and that’s why the second phrase of the principle is so important - continuous delivery. Fast iterations into production allow for improving the customer experience as well as improving the codebase and feature set. Prioritize the feedback from customers, but make sure that you’re not incurring too much technical debt. Gold plating now is especially dangerous – prioritize based on fastest-value-adding-feature.
To sum this one up: focus on delivering the critical path to value as early, then as often, as possible. Prioritize your next steps based on customer feedback, followed by the fastest-value-adding feature, then reducing technical debt. To me, this is how the principle ties directly into showing business value, and is why it’s the highest priority in the manifesto.
