blog

by Cindy Edmonds

As a Project Manager I have managed the delivery of projects in Agile environments since 2006 for organisations that vary in sector, size and culture. I have delivered Agile projects for the national broadcaster in the UK, for digital media agencies and for the largest telco in Australia. While there is no ‘one size fits all’ prescription of which techniques to apply, there are definitely some pitfalls that are common across all Agile-flavoured techniques and may be managed if identified early.

My Top 5 Tips to avoid these common pitfalls are:

Tip 1: Tread carefully with Agile, if your customer invested heavily in a requirements phase.

The lack of a requirements phase is crucial to the relationship with your customer on an Agile project. I have been on two different projects where the customers had previously invested in a requirements phase. On one project the customer had invested $1.2m in a requirements phase which defined their business need in order to produce a business case. The IT team which was then engaged to deliver the project wanted to ‘go Agile’ and collaborate on the requirements at the same time as building the product. They also selected an off-the-shelf product that would need to be highly customised to meet the vision that the customer had emotionally and financially invested in during Requirements. Once this investment has been made it is very difficult to get your customer to happily start again or abandon their investment.

Agile projects require a flexible outcome and a constant prioritisation of scope in order to be successful. Part of the success of this approach is taking your customer on a journey of defining and refining business value of the features and working with the team to create the best solution. This may result in a new view of the product and a refined scope. If you are entering an engagement where the customer has already gone through a significant scoping or requirements phase, you need to think very carefully about adopting Agile and how your customer’s previous investment and expectation will impact your Agile delivery.

Tip 2: Don’t forget that the Product Owner is very important on an Agile project.

Clearly the most valuable statement on the Agile manifesto relates to customer collaboration. The benefit of removing the divide between customer and supplier, or between IT and the Business, and moving towards a collaborative delivery is the single most important reason to adopt Agile. Many methodologies can deliver a project, but the collaborative approach advocated by Agile is what can make your experience vastly more enjoyable for your customer.

Your customer in an Agile team is represented by the ‘Product Owner’, a Scrum term with a corresponding variant in the other Agile techniques, and the success of this role can make or break your project. The role and its responsibilities, which include setting the priorities and owning the Product Backlog, must be clearly defined and understood by the Product Owner. This is to ensure that we are delivering the product that the customer wants, and not what the team thinks they should have or that the technical team thinks is necessary without customer agreement.

It is critical that the Product Owner is a decision maker in the organisation and not a ‘go-between’ as the person needs to make decisions on which features go into the product and be able to champion and defend these choices within the organisation. On the most successful projects I have had the Product Owner co-located with the team and being involved in all planning and development conversations. It is easier to negotiate scope with someone who is part of the team every day rather than someone who is removed and who you deal with only via a Project Plan.

Tip 3: Ensure that your customer understands their commitment to Agile.

If you are working for your customer as a consultant and, particularly, if you are managing a team with delivery responsibility, you need to ensure that the contract between you and the customer supports an Agile way of working.

Ideally Agile contracts need to recognise the flexible scope and should be Time and Materials. Your customer needs to understand the time commitment that will be required of their staff, particularly the Product Owner, as they will need to be part of the team and collaborating constantly.

Tip 4: Identify business benefit early and balance it with technical risk.

If you have not identified with your customer the specific benefits for using Agile to deliver projects or develop software, you will run into problems and mismatched expectations.

Showing your customer a potentially shippable increment of your product very early in the project can thrill them. However it is very important that you balance the planning and delivery of features that the business value with technical risk. This is a controversial area within Agile and there is a lot of debate around big upfront design and emerging design following the principle of ‘defer every decision until the last responsible moment’. The Agile camp is divided on this topic so the best approach is the pragmatic one.
Spend time with your customer defining the features that will deliver the most business value in the soonest amount of time. Ask your customer which features they would consider delivering post-launch and which features make up the bare minimum set of things they would need to have a basic product. Spend time with your team identifying features that introduce most technical risk and balance your plan to deliver both.

Tip 5: If you are asking whether you’re doing it right then you’re not asking the right question.

Agile inspires passionate debate. I have been to a number of Agile conferences and worked on Agile projects where I have witnessed or taken part in heated debate about what is or isn’t Agile or whether a project is Agile ‘enough’. The passion and debate around Agile implies that practitioners have a high level of engagement with their work. However it can also introduce a zealousness and a focus on ‘right’ and ‘wrong’ which can create a hothouse environment with more emphasis on ‘doing the things right’ than ‘doing the right things’.

Posted January 23rd, 2012
categories: Blog The Project Leader