Tuesday, 17 March 2009

Agile by Stealth

I don’t know how many other people have witnessed the scenario where someone goes to senior management clutching a bunch of books and papers on Agile development, asking if they can do Agile on the next project? The usual response from senior management (who aren’t usually tech savvy) is a disguised fob off. In most cases they don’t even know what Agile development is so find it easier to dismiss. The types of organisations I’m referring to here are usually well entrenched in the bowels of PRINCE2 methodology. And no, this isn’t a dig at PRINCE2 as it has its place, and it can coexist with Agile approaches.

Trying to release these strongholds from the shackles of PRINCE2 is extremely challenging. Many training and consultancy companies who evangelise Agile development talk about organisational transformation to enable Agile to happen. This can only work if cascaded down from the upper Escalon’s of the company and is perceived to be a big undertaking for most organisations.

If you are lucky enough to work for a forward thinking organisation that values its employee’s opinions and is willing to embrace change then go for it and adopt an Agile approach to software development. Do it properly though and bring in external help if the size of your organisation warrants it. If however, you’ve tried to introduce Agile approaches to your organisation and you feel like you’ve been fobbed off then there is another way, Agile by Stealth.

Why do people ask permission to do Agile? Agile shouldn’t be taken as an all or nothing, or a one size fits all. Agile provides you with an extensive toolbox of approaches that you need to pick and mix from to suit the needs of your project.

What I find is that if you announce in an organisation that you’re going to do Agile, you are instantly met with a lot of resistance. Why is this? Are they scared of the unknown or just resistant to change? Remember, most people don’t know what they like, they like what they know so any attempt to take them out of their comfort zone will be met with resistance.

As I said earlier, look at Agile as an extensive toolkit and pick out what’s best for your project. You don’t have to jump straight into hardcore SCRUM, XP, DSDM, RUP, or any other methodology for that matter and go for a purist approach, which is likely to fail if you do. One bit of advice I’d give though is to make sure you read up on and understand the principles of Lean Software development. With such an extensive toolkit you risk introducing a lot of unnecessary wastage to your development life cycle, so only adopt what you need.

I’ve listed below some of the practices that development teams can introduce from the Agile toolkit without the need for any management approval. These can sit very comfortably within a PRINCE2 stronghold and will drastically improve software quality and project success, even if you’re not doing Agile in the purest sense:

Automated Testing – when I suggest this to development teams the first reaction is “we already do unit testing”, but unit testing is only one part of automated testing. Unit, functional testing using products like Selenium, security testing, and performance testing are other methods of testing to automate. This blog post doesn’t attempt to go into any detail on these approaches so go fire up Google and get exploring. If you’re asking yourself “why is automated testing important” or even “what is automated testing”, then again, go look it up on Google. It’s too big a subject to cover here.

Continuous Integration – this should be one of your high priorities if you’ve got multiple developers on your project and CI can drastically reduce development time by removing the need for a final integration phase of a development cycle. It also weeds out all those annoying integration issues that usually result in an element of rework by facing up to the problems at the point they occur and still fresh in the developers mind. Doing a build upon check-in is an opportunity to run your automated suit of tests (see above) and alerting your development team when the build is broken.

Daily Build (Nightly Build) – Many projects I work on have both Continuous Integration as well as a daily build in place. The reason for having both is that some automated tests can be extensive and take quite a bit of time to execute. For example, you wouldn’t want to run a performance test which lasts an hour or so for each check-in made to your source repository. The daily build is an opportunity to make a deployment to a staging server for stakeholders to view, preferably using an automated deployment process.

Short Iterations – When defining Work Packages within the PRINCE2 framework, just define them as short Sprints but with a different label to keep it within the PRINCE2 framework. Other terms regularly used within PRINCE2 and MSP are staged deliveries.

Kanban, Burn up, and Burn Down Charts – Project Management Offices and Senior Management constantly demand progress and status reports. Quite often this produces friction between developers and management due to the burden of collecting data. A great way to stem the tide of status requests and progress reports is to set up a series of Information Radiators. The Kanban system is a great way for multiple developers on a project to self-manage and to show exactly who’s working on what and what the status is. Burn-up and burn-down charts are great tools to represent the likelihood of the current development phase coming in to land on time. These methods have the distinct advantages over traditional time recording systems that they don’t put an admin burden on developers, tend to be more accurate, and are much more affective at communicating progress.

Test Driven Development – the first mistake most development teams make with TDD is that they write unit tests for absolutely everything! Always keep Lean principles at the forefront of your mind and only write unit tests for complex or high risk areas of your code base. You can easily check for adequate code coverage by using code coverage tools such as nCover. Constantly look at ways of automating the testing of code and maximising test coverage. TDD isn’t just about writing test cases in nUnit before producing production code. It’s an approach that starts upstream with your Business Analyst. If your Business Analyst can learn to articulate requirements as a series of test cases then you’re well on your way.

Prioritisation of Requirements – One of the core principles of Agile development methodologies is the ability to respond to change and actually embrace change. This is through short iterations and re-prioritisation of requirements at each stage boundary in close consultation with the customer. This usually results in developing the high priority requirements first to a releasable state and then take stock to either add or remove requirements before commencing with the next development iteration. Adopting a phased or staged approach to your project will open up the opportunity to revisit the requirements and priorities at the end of each stage. Most PRINCE2 projects that I’ve worked on already have a pragmatic phased delivery plan, but quickly lose agility when constrained by Change Control Boards and bloated governance. This is probably one of the more common areas of incompatibility between PRINCE2 and Agile. If you are in a position to establish and write your projects’ change control procedure then this is easy to fix. ;)

Communication & close collaboration
– having your key users or stakeholders working with your development team is another pillar of Agile. Good communication and close stakeholder management is a pre-requisite for any methodology. I always set up a staging server on every project and make sure the automated daily build deploys a working piece of software to the staging server so that all stakeholders can see the work in progress. This results in no surprises at the end of the development phase and ensures expectations are managed daily throughout the phase. If you’re not as brave as this (it does require a lot of caveats) then you should aim to review the software as its being built at least once a week with your key users and stakeholders.

At the end of the day, delivering software is not easy and there’s no magic formula. No individual methodology can guarantee you success so it’s important to increase the size of your toolkit by learning about other approaches to software development, enabling you to adapt to the needs and circumstances of individual projects.

The key message is this, no where in the PRINCE2 or MSP manual does it say “you MUST NOT use any other methodology, approach or tool with PRINCE2”. So, stop asking to ‘do agile’ and get on with it.