stuart test blog

I’m attending the Agile BarCamp in Wellington to learn more about Agile and how the Agile methodologies could be applied to projects that don’t necessarily relate to software development.

My (very simplified) understanding of Agile so far is that it is a framework around software development that focuses on delivering lots of smaller releases instead of focusing on the end goal of releasing the final product. It’s a very flat-management style of framework, in that the project team should be self-organising and everyone in the team accepts responsibilities for the project.

I find all this very interesting in the way it could relate to infrastructure projects. The structure of most infrastructure projects that I’ve worked on all seem very "old school" compared to Agile methods…

Typical infrastructure project:

• There are usually two or more project managers that take responsibility for the project.
• They are managed by one or more program managers, plus there are business owners responsible for making sure that their own areas are covered, and other senior management also want to give input.
• The entire project is analysed and finalised before starting, through a lengthy process of tenders, proposals, statements of work, high-level architectures, detailed design plans, project plans, and gantt charts.
• It’s difficult to incorporate changes as the project progresses, and project managers are usually reluctant to do so anyway, as it pushes the project timelines over schedule.
• The project deadlines are always too optimistic, and run over regardless.
• Daily/weekly project update meetings take too long and don’t have any benefit to the progress of the project.

Compare this to how I envision an Agile approach to the same project would look like:

• Each member of the team responsible for the success of the project, with probably just a single project leader to shield the team from the politics and red tape that seems to be unescapable in bigger companies.
• The project is analysed and designed at a high level, and then broken down into smaller, manageable milestones that provide the customer with quick-wins and shows progress from early on.
• At the end of each milestone, you analyse what you’ve just done, learn from it and move on – implementing any changes that have come up along the way.
• Brief, daily meetings (stand-up meetings) to provide status updates to the other members of the team so that everyone always knows what’s going on.

The benefits of this approach seem immense, but there must be some downsides to it and my initial understanding is that customer fear is the main cause of pain when proposing or implementing Agile methodologies. This is another topic which I hope will be covered in the BarCamp.

The following table shows the original "Principles behind the Agile Manifesto", and how it would look if used for infrastructure. (changes emphasised)

Further reading:

• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Wikipedia – Agile software development
• Wikipedia – BarCamp