It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…
The Truth of Uncertainty
The first, and most important truth that Agile asks us to accept is that at no point in a software development cycle are we 100% sure of the structure, substance, or outcome of our work until it’s complete. We can make educated guesses about how complicated something is, how difficult a set of work is likely to be, or how our customers will accept what we decide to build. But all of those are guesses, and just as likely to be wrong as they are to be right at the end of the day. Agile instead asks that we simply accept that there are things that we won’t know until we discover them, and that’s okay…even preferable. Because if we engage in our work in an iterative fashion, we can course-correct early, often, and inexpensively — rather than waiting until all the work is done to discover that we’ve missed the mark. Accepting uncertainty is the core of a successful Agile organization, and driving it out should be their number one goal with every single sprint.
The Truth of Continuous Improvement
You’ll notice that nowhere in the Agile Manifesto or the Twelve Principles of Agile Development will you find any of the following terms: standup, planning, review, retro, pairing, Scrum, board, Kanban, flow, or the myriad other words that we use on a near-daily basis. There’s a reason for this — rather than prescribing or proscribing some set of development or project management practices, all the Agile Manifesto and Principles are doing is laying out a philosophy. Sure, daily standups deliver on the principle of “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” but there are myriad other ways to do that as well. As I’ve noted before, I personally think that Scrum is a great way to start your Agile transformation — but it’s far from the only way, nor is it something that you need to comply with religiously. So much of the Agile philosophy connects with the concepts put in place by lean manufacturing dating back to the 1940s and the Plan/Do/Check/Act process. Agile begs us to accept the truth that we must constantly inspect and adapt what we’re doing and how we’re doing it so that we can make ourselves, our processes, our tools, and ultimately our products better.
The Truth of Customer Collaboration
One of the biggest things that people miss when implementing Agile principles in their organization is the core concept of collaboration with the customer (or stakeholder, depending on how close you can get to your end customer). All too often we see organizations that claim to be Agile still behaving like the Product Manager (or Product Owner, or Product Designer, whatever you want to call them) is the only one who can or should work with the team to get the requirements “right” and ensure delivery of what’s “agreed on”. This is a highly dysfunctional remnant of waterfall and BUFR approaches of the past. If you have a stakeholder who understands the customer’s needs, there’s no reason why they shouldn’t work directly with the team to improve the quality of the output. Product Management shouldn’t be a gatekeeper, but a facilitator — we should be finding the right people with the right context and the right passion to help us all achieve our goals. The closer we can get our development teams to the customer, the better the work they will do, and the more close they will feel to that customer and end user. If that means that stakeholders are involved in backlog grooming, so be it. If that means that stakeholders are involved in sprint demos, bring it on! The more collaborative our approach is, the more Agile it truly is — up to and including connecting developers and development teams with end users. Refusing to allow others into “our world” as Product Managers is as anti-Agile as writing hundred page BRDs and tossing them over the transom to your dev team to check off.
