I think “Identity over Zealotry” belongs in the list. Just because I think there’s a right way to do something or say something or approach something doesn’t make it right, or better-than-yours, or even good. I find that the Agile Manifesto comes pretty close to expressing my values in a clear concise way. That said, I’m not sure too many other people find it clear and concise. I know quite a few folks who look at the list as binary and binding; a statement of what I as a agile adopter expect, or demand, or just flat out won’t do. But that’s not it at all, at least for me. It’s a set of statements I identify with; it expresses what I’ve learned to value.
So from time to time I rewrite the Agile Manifesto in a way that hopefully more clearly and much less concisely captures how I’m feeling about it at the time. My latest one is patterned after story cards, or at least, patterned after the story card pattern. Basically I wrote a Mad-Libs style statement and filled it in with words consistent with my value system. Here’s the structure for the value statements:
Your something you value is important to me. If I ask that we change some action we engage in, it is to improve our shared understanding of some quality of our working relationship. So to help you better manage the “something you value”, I believe that I should act in ways that respect the things you value.
Let’s look at the first one, a rewrite of “Individuals and Interactions over Processes and Tools”.
Your time is important to me. If I ask that we change what we do or use, it is to improve our shared understanding of each other. So to help you better utilize your time,
- I should make deployable software available as part of my routine. (3)
- I should meet with stakeholders regularly and frequently. (4)
- I should prefer to use more personal forms of communication. (6)
Basically I think the agile manifesto is making a value statement that we care more about the relationships between the Who’s rather than constraining the How’s. The numbers off the ends of the “I should” statements are mappings back to the Agile Principles, for those folks who might be interested. In particular, it’s worth noting that in this way of looking at the manifesto, it’s an expression of what you can expect from me given that I have this outlook. It’s about the changes I’m going to introduce. I’m not going to ask that we follow new processes or introduce new tooling for the sake of my time, but rather for the sake of yours. I’m interested in us understanding each other, in communication and dialog, not in shiny gadgets and constraining workflows.
On to “Working software over comprehensive documentation”.
Your project is important to me. If I ask that we change what we generate, it is to improve our shared understanding of where we are now. So to help you better manage your project,
- I should write software that speaks for itself as early and as often as possible. (1)
- I should provide reliable and current information to encourage emergent solutions. (11)
- I should understand my effectiveness to become more effective. (12)
Here I’m making a statement about the kinds of artifacts I’m going to introduce. I don’t value a bunch of pre- or post-documentation. And I’m not going to hide behind artifacts to give you a rosier picture of the state of the project. But that doesn’t mean I don’t value the documentation you’ve asked me to produce.
What about “Customer collaboration over contract negotiation”?
Your vision is important to me. If I ask that we change what we agree to, it is to improve our shared understanding of where we are going. So to help you better achieve your vision,
- I should accept that agreements can and will change. (2)
- I should maintain a sustainable pace in my work effort. (8)
- I should pay continuous attention to technical excellence and good design. (9)
And finally, “Responding to change over following a plan”.
Your experience is important to me. If I ask that we change what we commit to, it is to improve our shared understanding of how we get there. So to help you better leverage your experience,
- I should structure my environment to best get the job done. (5)
- I should demonstrate progress with working software. (7)
- I should increase the work that doesn’t need to be done. (10)
I don’t think there’s anything wrong with planning. I do think it is dangerous to commit when your experience tells you it is not safe to commit. I want to structure my environment and the software in a way that you can commit with confidence. And I want to identify and eliminate waste so that no one has to commit to doing it.
So there you have it. My latest exposition on the manifesto. The manifesto isn’t taking a box of 8 things you really care about and throwing 4 of those things out the window. It’s making a statement that says that I know you’ve been burned by software developers and teams before. I know you’ve had developers try to convince you that the only way to succeed is to follow some convoluted process or rigorously use a bunch of time-waste inducing tools. I know you’ve had developers dump mounds of documentation on your desk and claim that the system they’ve designed is perfect for your needs, they just need X more years to finish the software. I know you’ve had developers put line items in their contracts so they get paid even if you don’t get what you paid for. I know you’ve had developers try to force you into a plan covering months or years that completely ignores the fact that your business and the market changes. I’m not one of those developers.
And moreover, I’m not asking you to trust me. I’m showing you how you can test me. I’m going to introduce change. You’ve hired me because you want change; you want success where you’ve only had failure. I’m going to work with you to achieve that success, and here’s how you can tell: You’re going to talk to me, not my email, not my layer, not unreadable documentation, and not a convoluted process.
And when you talk to me, you’ll see the software. You’ll get to poke it and prod it and tell me to my face what you hate about it. And then I’ll fix it and show it to you again. And after we do that enough times, you won’t hate it so much. And we’re going to get to that point as soon as possible, because that’s when we’re going to start developing software that matters.
Posted with : De Machina