In answer to your questions, I’d say that we are predominantly a waterfall shop, the Project Office took the time to define their own process which, if I remember rightly, has the following phases: scoping; requirements gathering; define; development and release. The process has always been sold as a menu and not a recipe, ironically though, I am of the opinion that the 80 odd pages that are filled with the details of the various activities that should be undertaken as part of any given phase are either never read by the BAs / PMs or the sheer volume of information is so overwhelming that they are misunderstood and could perhaps as a result, be seen to be prescriptive. This really is just my perception of the situation though.

That said, there are now 3 teams that have taken steps to becoming more Agile, 1 of those is lead by a Dev Lead who is doing a great job of running the team using Scrum and has support from the Project Manager too, he also gets all of the development related methods that can be used to increase the teams agility. The other 2 are doing what I would consider to be some sort of weird mix between Waterfall and Scrum without any of the other practices that I would consider make a team truly Agile.

The above gives a good indication of what we are doing from a project management perspective, from a development stand point we’re quite a way off too I think, for example there are a large amount of our permanent staff (we are currently running with a high percentage of contract staff) a large number of which struggle with anything more than a basic understanding of OO concepts and design patterns and certainly don’t believe there are benefits to be had from of unit testing or refactoring. There are those however who do and I think it is for me to look to those people and to explain how those practices aid a move to becoming more Agile and to get them to spread the word.

It’s worth noting that we do have a Continuous Integration environment which is used by some of the developers to build and deploy their applications, I’d be surprised if there were more than a handful of developers who are checking in little and often.

All of the practices that I mention above are obviously something that I will work towards bestowing upon people both through coaching when I get the opportunity and the document that I am working on described in my original post.

I take your point about the mud sticking and the points that you make in your penultimate paragraph are really useful, thanks. My intention with the document is to set out a number of activities that I see are common amongst all projects and describe practices that I think should be used rather than trying to recommend a new process. Thanks for the book recommendation, I’ll get a copy ordered.

The NetObjectives presentation is excellent and carries some points that are very similar to those made in Craig Larman’s book: Agile and Iterative Development, A Managers Guide (a link for which can be found on my books page http://danrough.wordpress.com/books/). I’ve read it recently and thought that it was excellent, definitely worth a read if you haven’t already, he makes a very good and reasoned argument as to why Waterfall based projects tend to failure and how Agile principles and their associated practices can provide tools to avoid those failures.

I hope I’ve covered the questions you posed, if you want to continue this conversation I would be happy to, my email address is dan dot rough at gmail dot com. Thanks once again for leaving the comments.

Dan

I think your passion should be recognised but the technology industry has taken uncountable silver bullets and managment should be rightly supsicious of taking another one (especially from a fundamentalist ).

Agile development methods seem to have some real benefits but if the benefits are not clear along with when to use it (lifecycle model selection) and how to apply it then it can sound like a team or ten of developers throwing mud at the walls and seeing how much sticks.

I think you have to demonstrate how you scope; schedule; budget, assess and mitigate risk; test; support and apply entry / exit criteria on varying scales to projects that are “Agile” compared with some or all of the traditional lifecycle models, pure waterfall, modified waterfalls (sashimi, with subprojects, with risk reduction), code and fix, spiral, evolutionary prototyping, design to schedule, design to tools etc.

I think Rapid Devlopment by Steve McConnell would be a good read for you.

BTW Enjoy the blog, keep it up.