Agile development methods - good practice or poor management?
 Agile development methods are very much in vogue at the moment. These methods abandon the usual "analyse, design, develop test" waterfall approach in favour of an iterative one where requirements are gathered and expanded on in a series of cycles. The theory is this produces software faster and much closer to what the business really needs because assumptions, business practices and opportunities to improve are uncovered as the participants get to play and explore rather than at one lump at the start of a project.
Unfortunately these methods can also be used by developers to hide poor design practices, a lack of knowledge and - frankly - laziness.
An argument developed between a "project manager" and myself over an "agile" method that I suspected was being used as an excuse for hacking code together. I explained that I, as the client, expected each of our workshops to result in a document that set out what we had agreed, the assumptions we had made, risks we identified and things we had agreed to park for another time. It didn't have to be war and peace, it could be on PowerPoint for all I cared, but that control had to be present.
A forceful (in tone only) argument was put forward that this wasn't what agile was about, but the PM agreed to my wishes.
Three days after our next sessions I chased him when nothing had appeared. Apologies, then twenty minutes later a process flow appeared that had clearly been put together on Visio in about ten minutes flat. It didn't capture what we discussed, didn't match what I thought we'd agreed upon and missed a couple of what we'd considered "essential" requirements out.
Time for round two of the discussion.
I listened patiently as I was told that documenting things wasn't really what Agile was about. It was about building code and getting things done and that surely I could appreciate that. Anyway, he was an expert in agile methods and I, dear client, was an expert in something else and that surely I would appreciate that.
This I listened to.
And then I replied.
As the client it was my requirement that nothing was missed. At that moment in time I had no evidence to demonstrate that the requirements my team were coming up with were being understood, nothing to check back against to make sure what was being designed and delivered was what we asked for and no way of holding his team (or mine) accountable. All I was getting was some software to look at pretty much weekly, which I then had to second guess against a list of requirements that my team were keeping on pads and bits of paper.
Oh, and I, dear Project Manager, had been working with "agile" methods such as DSDM and AVM since the mid-90s. So please don't patronise me. I know what documents should be produced and you're not producing them.
There's a very important lesson here for business people who are confronted by software developers claiming they use agile methods. It is true that things are going to go faster and there's going to be a lot more involvement from the business. What isn't true is that there won't be documentation such as requirements lists and risk registers - it's just it won't go through a formal sign off loop before someone turns it into software. If you suspect for a moment that the agile development you're working on is out of control or being poorly managed put your foot down and get control back. Ask for documentation, insert a simple "approval" cycle where you get to see workshop outputs and stay on top of your developers.
Above all, don't be fooled. Agile methods require a lot more discipline around requirements gathering and project management than just putting software developers and business users in the same room.
Previously on this blog...
the global leader in Contact Center Consolidation 2.0
2.0 has become a meaningless addition to already poor tag lines.
A dozen beautiful images of Saturn
Wired presents a dozen of the best images from the Cassini mission
Setting up shop in a new country: beyond the website
Building a website for multiple languages is not just about translation. It is a critical business decision that has to be taken carefully.
Why call centre staff deserve your respect
If call centre staff set the first impression for your business, why do we treat them so badly?
Becoming a Specialist? A hard decision to make ...
Specialising requires hard strategic decisions to be made about your business.
When good people move on
Losing a member of staff to another company is not necessarily a bad thing
The quest for quality in Agile Software Development
Why quality assurance remains a central part of project management, regardless of the use of Agile methods
© 2010 Ross Hall. All Rights Reserved.
If you wish to use any of the content from this site please contact me.
All contents provided for information purposes only.
|
|
About Ross Hall