Notes on our project management 19:42 on Monday

I’d like to reflect on a couple of points in Biztech’s article on better project planning:

Replace phases with features

Originally I was looking for a todo list that would allow me to estimate the duration of the tasks. In fact, for a while I did use OmniOutliner for that. When I grew out of OmniOutliner, I looked at various products, before finally settling with the project management software Merlin. Maybe because I am a developer, and because I started my quest with a “task list” derived from features and requirements, I’ve never planned for phases. Always for features, and more specifically, for the steps required to build the features.

Re-plan after every feature

This is where we’ve failed. For a number of times we’ve fell victim to the curse of “let’s just add this small additional feature”. Without re-planning for the new features, the design of the code eventually breaks, and fixing becomes difficult. But next time, we will remember to re-plan.

Measure progress to predict the future

On the other hand, estimating and measuring is where we excel. We recently finished a project estimated at 176 hours, and we completed the planned features in 98.3% of the allocated time: just over 173 hours, to be exact. The trick here is to estimate every little task you do, and then check afterwards how you met the estimates. Do this a few times, and you automatically build a skill for good estimates.

I wonder if this blog post is slightly on the level of “cat blogging” (ie. “here’s whats new with my cat”). Apparently it’s not. More comments than usual. ;) Project management just happens to be what’s been on my mind lately.

8 Responses to “Notes on our project management”


  1. Rohan Says:

    For most projects something simple like http://www.statuswiz.com works.

  2. Niko Says:

    Rohan, I have no idea what that software does in reality, at least the site doesn’t do anything (it just reloads whatever I click). By the small blurbs I would understand it is a task manager, aka todo application. My most important need for project work is estimates and tracking actual time spent against the estimates. Even tracking progress is optional, I just need to know what happens in the end. Additionally, I now use Merlin to accurately convert estimates into calendar days, by taking into account our daily schedules, vacation days, and such.

  3. Visa Says:

    Here at Sulake where I work, we use the Scrum methodology for our software development. I know it’s a buzzword that causes headache or bursts of laughter for many, but for us Scrum has worked very well. In my own words, Scrum’s idea is that the work is split into “sprints” which in our team are currently 2-weeks long. The length of the sprint usually varies from 2 to 4 weeks in different companies.

    Before each sprint, the product owner (= client) represents the team the stuff that should be done. The sprint begins with a planning day where the team picks the stuff with the highest priority that they can manage to do during the sprint. Those things are split into the tiniest possible tasks whose progress will be followed throughout the sprint.

    On every morning of the sprint, the team has the daily Scrum meeting where each team member goes through the tasks he or she had been working on the previous day, how many hours are still left of each task and what he or she will continue working with.

    When the sprint ends, the project should be in a shape that can be demonstrated to the project owner or even released to the public. Then the cycle starts from the beginning with a new planning day and a new sprint.

    The good thing about Scrum is that the project will automatically be re-evaluated every two weeks. Also, because tasks are only planned for one sprint at a time, the planning is easier. The project owner is happy because every two weeks he or she will get something new to see. And most important of all, the developers are happy because they will always have at least two weeks during which the specs won’t change.

    Of course, Scrum works best with a bit bigger group of people than a team of two, but thinking of project in sprints and having a sprint planning could work well in a small company as well. You have to remember that sprint is not the same as a project phase. Sprint is always the same length but a phase in the project or the implementation of a feature can last longer than one sprint.

  4. Mikko N Says:

    Visa, have you been using Scrum with projects that last more than a year? With big projects you must have a clear idea what final deliverable should be. Otherwise you’re fucked ;)

    Correct me if I’m wrong.

  5. Visa Says:

    We’re using Scrum for the development of our own product, Habbo. In a sense, the project has lasted several years already. I don’t believe there is such a project that would require you to plan on the daily task level for more than a sprint ahead. In Scrum, it’s the product owner’s responsibility to keep the project on course in the longer term and take care that the deliverables are what they were supposed to be.

    I only have Scrum experience with an internal project. It may very well be that Scrum doesn’t work well when doing an external project with a strict deadline coming from an outside client.

  6. Sulka Says:

    Mikko – it sounds like you’re thinking Scrum somehow prevents you from having the clear vision. That’s not the case at all. In fact I think it’s important the product owner has a clear vision of the deliverable because as you say, when people don’t know what they’re aiming for, you’re fucked. And that’s true no matter which methodology you’re using.

    What actually happens with Scrum is that if you don’t know what you want, Scrum exposes that very quickly. Without the longer term vision the product owner will have trouble being able to commit to any development and will probably change focus after every sprint. When using waterfall, that typically leads to the customer wanting to spec out the project for a long time until they think they’re getting what they want and then a few months into the development, noticing their needs – the “vision” – has changed. Scrum says that’s fine, because that’s the way the world works.

  7. Niko Says:

    Visa, I think the idea of Scrum would be excellent for client projects. I can only talk about theory as I don’t have first-hand experience with Scrum or other eXtreme Programming methodologies, but my understanding is that the original XP idea to have these sprints was partly just because the sprints would expose the effects of feature creep to the client. On the other hand, the client would always have a “deployable version” of the product (which probably is only runnable in practice). Like Sulka said, the methodology was built around the pragmatic reality of ever-changing specifications, not the idealistic non-reality of “spec lock in January 2008, release in January 2009″. ;)

  8. Mikko N Says:

    Wise words guys. Luckily I have not been working in waterfall projects for many years, and I don’t think anyone uses that model anymore. But sometimes you just have to lock some specifications, for example data exchange formats for legacy systems not using XML ;) If you have a project involving different companies, then I believe you have to have a bit more formal (and less efficient) approach. This usually means more paperwork, meetings, overhead, documents, boredom, etc…

    One of my current projects has several hundred pages of specs, and only minor adjustments are made few times per year. Still our project is run in a very Scrum like fashion. We implemented the system according to the specs, and started “scrumming” after the first working version was delivered.

    I think Danske Bank uses “Scrum^2″ methodology for their online banking system ;)