David Heinemeier Hansson’s perspective:
“I think of functional spec as one of the worst inflictions that has ever happened to the software development world. I think functional specs are a relic of a time when building features was a very, very hard and long process and you had to do all of this upfront planning because once you wrote anything in software, it was pretty much impossible to change it. I don’t think that functional specs is a technique that’s any longer relevant.”
Jim Highsmith (@jimhighsmith):
“Agility is the ability to think and learn rather than blindly following a recipe.”
Bob Marshall (@flowchainsensei):
“You really have no clue as to how much your business success depends on software, do you?” #neversaid
Ben Simo (@QualityFrog):
“Compliance with standards makes sense when & where interoperability is more important than innovation & improvement.”
Wil Harris (@wilharris)
“New Apple mouse proves not only does Steve think we are too dumb for two buttons, we can’t even handle one. A mouse with no buttons. Nice.”
Jared M. Spool (@jmspool):
“Remember, if you torture data long enough, you can get it to confess to anything you want.”
Jeff Patton (@jeffpatton)
“Requirements are the boundary between what I get to decide and what you get to decide. It’s a fuzzy discussion, or DMZ”
Esther Derby (@estherderby)
“ppl talk about commitment as if it is an act of will. commitment requires will AND time, resources, skill, authority”
Bob Marshall (@flowchainsensei):
“So you’re all far too busy politicking and CYA-ing to actually bother about delivering stuff to the paying customer?” #neversaid
37signals (@37signals)
“The best way to have a good idea is to have a lot of ideas.” -Linus Pauling
Naresh Jain (@nashjain)
“Consistency is over-rated. Consistency is a big innovation killer. Let diversity & positive deviance help us explore better ways”
Visual Management is one of those things that feels obvious, but isn’t. The idea is that you manage projects, tasks, and other bits of work-in-progress using something visual (ie, not digital). It’s a chart on the wall that everyone can see, that everyone can modify, and is updated regularly.
There was a workshop specifically for Visual Management at Agile 2009 and a subsequent write-up on the presenter’s Visual Management Blog. But don’t be fooled – while this may be gaining traction in more technical areas, this will work for anyone’s project. There are lots of great pictures of examples and is worth your time to browse the pictures even if you don’t read the whole post. I’d suggest starting here.
I’m amazed at how well a non-technical solution can communicate to everyone on (or off) the team.
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]
monthly email
RSS 2.0