Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Category: project management

  • Evidence Based Scheduling – One More Way to Improve Your Estimates

    Somehow my recent discussions are mostly about estimating. Last discussion on PM Clinic happens to be on the very same subject. It reminded me about great technique which can improve your software estimates. It is called Evidence Based Scheduling and I’ve learned this from Joel Spolsky’s article.

    The basic concept is pretty simple. Jack the Developer gets the task. Actually a bunch of them. He delivers his estimates basing on his guts. Estimates are most likely crappy but at the moment it doesn’t matter much. As Jack does his work he tracks how much time he really spends on the task. It may happen it takes two days instead of planned 4-hour effort. Velocity for this task is 0,25 and it goes to the history of Jack. When Jack’s history is long enough you can use it to judge how crappy his estimates are.

    Evidence Based Scheduling uses Monte Carlo simulation which takes some effort to calculate results. However Joel brings some good news here:

    “Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected. (…) This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}”

    After completing a dozen of tasks you can get pretty much insight which number you should use to multiply Jack’s estimates to get something close to reality. Of course full-blown simulation will probably lead to better results but you get the idea.

    There’s one more gem in Joel’s posting which is worth stressing:

    “Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code.”

    I know it brings quite a lot of effort for Jack the Developer, since sometimes he fixes bugs really fast and accounting time spent on each bug fix to proper original task adds enough hassle to be reluctant to do so. However the ends are worth means this time.

    I strongly recommend you reading whole article as it delivers all the details about Evidence Based Scheduling.

  • What’s the Use of Wild Guesses Instead of Proper Estimation?

    OK, this one is controversial. Software estimating. How to do it good, or good enough? First of all, when talking about the subject we all can learn a lot from Glen Alleman who bring quite an uncommon perspective to the area as he’s based in industries which tolerate missed deadlines with much less patience than the average.

    Now, what’s the point? If you asked me how software estimating should be done I’d direct you to Steve McConnell book on the subject. Believe me or not, he didn’t write anything good (if anything at all) about role of wild guessing in software estimation. Which doesn’t make me avoiding wild guesses at all times.

    Actually sometimes I make good use of them.

    Now, go flame me.

    What’s the use of wild guesses instead of proper estimation? Wild guesses don’t have to be so wild if you ask a right person. If I ask my development manager how long something would take and it’s a piece of software he’s fairly familiar with in vast majority of cases he’ll come with some guess. It should be reasonable enough to judge whether it’d take 9 months to do the job or rather just a few weeks.

    I don’t consider that as a full-blown estimate. It’s hard to use it as a base to create a schedule but still it’s a valuable feedback to judge whether and when your team is capable to overtake the project or decide if the whole thing is worth further presales effort. If you need to develop a bunch of tools which your competitors already have in their product portfolio chances are good you won’t match their schedules and/or prices. If you add that your team is backed up for the next half of the year it’s probably not worth investing effort to do more than just getting first coarse-grained approximation.

    Yes, every wild guess should be considered very carefully since after all it’s, well, just a wild guess not an estimate done according to rules. However doing proper estimation is quite an effort and sometimes you need something rough but quick instead of exact but demanding.

    And remember: don’t ever, ever allow your wild guesses to be sent to sales department.

  • A Failure Is an Option

    One of my ex-CEOs told me once a story about situation he’d have to face when he’d been a newbie manager. Shortening the story (it’s dull anyway, you can just skip it) a bit there was serious hardware malfunction in a company. There were no spare parts on service stock and they were to deliver their services next day, which was impossible to do without working hardware. The manager felt he had to do something to get machines working again. Unfortunately there was virtually no chance for him to succeed. Company failed to meet their deadlines and he felt as it was partially his fault, which wasn’t true.

    The moral of the story is:

    A failure is an option. Face it.

    By the way I’ve heard the story just after I finally rescued a project after 80-hour over-weekend battle with short brakes to get some sleep. Yes, it sounded totally irrelevant, but what would you expect from CEOs in that matter anyway?

    The moral however is very wise. A failure is an option. Sometimes it doesn’t matter how hard you try there are objective obstacles you can’t deal with. It can happen even if you’re the greatest Project Management Superhero in the galaxy and the biggest projects eat from your hand.

    If you ask me what to do, well, you won’t be surprised with the answer – prepare yourself. Sure, you can sit and cry your eyes out but you won’t get The Most Creative PM Technique Prize for that.

    First thing is to acknowledge you can fail. To be honest most of managers don’t get through this one. You know, you need to tell your ego you’re not as perfect as you think. That’s a tough task. Especially if your ego is so big it goes 5 meters ahead of you.

    Second, to have clean conscience, make sure you did everything you could to avoid failure before giving up. After all you’d prefer to be fairly sure you couldn’t make it, right?

    Third, prepare rescue plan. When you’re finished with hitting the wall hard with your head, have a plan how to call for an ambulance. It was said already that crying over spilled milk or crushed head isn’t the best idea in the world.

    I always smile whenever the reaction for question about potential problem is “we’ll manage, we’re superheroes, don’t ask” kind of approach. And believe me I see that a lot recently. I should have several great stories to tell soon.

  • Post Mortem Basics

    What is it?

    To make long story short post mortem is a little discussion after a project or important part of project. The team discusses what was done well and what was screwed. Before discussion one person gets feedback from all team members to bring a food for thought. Outcomes are used in future projects.

    What’s in it for me?

    Why to do post mortems? You usually feel what went wrong and what went well. But do all team members feel the same? Does a developer care if communication with a client went perfectly? Does a project manager understand all architecture flaws developers had to face? Does quality assurance team was aware about complex hardware installation part?

    Post mortems bring two main outcomes.

    1. Knowledge sharing. Everyone adds their two cents. All perspectives are included. Even the least important team member can bring a refreshing insight about project.

    2. Written summary. The process of preparing post mortems forces a person to prepare a piece of document before discussion. You just raise your chances to have a written summary after all which won’t fade in a week.

    How to do it?

    The scenario is simple:

    1. A person who knows a project well, ask all team members to answer three questions:
    • What went well and should be repeated in future projects?
    • What was on a good path and should be improved in future projects?
    • What went wrong and should be avoided in future projects?

    2. Then the person needs a lot of squeezing to get answers from most people from a project team, as many people won’t just answer a polite request.

    3. All answers are assembled into one summary. That’s part can be tricky as it sometimes happen the same thing will be put in different categories by different people.

    4. The whole thing is discussed and adjusted during team meeting, when everyone can add anything what comes to her mind.

    5. Post mortem can be, and should be, used to improve future projects.

    The questions can be adjusted if you feel like it, although I find the more general they are the more interesting things people will bring in answers. You don’t force people to change their perspectives, you just let them exploit their area of competence.

    When to do it?

    Definitely when a project is finished. But when you run a project which lasts three quarters you won’t remember all the issues you had to resolve during first phases after all. Then it’s quite a good idea to run post mortems after each important milestone.

    When you shouldn’t bother?

    If you don’t plan to use post mortem outcomes to improve future projects, don’t waste your time. Looking back is worthwhile only when it is a tool to improve future.