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.
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…