Planning enough time to do it

Most people like to find all options they have available to them, weigh the pros and cons of each one with the best possible result being the desired outcome. However, there is one variable of the outcome that is often neglected, the duration to reach the outcome. Instead of discussing the plan, if the first suggestion is reinforced with agreement by another automatically more often than not something some work will begin. It might not be the best choice but something is being made whilst a better idea is being decided upon. The something that is getting done if put forward by someone sufficiently clever will more than likely be relatively close to the best idea when it’s determined. Also it will most likely be able to get adapted to work before the completion of starting it from scratch in the present moment.

The development cycle for software is very similar, there is always the discussion of whether it would be quicker to adapt something that already exists, i.e. the time to learn its structure and behaviour versus the time to work out your own and build it. In smaller systems the first option is often the quickest and in larger systems it is easier to make your own.

This is the argument the committee in my head is having at the moment over making CMS, I wasn’t going to tell anyone about it but I typed most of it out anyway in a comment I was going to make at KCNB and I thought that I’d rather keep it for posterity here and drop a trackback to her.

Hazel, the owner of KCNB, is coding a game as a degree project, she’s a little perturbed about spending so much time planning and using the scrum development method. In a nutshell to adhere to its methodology you say what you are going to do and do it in the time allotted.

Accordingly you need to workout, usually in length what you can do before you do it which often means a lot of unproductive talk followed by anticipated achievements which can be very reassuring to the person looking at the bottom-line of missing a deadline.

The method I was primarily taught was the RUP which in a nutshell is making a broad plan incrementally more accurate until the problem becomes little manageable chunks which don’t necessarily need the attention of the starting team.

This means 4 people could do the planning but 20 could do the coding as their bit only requires them to know what goes in and what must come out. Whereas the scrum method is best suited to having those who start a project finishing it aswell as newbies brought in would take a long time to see what their doing in the grand scheme of things, this also means that the man-hours of work can not be distributed in the home stretch.

Working on my own I write the plan as I go, moulding and adapting it as I need, however working as part of a team that aren’t mind readers I find it best to create documents and drawings to show my intentions, and if someone has the same idea as me I immediately back them up to get going, not because I think I know best but because if 2 people have the same idea to solve the problem is can’t be that bad of an idea and its mostly likely simple “which is the ultimate sophistication” (Da Vinci).

Both planning frameworks have pros and cons but sometimes its best to make it up as you go along, its risky but experience and talent with a little luck can sometimes reach the finish line quicker even though they’ve actually done more work (coding) and less planning than another team that have done less coding but more planning. It’s all a balancing act between a time intensive plan making a beautiful and efficient system versus a slapped together quick’n’dirty one.

One thought on “Planning enough time to do it”

  1. Thanks for the thoughts and suggestions. One of the key reasons we are using SCRUM for our project is that we need to be able to make changes as quickly and cheaply as possible throughout development. Even with a completed, well thought through plan, it’s still necessary to constantly refine the design as you find out what’s “fun”. We were also using several different poorly-documented open-source components which we weren’t able to fully test before we began.
    I think the real problem is that we didn’t consider how long meetings would take when we worked our how much time we had to spend on this project. I’m not saying we should cut down weekly development time to 5 hours and spend the rest on meetings, just that it would have been easier to estimate how much time to put aside. Guess we know for next time 😛

Leave a Reply

Your email address will not be published. Required fields are marked *