One of the issues that Product Managers commonly face when engaging with teams who claim to be, or who want to be, “Agile” is that most people have never really take the time to actually research the origins of the Agile movement, the principles upon which it is based, or even the histories of the specific practices that have grown from these principles. All too often, teams and companies begin their way down a transition to Agile practices as blindly as a bat fluttering out of its cave into the sunlight.
The fact is, there is a long and storied history to be found, and one of the best places to start is by reviewing the Agile Manifesto, which in many ways was the first coordinated effort to coalesce a variety of different approaches under a single set of guiding principles. After a few online conversations, I thought it might be useful to present a few common misinterpretations of the Agile principles and explain why they’re incorrect. To start with today, I’m going to dig on on the first two statements in the Agile Manifesto:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
History & Fundamentals
Before I dig into each of the specific statements in the Agile Manifesto, I think it’s important to start off by setting the context of the Manifesto and it’s principles. Sometimes people forget that the Manifesto itself, and the practices that followed from it, is almost 15 years old. It dates from a time when Agile practices were not the norm, and where Waterfall approaches were the norm — with detailed, 100-page requirements documents; stage-gate review for large projects; and 2-year “roadmaps” that were based on specific features delivered at specific times. The Agile Manifesto is, in large part, a response to the failures of these processes — which is key to understanding what the principles really mean and why they were adopted. Each of the principles, as stated, is a preference for one approach over the other, not a statement that either of the sides of the statement are “right” or “wrong” — just that leaning too far either way can cause dysfunction and missed opportunity.
Individuals & Interactions over Processes and Tools
One of the most common misinterpretations of this principle is the belief that teams don’t need process or tools, that they can do what they need to without structure. This is the opposite side of the spectrum from a traditional, waterfall approach that focused strictly on tools and processes — no change was accepted that didn’t go through change control, that wasn’t reviewed by ten people, that didn’t have a footnoted requirements document associated with it. The problem is that no structure at all causes just as much trouble from a business perspective — development teams are part of a larger structure, and there are things that they need to report on, things that they need to be held accountable to, and measurements that make sense from a business perspective. Stakeholders need to know what’s going on, when releases are likely to be delivered, and what the priorities are — that’s how the business itself runs and grows. We wouldn’t put sales teams out there without some kind of revenue goal; we don’t put marketing efforts out without measuring ROI; we don’t solicit investment without understanding the terms of the deals. And with the current state of tools out there, they can often be bent to fit whatever process the teams are using — the goal should be finding the lightest process needed to provide stakeholders the information they need while not burdening the team.
On the other side of this principle is the focus on individuals and interactions — the idea that we’re all more productive, and that we learn more and enjoy our work more when we’re acting in a collaborative, supportive environment. Things like the daily scrum, properly-run planning and review sessions, and even demos are all expressions of this principle. The goal is to have the team talk — to each other, to other teams, to the Product Owners, to the stakeholders…even to the customer. This does two things — (1) it reinforces that there are people on the other side of the software; and (2) it shows others in the organization that the developers themselves are people, and not simply interchangeable cogs in a machine. Teams are self-directed to reinforce the trust and respect that the organization places on the members of that team; team members are held accountable not by a checklist of requirements over the course of 12 months, but against their own commitments, made to and by their team members on a regular basis.
The preference for individuals and interactions over processes and tools accepts that there is a place for process and tools while strengthening your teams’ ties and ensuring constant, collaborative communication.
Working Software over Comprehensive Documentation
The key word in this statement is comprehensive — and in the context of a response to Waterfall methodology, the point that this statement is making is that it’s more important to do something than it is to think it all the way through. This principle alone is the one that demonstrates how strongly companies are willing to actually take on the risk that there are unknowns or not. Companies that dabble in agile, or that implement agilefall practices (the odd combination of agile and waterfall), generally fail in this aspect far more than any other. They’re unwilling or unable to accept that they may not know exactly what needs to be delivered in the next 12 months, and they’re skeptical that starting out building small iterations of work will actually wind up accelerating their delivery. The transition to user stories can certainly be an uncomfortable one for many organizations — giving up that security blanket of a detailed, comprehensive requirements document is a hard thing. It’s also a necessary thing, as detailed requirements provides a false sense of security — it hides the unknown unknowns under a veil of supposed knowledge. But, as anyone can tell you who has worked in a traditional waterfall, stage-gate process, the requirements are never executed as-is — that’s why there’s change management — primarily to update the “comprehensive” requirements to reflect new information. Which is the whole point of Agile development — build what you know, change it as you learn more.
At the same time, there is certainly a need for some documentation — whether that’s commenting your code under accepted coding practices for your organization; documenting user stories and decision points; writing help documentation or implementation guides or deployment instructions. There will always be some need for documentation — stakeholders need to know what the goals of the development team’s efforts are; support needs to know what the software does; marketing needs to know how to position the software; sales needs to know how to talk to the software; tech writers need to know how to describe the software. The point is that such documentation is the minimum necessary to achieve the goals of the development team and the stakeholders. Work should never be held up by documentation, but sometimes after the work is done it’s necessary to provide some overview or to collaborate with the teams who need documentation to provide them what they need. Having no documentation is just as bad — if not worse — than having “comprehensive” documentation.
The preference for working software over comprehensive documentation focuses the team and the company on answering the questions that they know exist so that they can uncover what they don’t know, and adjust appropriately.
Next Time…
In Thursday’s installment, I’ll dig in on the two remaining statements, which are of equal importance (and often equally as troubling) as these first two:
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a Plan
