Recently I went to a seminar being run by Thoughtworks - a consulting company with a focus on agile software delivery (they're the company who built CruiseControl; the automated build server I use).

It was an interesting seminar and covered a few things from a perspective I hadn't really given a lot of previous thought to - that of the project manager.  I'll briefly cover some of the areas discussed.

Agile vs Waterfall:  Initially the seminar ran through the differences between agile and traditional (aka waterfall) projects from a PM view and explained how things "feel different" in an agile environment and some of the advantages you gain from operating in such an environment.

Cost of change: The cost of changes at various stages in a project lifecycle are fairly well understood from a traditional PM view - there's typically a nice graph showing cost vs project stage with the graph getting steeper and steeper the further the project goes on.  The agile cost change model is quite different and a graph typically shows a flattish line throughout the lifecycle.  Scott Ambler has a good article covering some of this in more detail. 

Simple Approach:  The "simplest thing that works" - it's not dumbing down everything and only doing the most basic of things, but rather an approach where we do "just enough" to satisfy the customers requirements.  Avoiding overengineering solutions, writing documentation that never gets used, designing functionality that wasn't asked for, or worse actually building it as well.  An interesting stat mentioned was that a Standish Group study showed that over 60% of software functionality is rarely, if ever, used.  When you consider the time and cost of that development it's a lot of investment for very little return.

Risk Management: Being able to identify and, more importantly, respond to risk in a quick and cost effective manner makes a huge difference for Project Managers who are typically forced to be reactive to problems instead of proactive.

Changes in scope (aka Scope Creep):  Agile is all about feedback and responsiveness and we expect changes in scope, especially when customers see work in progress software and realise that their original ideas maybe weren't so hot.  But scope is a major issues when working in a fixed price, fixed time, contracted development situation.  One of the really practical ideas was, with the customer, quickly assessing the impact of the requested change and showing what the adjustment means in both project delivery times and project costs.  Showing a customer what their handful of small requests means and then getting the customer to decide what they want to trade off can be a very useful exercise and will help enforce the collaborative approach that underpins agile projects.

Test Driven Development:  What was made blatantly apparent in the seminar was the value of TDD to success with agile and how a "write the tests first" approach is fundamental in ensuring that the rapid delivery cycles can still maintain quality, provides a regular confirmation that the code really works and that the defect rate remains low.  TDD also helps ensure a simple approach and forces people to think through the work to be done before jumping in and coding.

User Stories: From Wikipedia; "A user story is a software system requirement formulated as one or two sentences in the everyday language of the user".  User stories are very similar in concept to use cases, but without the detail that sits behind a use case, and include criteria for acceptance testing; i.e. what has to happen in order for the user story to be deemed complete.  In terms of delivering work, user stories can be thought of as the summary of all the work that occurs underneath that, such as writing a use case, doing a UI prototype, developing the code, testing it, and proving the requirements have been met.  If you ever have to  deal with tender requirements, it may be a useful exercise to group the one-liners from the tender into stories and to do prioritisation and estimation based on the stories.  Then when you win the contract you can then come back to the stories and have conversations with the customer over what the real needs actually are (ie base gap analysis around stories not data areas).  More information on user stories can be found at Advantages of User Stories for Requirements, Writing Contracts for Agile Development, User Stories

Local Optimisations and Completion: One of the more interesting things to come up was a conversation I had after the seminar around velocity and what counts as completion.  When I talked through velocity I indicated that we are typically achieving a velocity of between 0.4 and 0.8.   The Thoughtworks people were actually pretty impressed with that as they typically expect velocities of around 0.2 to 0.3, however their velocities are based around story points and the understanding that delivery is not just a development process but that it involves all people on the project, and that a story is not delivered until the customer signs off on it.  Because my control is limited to development areas and because we count items as delivered when they are internally signed off I'm are really only looking at part of the overall process.  By focusing on only the areas in which I have control i may be misrepresenting the real time required to deliver an item and may be missing slow downs in other areas where we are wasting time or that could be further improved.  In other words I may be locally optimising work at the expense of the overall efficiency of the project.  Hmmm, something to think about...

Story Boards:  Prioritising work with story boards is a recommended practice with agile projects and was actually used in the seminar to prioritise the requests from the attendees on what areas to cover.  It was really interactive, really quick and very useful and seeing it in action made me realise how useful it might be to do this internally.  I always used Excel for tracking priorities as you have a permanent record and don't have to worry about cleaners knocking items off whiteboards, but seeing how easily it worked I wonder if it's worth trialling it.  After all, switching priorities in Excel can be a little bit tedious at times.

Overall, it was a very interesting seminar and gave me a fair bit of food for thought and triggered some ideas for other improvements I might be able to make in the near future.

If you get a chance to go to one, it's worth doing.

Many thanks to the guys at Thoughtworks for their time :-)