Zealot isn’t a word that you (by that I mean me…) come across too much but I’ve encountered it twice recently. I’ve been speaking to a couple of the senior management team about how I can sell Agile throughout the organisation and both of them have commented on the language that I use, one going as far telling me that I can sometimes come across as a zealot when I talk about Agile to people and if I remember rightly, the other told me that I can appear to be a fundamentalist.
Whilst neither of these descriptions are great from a personal perspective, the feedback is obviously useful and if I’m honest, it’s fair comment.
I want to see Agile principles and their associated practices adopted across the organisation, I think they offer a lot, both to the business and to the developers involved. Having given the feedback consideration I went away and thought about what I stand for and how I can communicate that to people in a manner that won’t alienate them to me.
My starting point was to think about what Agile means to me and to come up with 3 points. I’ve detailed those below:
- About setting up development teams to embrace change, they do this through intelligent solution design and with increased involvement with the customer to understand business priorities and associated requirements.
- About a process of continual planning rather than attempting to predict the outcome of everything in advance.
- About delivering increments of working software to the client, both to suffice business requirements sooner but also to allow them to understand the capabilities of the software that we can produce for them.
I’d be interested in hearing other peoples’ thoughts on this, I must confess that I do find it frustrating that people just don’t seem to get what to me, are the obvious advantages.
I also volunteered to one of the afore mentioned managers to write a document describing how I see Agile development working here. As that comes about I will post samples.
braek for caek 
It would be interesting to hear what project managment and software developments methods are currently used and how effective you think they are in different scenarios.
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.
I’ve just watched the executive briefing you linked to the other day by Net Objectives and thought it was great. I’m looking at how to run a big build cycle at the moment so may incorporate some of this.
Thanks for your comments Rob, it’s good to know that there are people enjoying my ramblings.
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 https://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