Projects@Work has perhaps the most succinct description of the problem with plans:
“Plans aren’t sacrosanct — they’re meant to be flexible guides, not straightjackets. Agile project leaders focus on adapting to inevitable changes rather than opposing them. In this way, value and quality are the end goals and the plan becomes a means to achieve them, not the goal itself.”
Glen makes the argument in It’s not Waterfall versus Agile, It’s sample time: ”the sampling time in the control loop determines how responsive the loop is to change.” or more succinctly, “Sample slow, respond slow” and “Sample fast, respond fast”.
I agree that sample time is the major difference between projects that succeed and projects that don’t. However I would also argue that the major difference between Waterfall and Agile is the sample time, and thus is fair to pit the two against each other.
When you get down to it, every practice and method is some variation of PDCA/DMAIC/etc. What differs from them is how quickly you close the loop between each iteration, how the speed impacts the style of communications, what you believe about the appropriateness of certain inter-team communications (can developers impose restrictions on the requirements? can developers talk to the customers?).
Agile likes it fast – you need to work hand-in-hand daily with everyone on the team because there isn’t time to do otherwise. It is believed that developers and business people need to talk together, because the developer may have a restriction that the designers didn’t know about.
Waterfall likes it slow – you write design docs, throw them over the wall to development, and again over the wall to testing, etc. You write a lot and try to be exceptionally clear, because waterfall folks believe that conversation about a project is basically a one-way street, slowly falling down each step of the waterfall till the product emerges at the bottom.
Each belief fits a different situation, and the real argument is: which one fits software development the best?
[via @jurgenappelo]
Jim Highsmith writes “Do it right the First Time sends the wrong message: it says we can’t be uncertain, experiment, learn from mistakes, or deviate from the plan”
A friend of mine commented that while interesting, this was taking the “Do it right the First Time” out of context. I thought I’d look into it a bit more, and from what I can tell, “Do it right the First Time” is an idea embodied in the First Time Through (FTT) manufacturing metric, which itself is based on the Zero Defects idea of which is part of “Philip Crosby’s 14 Step Quality Improvement Process” (someone please correct me if I am wrong).
While I would agree that it seems reasonable to apply this ideal in a manufacturing setting (a highly consistent and repeatable process), I don’t see it as being a good principle to apply elsewhere (say, software development).
The problem I see, is that the principle is often applied in areas that are inappropriate. Design documents for software would be a great example. If a software enhancement was designed was discovered later to be unbuildable, is it the developers fault for not being smart enough? Or is it the designers fault for not understanding the very technical system constraints? Or maybe it was further downstream, and the customer didn’t know what they wanted till they had something to look at. The process depends on experimentation, and is always uncertain at the start. 9 times out of 10, you end up building something entirely different than what you thought you were going to build at the beginning. The way I see it, highly collaborative, multi-disciplinary processes can’t possibly be done right the first time, because progress is an act of discovery, not an act of manufacturing.
So was it taken out of context? Yea, a little.
But is it a good reminder because the principle is frequently applied out of context? Absolutely.
Jim Highsmith wrote: “Documentation is often the solution to a communications problem that can’t be corrected with documentation.”
I found this to be a good reminder. I mean, the point of documentation is a simple one isn’t it? To convey ideas and intent clearly and without ambiguity. We write it down because we can’t remember long enough or clearly enough, or we don’t trust the people we are working with enough. (“I asked for X” “I thought you asked for Y” “well, let’s go look at the document!”)
If we worked in smaller iterations (with people we trust), our need for documentation would decrease exponentially. With contract thinking (ie, everything must be written down and signed) increases project cost by 30-50%. That’s a lot of waste for a problem that is pretty easy to solve.
I suppose there is a secondary purpose to documentation that focuses on tracking the history of an item. But let’s be honest – how many times do you go back and look at project documentation after it has been released into production? In my experience, the more detailed the document, the faster it becomes irrelevant and unhelpful.
Jared Spool, a Researcher for User Interface Engineering, gave the closing keynote to the Agile 2009 conference. He had an informative and entertaining talk about what UIE has found with their research.
He used this video from Apple on the “Apple Computer Knowledge Navigator” as an example of a good experience vision and discussed how it directs the actions of the company. Here is a short write-up from Forrester on the talk. Of about 200 different company attributes, the UIE research found that the following three were the most useful in predicting long term success:
VISION – Can everyone on your team describe the experience of using your design 5 years from now?
FEEDBACK – In the last six weeks, have you spent more than 2 hours watching someone use your or a competitors design?
CULTURE – In the last six weeks, have you rewarded a team member for creating a major design failure?
The first two are (I think) rather self explanatory, however the 3rd has gotten double-takes for everyone I’ve discussed with. The theory is really pretty straight forward: discovering a major design failure is to be celebrated because it is informative. If the culture of an organization celebrates learning, then you will find learning occurs both with successes and with failures. Wonderful point of view.
monthly email
RSS 2.0