Does anyone have any good techniques or examples on how to promote the benefits of Agile development practices in a waterfall driven corporate environment?
We recently switched to feature based development, using trunk & branch code management, we have a one project running well with scrum, but its hard to get this approach adopted by the wider masses.
I just wondered if anyone else is battling the corporate machine?
If you already have a scrum project running well in your organisation, 90% of the battle is done.
I'd suggest taking some time to write up a case study, maybe put it up on your intranet or similar. Find out who leads the other projects you would consider good candidates, and have a chat to them. Don't come off all preachy - Just 'hey, well, I we used to have the problem you described, if you ever want to take a look at how we're running projects now, have a look at http://xyz/
The other option is to get someone high up in your organisation to champion it. That will make the transition much quicker, but requires you to find a suitable champion and convince them of the benefits.
Better ROI in general.
A waterfall process makes itself redundant by the time you've finished due to the amount of time it takes to complete. By the time you've finished the client has changed the way they work.
This is why iterative development and iterative releases work so much better than waterfall. You'll spend less time developing redundant packages and you'll make the customer happier too by being better able to respond to the changes in their requirements.
The paradigm in general is better. You don't blueprint and create perfection. You assume from the outset that it wont be perfect and you "grow" the software by making it flexible and easy to change.
G'day,
You might like to have a listen to Ken Schwaber's talk on Scrum over on IT Conversations.
While being focussed on a particular "implementation" of Agile, it does cover a lot of the basic reasons why Agile succeeds.
You might like to check out the articles on introducing agile over at the Agile Alliance as well.
HTH.
cheers,
Rob
I think the best way is to start out small and prove that the approach actually works.
As discussed earlier, Scrum and other agile techniques can be introduced step by step.
If the organisation doesn't recognise that they have a problem (and many don't want to know) then you have an uphill battle.
You might suggest that you reduce the scope of projects (and thus the size of the interval between deliveries) without otherwise changing the methodology.
The phases of waterfall, which might include analysis, design, code, test, implement and review, aren't of themselves the problem. Map them to a project with scope restricted to a single feature: analysis becomes understanding the user story, design and code become a TDD loop, test is user acceptance and then we put it into production. We just did a smaller unit of work in a few days instead of the entire system in a few years.
It might work.
is a good resource for agile info particularly for tech folks moving into management.
Manning Publishing has a book by Greg Smith and Ahmed Sidky on this very topic : link text