Every three to four weeks somebody tries to sell me on some new methodology or way of software, generally it's some agile, scrum, XP, iterative, test-drive, fully buzzword-compliant system that comes complete with 2 case studies, web-based management tools. (Generally it's someone in chinos and a polo-shirts, occasiaonlly suit pants and a highly-patterned suit. It's barely ever someone in a suit-and-tie.)
I sort of half-buy it. There's some fantastic ideas in a lot of "agile" methodologies that I gladly steal, and I'm sure it works great for a lot of projects, but they still rely on:
And really if you have these, most methods are going to deliver. A lot of the people who get excited about lighter approaches have a habit of comparing the worst real-world water-fall project experienced to the best imagined agile project they can think up.
I may just be biased against the "no-spec/agile" stuff as I do so much work on fixed-price/fixed-delivery projects.
It's not that I haven't seen my share of useless 200 page behemoths that will never get read - I just think there are less radical, less risky solutions (e.g. Wikis, BA Compotency Centres, proper Requirements Management) and if people spent half the time they spend on polishing and improving their agiles processes on traditional processes they'd get a much higher return.
Posts
No argument about the shortcomings of methodology change. I'm sure you'll enjoy further ranting on the subject here: http://www.bigvisible.com/gschlitz/enterprise-agile-framework/
ReplyDeleteIt's not about a silver bullet methodology that fixes all your problems. I believe you need to look at the organisation and the project in context, and really think about why most projects end in a death march regardless of the quality of the people and their good intentions. people are more complex than software, and finding a way to get the best work out of them will lead to good project results. Key ingredients tend to be honesty, ownership, and collaboration.
Worth some thinking - agile methods are based on "empirical process control" where inspection and adaptation is baked into the process itself; a madatory component. traditional (non-agile) development approaches are based in "defined process control" where the stages are set at the beginning, and we follow the process all the way through to delivery. if the 'thinking about what you're doing and why' leads you to believe you need to change, a traditional process can be too rigid to incorporate that change (and this is really the people behind the process being rigid, but who's to blame them?).
Change is hard, especially when we think we know exactly how to go about building a system using a defined process. When we admit to ourselves that inspection and change is a necessary part of building complex systems, shouldn't we embrace a process that incorporates that insight?
Who says inspection and change can't happen in traditional projects? They are embedded into every single methodology, as reviews, regulat demos, sign-offs, user involvement in test-plans, etc.
ReplyDeleteIt's in there differently but it still there.
It's often done badly - but that's because there are a lot of bad BAs and PMs out there. They don't get magically better on an Agile project - though as an aside I think Agile projects attract a better class of people as it's considered sexier.
Going Agile often doesn't help. It only really changes the structural frame (http://www.tnellen.com/ted/tc/bolman.html)
Granted 200 page word docs are hard to update if written badly - but I'd say most systems are pretty hard to update too. And a Wiki for Requirements/Designs solves a lot of problems here.
Agile is just so consistently over-sold and over-hyped "Agile isn't a silver bullet" statements aside.
P.S. You're right. I did find a lot to rant about in that article. It was like the same blind-enthusiasm, lack of respect for reality, and inability to compromise of a RUP enthusisast, but for agile instead.