« Helpful Advice for Managing Project Sponsors
Modern Project Management »

3 Ways to Kill Focus in Agile Projects

December 10, 2009 | Author: PM Hut | Filed under: Agile Project Management, SCRUM

3 Ways to Kill Focus in Agile Projects
By Ketil Jensen

Focus is in my opinion, one of the key ingredients in agile software development and teams with the correct focus will consistently deliver more value to the organization than none-focused teams. Obviously.

There is more than one reason why focus is important within software development. Not only must the team focus on the stories at hand, they must also focus on delivering the right code for these stories. When you know that 56 % of all errors in software projects stems from the requirements you realize that this is extremely difficult. Yes, software development is hard and it is really not surprising that so many software projects are late, more expensive than planned or even worse: fail to complete at all.

Focus is hard to retain over a sprint and especially over several sprints. If you still feel it could be harder here are 3 ways to make it harder to retain this focus:

  1. Make sure the team isn’t seated together

    Henrik Knibergs states in his book, Scrum and XP from the trenches, that it is absolutely important that the team sits together in Scrum projects. This will make it easier for the team to communicate, they will feel more like one unit, they can all see the task board and so on and so on….

  2. Staff up with lot’s of 50% or less resources

    Context shifting is extremely expensive and resources that are only committed 50 % or less will need to switch context more often than 100 % resources since they have other business to attend to when they’re not working on your project. You simply cannot say that two 50% resources is equivalent to one 100% resource. Programmers are not machines. If they are allocated to more than one project at a time a great deal of time will be spent in task switching. Managers often get this wrong.

  3. Have unclear priorities

    The product owner doesn’t have to have a 100% priority when the team starts the sprint planning. Various aspects may arise during the planning which can affect the priority. However, it is very important that the product owner is present during planning and able to decide which stories to prioritize. When the sprint planning is over the team needs to be able to focus on the stories they have committed to. Get this process wrong and you could soon find yourself in a situation where the product owner tries to prioritize one or more new stories into the sprint. Of course, if you are playing by the book, the way to resolve this is to cancel the current sprint and start a re-planning. This is expensive, so most product owners will try to avoid this as much as possible. If you are navigating in a turbulent environment with lots of changes all the time you can probably remedy the situation by keeping the sprints short and thereby give room for frequent changes to the priority.

Ketil Jensen is currently a senior consultant at Miles AS, a Norwegian based consultant company. He has a strong interest in Agile Software Development, Test Driven Development, and Domain Driven Design and testing. Ketil maintains an interesting blog on Agile: Walk the Walk.

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

Related Articles

This entry was posted on Thursday, December 10th, 2009 and is filed under Agile Project Management, SCRUM. 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.

2 people have left comments

You could simply delete “Agile” and then these issues describe the proverbial 99.9% of software project problems.

For point 3, if you are receiving that many changes to requirements then stop. There is no need to ’sprint’ or do anything at this point. What needs to be done is for the product manager to renegotiate terms with the customer (or sponsor). I suspect some will gasp at the prospect of doing so, but it is a legitimate option that organizations, managers and teams neglect.

David Pletcher wrote on December 14, 2009 - 5:38 pm | Visit Link

I agree with David above, there has to be a point when the Agility of the Agile Methodology is overrun with the varying expectations of the client. I’ve completed a task for NAB where the number of requirements had doubled from the initial quote, and the business person was renowned for pressing more after the quote was given and accepted.

We used to be told dont provide anymore func pts than the spec asks for because the customer will likely change their mind.

Its bad management practice in Agile or Waterfall to accept every new story or use case or func pt, without standing back at some point and seeing the trend of engagement with the client.

Rodney wrote on April 12, 2010 - 11:20 pm | Visit Link

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