« Management by Procrastination
Seven Attributes of Effective Project Management »

Where Agile Project Management Doesn’t Work

August 23, 2009 | Author: PM Hut | Filed under: Agile Project Management

Where Agile Project Management Doesn’t Work
By Ksenia Woodgate

Many IT organisations have faced a question whether or not to develop using Agile. It has its own well documented merits – such as ability to motivate teams and increase their throughput, as well as deliver a product that meets the customer’s needs very well. A highly motivated team is also more likely to display a greater ability to innovate – a winner all around!

In this article, I wanted to share my own thoughts on the suitability of Agile to organisations or projects.

It seems a good idea to carefully evaluate whether or not to adopt Agile, and to what degree to adopt it, on a case by case basis. There are places where a traditional Waterfall approach could still work. In others, Agile can be of huge benefit. It depends.

From my own experience, I can see two areas where Agile might not work all that well. Both cases relate to organisations with cultures that are more regimented.

The first case is where a customer needs to fully understand the end deliverable before signing off on the dotted line to commence the project. So we are talking about a customer who is fairly inflexible in their approach. To receive a go-ahead to actually start building software, one would then need to put in place a comprehensive functional specification – which will be arrived at after a full-on analysis and design phase.

Of course, going Agile does not mean that the func spec is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. But not all customers will grant such a degree of artistic license to the project team. And hence it can also be a question of trust in one’s professional ability, judgement and skill – is there enough of it between the customer and the vendor? Can the customer “let go” and empower the project team to work out the smaller details using a suitable Agile methodology as the project carries on, or will every question need answering in advance?

The second case is where an organisation’s senior management interferes with the Scrum process, perhaps wanting teams to achieve unrealistic targets and add to its list over and above what teams say they can do – or maybe insists on reprioritising deliverables at short notice and still expect excellent results.

Such an approach can be destructive for any team trying to implement Scrum, as it will cancel the efforts made by the participants to work out their own capacity and commit to work on their own initiative and own understanding of their skillset. Senior management must fully buy into the Agile process and remain strictly at arm’s length. If it does not, the process will not work efficiently and result in lesser motivation and decreased productivity.

The Scrum process allows for priority calls to be made – but only at the start of each Sprint. If, half-way through a Sprint, serious external circumstances cause a massive shift in priorities rendering the current Sprint a total waste of time, the Sprint can be stopped – and this is the only time this is allowed. However if an organisation tries to change priorities half-way through a Sprint by introducing new key items into a committed iteration, whilst Scrum masters allow this to happen under pressure from management, the process breaks down. Needless to say, this causes stress to all participants and often does not get the item done on time anyway.

Yet again, we are talking here about trust. This time – in implementing Agile – between senior management of an organisation and its Product owner, the Project team, and the team’s Scrum Master. When an organisation fully empowers its employees to deliver (whichever software development method is preferred) and gives them all suitable tools to do so, it will have the greatest chance of success, and trust in its teams is a huge step towards such empowerment.

Ksenia Woodgate has over 10 years’ experience in the investment banking arena and is currently the director of PointBeyond, a company specialized in managing MS SharePoint implementation and customisation projects. PointBeyond is located in London, UK.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Sunday, August 23rd, 2009 and is filed under Agile Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories