The Dangers of Planning Time on Software Projects

Home » Agile Techniques » The Dangers of Planning Time on Software Projects
Photograph of columns in old building

Agile techniques favour responding to change over following a plan. I can’t remember where I read it, but I took it years ago that Agile was about staying focused on user functionality over and above trying to plan every last detail because it had been acknowledged that it isn’t possible to do that in a changing environment. Time planning is the subject of this post.

The Dangers of Planning Time

I have worked for many customers where the primary focus of management is the time taken by developers to create the software. As though development is some kind of production task. I believe that the only production we do is publish the project or cut the cd at the end of development. The reminder is design, not production.

The danger of trying to plan time taken over functionality, is that faced with having to justify every minute spent, developers (especially if not architecture aware) could take short-cuts that compromise the architecture.

This sounds crazy as I write it but it happens. If the culture is for developers to look good by getting work done quicker than others, some are more likely to take short-cuts that result in less code but poorer architecture with more dependencies. The end result is the software is quickly reduced to a complex tangled mess. The same developers can then go on to defend their actions, e.g. that they created performance improvement that obfuscated the code when they had not tested the benefits beforehand. This makes them sound good to their managers who think they are working with an expert when the reality is that the developer needs further training as they are just making a big mess.

This can all come from focussing on time rather than functionality. In the Agile world, a complete feature can be removed from a sprint if time is short. Or a more aware developer could take a short-cut that does not compromise the core architecture. Agile techniques have more than one level of protection against this type of practice which I may blog about in future.

Example

An example of the dangers of planning time and trying to control it to the nth degree is as follows: Say for example, the managers say that they are “Agile”, they will allow for an hour of code review every four hours spent on coding. Sounds reasonable? (apart from this isn’t Agile and is totally arbitrary)??

The programmers work on this basis, filling out their time if no review is required, so they don’t get accused of not reviewing the code properly, or skimping on reviews if there isn’t enough time. I don’t need to say what the end result is.

The correct way to do this is to give the team as much time as they need for reviews, and measure the time taken. Thus as a manager you can learn the true velocity and the true situation from the times actually taken and if the software actually stands up subsequently.

I would say that as a developer, if you can’t find a WTF in five minutes of looking, you are most probably done, so reviews should take as long as needed until you reach that point…

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!
One Response to “The Dangers of Planning Time on Software Projects”

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">




Top Posts & Pages

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

From helping teams understand the boundaries of self organization to creating safety around things l [...]

- mike@mountaingoatsoftware.com

Your team is probably spending too much time in sprint planning meetings. Here’s how to spend less t [...]

- mike@mountaingoatsoftware.com

Debating between Scrum and Kanban? Guest author Brendan Wovchko offers five advantages Kanban has ov [...]

- mike@mountaingoatsoftware.com

Most individuals know that multitasking slows us down. It has an equally negative effect on agile or [...]

- mike@mountaingoatsoftware.com

Announcing the world’s only dating website for Scrum Masters and product owners. [...]

- Scott Hanselman

I think that we, as an industry, are still figuring game streaming out. It's challenging to fin [...]

- Scott Hanselman

If you find yourself learning C# and .NET and come upon the "Run your first C# Program" do [...]

- Scott Hanselman

I was at the Microsoft BUILD conference last week and spent some time with a young university studen [...]

- Scott Hanselman

I've blogged before about the Azure Cloud Shell. It's super cool and you can get your own [...]

- Scott Hanselman

"My fellow Windows users, our long national nightmare is over." The Windows Terminal is he [...]

Meta