Agile, lessons learned, Scrum

3 ways to kill focus in an agile project

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 team. 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: fails to complete at all.

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

1. Make sure the team isn’t seated together

I read Henrik Knibergs Scrum and XP from the trenches the other day. Excellent book with loads of great examples from real life on how to do scrum. Read page 57 and you will find Henrik is absolutely clear about this: It is absolutely dead important that the team sits together. 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 with 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. I think that managers often get this wrong. I definitely prefer to have 100 % resources in the team

3. 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 situation. Hence, you may have a situation. 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s