Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Monday 28 September 2009, 6:42 AM
Agile programming power everywhere, no thanks!
The reasons for my cogitations on this topic are that some vendors appear to think that Agile needs an occasional boost, like it’s already some kind of floundering fish in need of an oxygen boost.
If you look back at the last time I interviewed IBM’s Agile practice leader Scott Ambler, you’ll see that there’s lots of passion attached to this subject. But some of it is almost ‘single-minded’ passion that is hell bent on Agile everywhere. Possibly leading us to down a narrow one-way alley where the scrum can’t move and is in danger of imploding upon itself.
As the ever-affable Jon Collins of Freeform Dynamics said, “If something goes wrong {… with Agile…} there can be a domino effect on other parts of the project. To all intents and purposes, Agile approaches can be intense and rewarding, but the one thing they are reliant on is a level of structure and co-ordination.”
It’s not just a quick fix ‘chuck an Agile team at it and have some power scrums’ one size fits all solution then – and as I said before, don’t necessarily expose the underlying foundation of the total application ecosystem to Agile. So how do we know when to use Agile (or insert other programming methodology of choice) or not?
As US blogger Steve Yegge said some time back now, “When I was growing up, cholesterol was bad for you. Nowadays there’s good cholesterol and bad cholesterol.”
Perhaps this ‘confusion’ is the raison d’etre for Stobart’s company today then? Perhaps it’s the same reason why IBM has a ‘practice leader’ (I'm sure they forgot to slip the term evangelist into that job title somewhere?) and why they all blog a) so much and b) with a fair degree of style.
IBM’s Ambler has a blog that ranks globally alongside many professional journalists including (ah-hem) my own in the realm of software application development – and Unboxed Consulting is doing its level best to bring sexy cartoon inspired chic to the world of coding almost single handedly I would say.
So nuclear power, no thanks – but Agile power, yes please but not all the time? Something like that isn’t it? Or am I showing my age?
PreviousComments on this post
Agile methods are good at dealing with a particular class of problem seen in business software development: Changing requirements. Waterfall development was (I use the past tense in hope no-one uses it any more) deeply flawed because no matter how well-written your specification was, it was out of date by the time the implementation was ready.
Agile was created to overcome this problem by doing small amounts of work that could be completed before the requirements changed too much. It's also a reasonable guard against the customer (internal or external) not really knowing what they want, since you can build the parts of the application the customer can describe.
Agile only solves problems with changing requirements. It doesn't solve any other class of problem — performance, stability, compatibility — so applying it everywhere is, as you say, ridiculous.
@Jonathan, I agree. Don't confuse a team management technique with an architecture. Our customers generate applications with billions of records and millions of hits a day using Scrum to manage their development teams.
What makes their applications perform, stable, compatible, etc. is having a competent team build on a proper architecture. The thing Agile helps with is having ideas discussed and peer reviewed continuously throughout the lifecycle, not just at key milestones, continually improving the applications. If scalability, for example, is important, bake it in and test it every iteration as the solution forms, not at the end, when everything's built.
There is not a simple sound-bite answer on how to deliver successful development projects but agile practices have higher success rates because they encourage the common sense practices that the non-virtual world has been using forever. (In success I also include early and cheap failure but that's a whole new discussion.)
Thanks Jonathan (as always) and thanks Richard too,
Some good leveling words there. I wonder if the big vendors out there who champion Agile would take your collective words of advice to heart, ever?
Or will they stay focused on steamrollering us with the big "Agile-Inside" sell?
It is, I fear, perhaps, a big ask.
AdrianB
