Today we wrap up our series on Agile Leadership examining the four values in the agile manifesto and seeing how they apply not only to software development, but to leadership in general. And that means today I have to figure out the hardest one of the bunch to apply outside of software. Man, I've been putting this off for a reason.
The second value listed in the agile manifesto is, "[we value] working software over comprehensive documentation." Yikes. How on earth are we going to find a general case for that?
Well, let's take a step back and figure out what the point of this for a software team really is.
Documentation Is Evil!
Ask yourself which you'd prefer: A well-engineered word processing program, or a user's manual that described to you how that word processing program would work if we actually had finished it.
Here's another one: Would you rather have an MP3 player without a user's guide or a nice, thick, chunky owner's manual that described in painful detail how our awesome player works, but no actual device?
The point of this agile value is that it's always better to deliver something that works, and works well, and works as expected. Do the work you're being paid to do in such a manner that you don't have to document it to the nth degree.
...But It's A Necessary Evil
Are there going to be times when you'll need to draft documents? Sure! Even the iPod comes with a user's manual. It's printed in a small card that you probably threw away after glancing at it and realizing that it all just made sense. But the first time it hung and you couldn't control it? You went to the web and probably Googled for an answer and found it, probably on Apple's customer support site.
So, as agile leaders, are we telling our people to avoid documenting the jobs they do? Not at all. The key to the second part of the value is "comprehensive" documentation. Agile leaders don't need every single i dotted and t crossed if we've designed our processes & procedures so that they make sense.
If it requires a printed manual for our people to do their jobs, then we probably need to look at the tasks we're asking them to do for opportunities to simplify and streamline!
Document appropriately. But not as a substitute for doing other work. Documentation should be an extremely minor part of anyone's job. Your goal as an agile leader is to ensure that tasks and jobs are as self-documenting as possible. Ideally, a trainee should look at you during training and say, "sure, that just makes sense!"
How about it? How can you see this agile value working in your workplace? Leave a comment and tell us about it!