Speed vs Predictability

Understanding which trait is most important to a project can be a big factor in whether that project is seen as successful. It can also help determine the best way to “manage” a project (in a “project management” sort of way).

A traditional waterfall approach to a project can attempt to restrict change and so looks good from a predictability point of view. We know the requirements up front (or think we do), we have a design we have signed off on, we can therefore know with some certainty the end date for this project.

When it comes to speed though, a waterfall approach has some issues. Firstly, there’s Student Syndrome to consider – the fact that many people will only start to fully apply themselves to a task at the last possible moment before a deadline. This can lead to wasting any buffers built into the original estimates and helps to explain Parkinson’s law – work expands so as to fill the time available for its completion.

Waterfall plans tend to have larger tasks on them with deadlines that are further away. Even if the work is broken down the focus on phases tends to be larger. For example, even though I know I should complete my task today, I know that it only really matters in 3 months time when this larger phase has a deadline. I can convince myself that things will get better, I will get lucky with the next task and so I can catch up.

Agile approaches focus more on embracing change so can appear to be less predictable. We don’t really know what we are creating or when it will be ready, but you will have an opportunity to really shape what we develop incorporating the best ideas of the time and deciding when we have enough value in order to release.

The Agile processes of daily standups(or scrums) and short sprints create a culture of constant targets and could be seen as a way of speeding up development. There is little scope for either Student Syndrome or Parkinson’s law to take effect here. Daily standups attempt to break down that large task we might have had with a waterfall approach and turn it into smaller daily commitments. By setting a daily target, apathy is never allowed to set in.

However, it is also this practice of daily commitments which could be seen to force teams to aim lower than they would normally. Rather than saying “I think I would like to get this done if things go well”, the group aims instead for a commitment – “I will definitely get this amount completed”. The very nature of it being a commitment means less is targeted and anyone attempting to commit to more than seems reasonable is questioned by the team.

This same thinking can also be applied to the “sprints” that an agile team will take part in; they could be seen as less like sprints and more like strolls as the amount they are “sprinting” for is reduced in scope in order to achieve a commitment. That’s not strictly true, a team should be tracking velocity, taking items from the backlog to fill the sprint and adding items that weren’t completed to a future sprint. However, teams and perhaps more importantly their stakeholders want commitments. Even if it isn’t seen as a commitment by the team; the innocent question at the start of a sprint “what can I expect to see in the product after this sprint?” can lead to an unspoken expectation of a commitment.

However, if a team constantly meets its daily commitments (or sprint objectives) then it is going to be more predictable, which could be seen as more valuable in some projects.

As a thought experiment, let us consider a task so important that we need to devote every single minute of our time to completing it. Surely, this is the route to completing it as soon as possible. Stopping work for a daily standup isn’t going to help us progress this task. The standup does offer the chance for the group to offer assistance in creative ways; perhaps someone else has already solved the problem you need to solve in another project, perhaps someone else is available to look at the problem with you and remove the blockages that have slowed your progress, perhaps the task can be broken down and worked on in parallel. So, the standup is a bit of a gamble, if nothing changes, the time is wasted, but you could save time on your project by attending.

This is one of the reasons the standup should be as short as possible; for all those people attending and taking the gamble that they will get a benefit from being there, if the gamble doesn’t pay off then the loss should be as small as possible.

By reducing scope a little with the daily commitment the group increases predictability, but also has a little spare capacity to help those people who might not make their commitment. A bet that will nearly always pays off is a very attractive proposition, and I think is one of the most powerful aspects of a daily standup.

I don’t think there is a simple answer to the question of whether speed or predictability is more important, but I do know from past experience that choosing the right approach is very important.

 

Advertisements

About Big_GH

Currently employed as a Software Development Consultant with over 30 years experience with computing. Started writing BASIC programs on the Commodore VIC 20, C64 and Amiga before switching to C and C++. Now spends more time helping others with their software and looking after the "bigger picture".
This entry was posted in agile, planning, process, Project Management, software development and tagged , , , , , . Bookmark the permalink.

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