Rough Sea Games » Management

Common project management mistakes: Estimating tasks (part 2)

Joe Cool — Tue, 09 Jun 2009 14:19:46 +0000

Hi there,

we were quite busy over the last weeks, so updates of our blog are currently reduced. We are only going to post once a week in the upcoming month, but this should improve the quality.

Today I will continue my project management series. In my first post I described the common mistakes which are often happening when estimating tasks:

- Mistake 1: Estimation is not done by the task owner
- Mistake 2: The task has no proper description
- Mistake 3: Estimation is done by averaging worst case with best case scenarios
- Mistake 4: The tasks are too big
- Mistake 5: The tasks have unclear dependencies
- Mistake 6: The owner puts some unknown buffer time into the estimation

Please check out the first part of this article to find viable solutions to those mistakes.

The mistakes I wrote about are not really specific to a single department; most of them are quite common problems. Unfortunately, there is one department where task estimation can be very difficult. It’s obviously the programming department that I have in mind. Estimating tasks with programmers is quite an awkward business.

You need lots of knowledge and experience to get numbers that are even close to realistic. As a project manager you may wonder why this is so complicated and why programmers’ estimates are so often unreliable. There are several reasons:

Mistake 7:

Taking the estimates of a rookie programmer as the final estimate

Solution:
Programmer performance varies by a factor of 10, which means a very good programmer can solve a given problem ten times faster than a bad one/rookie. No problem, you think: just let the slowest programmer estimate the task. That will unfortunately not solve your problem.

Young programmers tend to overrate their skills and dramatically underestimate tasks. So let the lead programmers, who are able to rate programmer performance as well as task difficulty, review the rookie’s estimate. The more experienced programmers check the estimate, the better it gets.

Mistake 8:

The buffer time for the programming tasks is the same as for any other task in the project plan

Solution:
This is nothing new and a lot of people have written about this problem, but unfortunately it’s still not accepted as an unalterable fact. Maybe it’s because of the certainty that there is no simple formula to determine the right buffer time.

It really completely depends on your programming team. You might have a 100% or even 200% buffer time and it’s not enough. Track real life data and your estimates, compare them, learn from them . Every programmer has his own speed and estimation techniques. Find out which ones are reliable and which are not and adjust your buffers accordingly.

Mistake 9:

Assuming that a programmer programs 8 hours a day

Solution:
If a programmer tells you he needs one day for the task, does that mean one real life day? It depends, again, on the programmer, but you should not ask how many days; instead you should ask “how many hours do you need?”. This is very important because a rookie programmer might not have realized yet that his effective programming time is only 4 to 5 hours a day.

Mistake 10:

Changing numbers in the project plan in order to change reality

Solution:
Project managers very often reduce the (massive) programming buffer times after estimation is complete, because it tightens the project schedule and seems to save lots of money.

Well you know the answer already: this does NOT change reality and you will not save a single cent. Instead it will cost you a lot of money! Never reduce programming buffer times unless you are absolutely sure it can be done faster. To put programmers into a crunch because you reduced their necessary buffer times will damage your reputation, and the team will not trust you anymore and will sneak their own buffer times in their upcoming estimations.

Next time I will talk about crunch, a very common technique to waste money and lose good employees.

That’s it for today, thanks for your time .

Cheers,
Matthias

Share/Bookmark

Common project management mistakes: Estimating tasks (part1)

Matthias — Sun, 11 Jan 2009 22:53:59 +0000

Over the last several years I have managed and participated in different projects of different sizes. I made a lot of mistakes, some of them more than once. This time I want to talk about mistakes in estimating the time to complete tasks.

Estimating tasks is really tough work, and it’s done wrong most of the time. Estimations are never precise. I think that most project managers are aware of this problem, but may not know how to get better information out of their team.

Mistake 1:

The task is estimated by somebody who is not working on it — maybe by the lead, which is even worse.

Solution:
Tasks should be estimated by the owner of the task with the help of his colleagues or his lead. Programmers especially have different working speeds, which can be ranked from 1-10. This means a very good programmer can be 10 times faster than a very bad one.

Mistake 2:

The task has no proper description and/or is unclear to its owner.

Solution:
How do you know if the task has a proper description? Well, it’s a mixture of common sense and experience. If you, as a project manager, do not understand the task (e.g. it’s too technical), it might be already a very good hint. Tasks should be described non-technically, understandably and in only a few sentences. If you prefer working with user stories I would recommend to you this book from Mike Cohen.

Mistake 3:

The task is estimated with worst case and best case scenarios and the average is taken for the project plan.

Solution:
This doesn’t make sense because the owner has to make 2 estimations. In the worst case scenario there is probably a hidden buffer time, which is not obvious to the reader when checking the project plan. Ask only for one estimation from the owner or the team when estimating the tasks. It’s much clearer to them and they know you will add the buffer.

Mistake 4:

The task is too big and cannot properly estimated by its owner (tasks with 8- 16 hours are a maximum)

Solution:
As soon as a task is bigger than 2 days, it is time to break it down, because nobody can foresee the problems that are going to arise when approaching such a big issue. If you are not able to break down the task (e.g. because of a missing design), but you need the information desperately, you should estimate it and add at least a 100% buffer. Don’t forget to mark that task with “??”, to be sure to break it down later and re-estimate it.

Mistake 5:

The task has dependencies on other tasks that are not clear to its owner.

Solution:
This is not an easy problem. Try to make tasks as independent as possible when defining them. If you work with user stories, add the dependencies of the task to your war-room board and check if your priorities match the dependencies. It is really hard work for the designer and project manager to get this right. Communicate as much as possible with the team to avoid dependency hell early: it can vaporize your whole project plan if you do not care about it.

Mistake 6:

The owner puts some unknown buffer time into his estimation

Solution:
Again you need your soft skills and experience here to identify this problem. Some people just add buffer times to be sure they can handle the task. Be open with them, tell them that you will add enough buffer time, holiday and sickness absence. They will only tell you the right time if they trust you. Collect all the estimation data of each owner to get an idea of how well they estimate over the whole project.

I have some more mistakes on my list, but It is late already. So stay tuned for more in the upcoming days. Cheers for reading and I would love to hear your experiences…

Share/Bookmark

Use Mumble as a virtual conference room

Ole — Wed, 03 Dec 2008 16:23:04 +0000

Hello folks,

I am sure you know that communication is one key for successful development or project work. Companies usually have a conference room, or you meet somebody in the hall or in the elevator that you need to talk to. But nowadays people work from home in different cities, countries or even continents. Therefore you need a virtual place to meet.

That’s why I am going to write a little about Murmur / Mumble for those who haven’t heard about it. Mumble is a voice over IP service, like Battlecom, Teamspeak or Ventrillo. The advantages of Mumble are an excellent quality of speech, database support, server & client support for all major operating systems, text chat, and encrypted traffic — all for free!

First of all, we should differentiate between the server (Murmur) and the client (Mumble). Murmur defines and handles all Mumble requests: a typical client / server system.
But enough of this chitchat. We have to set up a Murmur!

Installation of Murmur:

Therefore we should start with installing Murmur. Installing Murmur on Windows shouldn’t be a problem, but what about Linux? All common distributions offer a binary packet of Murmur that you can install via your package management tool like yast, yum install “packetname” , apt-get install “packetname”, etc.

I am going to describe another way and will use the
“Static Linux Server stable packet” which you can download here.

Download murmur-static_x86-X.XX.tar.bz2.

Now untar the compressed file.

tar xfvz murmur-static_x86-X.XX.tar.bz2

Go to the directory which has been untared or move it for example to /home/murmur. Of course you can also run Murmur in the current directory.

Now it is time to decide whether to use SQLite or a “real” database like MySQL. SQlite has the advantage of running with Murmur right out of the box. The disadvantage is command-line-based user management, like adding new users or administrators. With MySQL you could use phpMyadmin (if installed) to do the management, so future administrators wouldn’t need shell access to add new users.

So if you want to use SQLite, ignore the MySQL part of the murmur.ini

Create a database or use an existing database of MySQL!

Edit the murmur.ini with MySQL support:


database=putyourdatabasenameinhere

dbDriver=QMYSQL
dbUsername=database username
dbPassword=Ilove-securePasswords
dbHost=localhost #localhost or the ip of the remote database
dbPort=3306 #usually the default port of mysql is 3306
dbPrefix=murmur_ #prefix name of your tables within the database

### SQlite and MySQL has to edit the lines below ###

host= the ip or domain # if you want to bind the murmur server to a default address

port=64738 #port you use for your murmur server

serverpassword=NicePassword # password for non-registered users. Keep it empty for no password login

Save the murmur.ini and exit it.

Now set up a superuser with the following command:

./murmur.x86 -ini murmur.ini -supw

Under Windows, of course, use cmd and type murmur.exe instead of murmur.x86

Now the superuser is saved in the database.

That’s it!

Murmur is running. Now you can login as “superuser” with your Mumble client and configure the rooms with a helpful GUI. Click on “channel” and then “add”. Now you can add a channel/room. This shouldn’t be a problem.

Enjoy your virtual conference room!

Documentation is available at mumble.sourceforge.net

Share/Bookmark

Scrum and XP for distributed teams (part two)

Matthias — Mon, 20 Oct 2008 08:47:21 +0000

Please check my last blog entry for the background to this post.

This time I will focus a little bit more on the XP side and explain what exactly we practise here.

Step 5 – regular pair programming sessions

Unfortunately, we are not able to pair program very often. We currently try to meet up once a week and have a 3 – 4 hour pair programming session. At this session we go through as much code as possible and talk about the architecture and the current design flaws. We try to get hold of the worst things we did while coding on our own, and start refactoring on the spot to learn a little bit more of each other’s code.

Sometimes pair programming is not possible because people live too far away, so we are looking into remote pair programming. We have not established it yet, but have collected lots of information. Please checkout Doug Alcorn’s Blog or Andrzej Krzywda’s Blog for some field reports. We will probably try VNC combined with Skype, because Flash Develop (our current IDE) does not have any collaboration support yet.

Step 6 – collective code ownership is even more important

CCO means that everybody can make changes and fix bugs anywhere in the code. There is not a single line of code in the project that is under the control of only one person. A good description of code ownership can be found at Martin Fowler’s Blog. As mentioned, we know each other very well already. If this weren’t the case, CCO would be much more of a hassle. A lot of trust and a lot of communication is necessary and coding divas are not allowed. Fortunately there is no diva in our team yet.

CCO is key for the success of a distributed team, because it helps to spread the knowledge of the code, systems and architecture of the project among team members (as pair programming does). Programmers will perform much better when they know how to use a specific system and how to adapt it to their needs. Not everybody on the web thinks that CCO is a the best idea ever; please check Ralf Sudelbücher’s Blog for a different perspective.

Step 7 – consistent and very regular refactoring

This, you might think, is not something specific to distributed teams — but I’m here to tell you you’re wrong. Sitting at home on your own, without a team mate next to you who reminds you to fix that broken window now (kudos to the pragmatic programmers), makes refactoring much less likely. The code quality can decrease quite fast for a distributed team if the programmers do not really care about it. What to do?

It’s actually quite easy. At each pair programming session, we identify broken designs and foul code and write our own refactoring stories. We give those stories the highest priority in the backlog. It’s very important to keep these stories as small as possible, because refactoring can sometimes get out of hand and this should be avoided. We only put the most relevant refactoring tasks into stories, because otherwise the backlog gets too confusing.

Step 8 – keep up the motivation

This is by far the most relevant and hardest part for a team which does distributed work, especially when there is no investor yet. The 7 steps already described help a lot to keep up the motivation when done right, but that’s not everything which can be done.

Try to establish a culture of praise and respect in your team. As soon as people start blaming each other, motivation will ebb and the team will break apart. If possible, the whole team should meet on a regular basis, as this helps a lot to improve communication and trust.

It’s also very important to have progress in all areas, not only the development part. Somebody has to care about investor relations, marketing issues, team building, business development etc. The team needs to believe that the product will be a success and that it is worth selling to the customers.

That’s it for today. I hope I could shed some light on our Scrum and XP processes and if you have some improvements or suggestions for us, I would be very happy to hear them.

Share/Bookmark

Scrum and XP for distributed teams (part one)

Matthias — Tue, 30 Sep 2008 08:56:47 +0000

As promised, this blog will include some thoughts about development processes and their impact on teams and projects. Today I will write about scrum and extreme programming (XP) for distributed teams, because at the moment we are one of those teams.

Scrum is a well known and currently very popular agile project management process. XP is a technical process, for programmers, and is also an agile methodology. The basics of Scrum are summarized in this great video from Kent Schwaber. If you looking for a good overview on XP check the Codebetter.com blog. More info on Scrum and XP can be found at the Agile Alliance Website and Mike Cohen’s blog.
I know both processes quite well, read all the available books, and have had the great opportunity to build up a team using these agile approaches at full scale. The team included some offsite workers, but that wasn’t too hard to organize.

To implement Scrum and/or XP in a team which does not share an office sounds almost impossible. Everything in agile methodologies relies on communication and transparency. A distributed team talking over e-mail/ICQ/wiki normally has difficulty communicating, and most team members have almost no idea what their colleagues are currently working on.

I will tell you what our team has done to improve communication, and why it is currently working like a charm. I have to admit that all team members know each other and are quite experienced. All of them have used Scrum and XP methodologies before. So the techniques described might not work for new teams which have never worked in an Agile way.

Step 1 – a wiki substitutes for the daily Scrum

We established a wiki as our major communication platform. WOW! That’s magic, isn’t it?
Well, the magic is not in the wiki itself, it’s in the motivation of its participants. If the team doesn’t update the wiki several times a day, it becomes absolutely useless.

Every day, I post the latest technical and business news, and all team members, including me, write an update on their current tasks. We still write e-mails and chat over ICQ, but most important communication happens in the wiki. It contains our business plan, the product backlogs, the complete (and current!) game design, helpful FAQs, various artwork and brainstorming thoughts. We even track our work hours and expenses in the wiki. We are still trying to improve our communication processes, but for now it’s working out quite well.

Step 2 – removed sprints, and introduced stories as mini sprints

We are currently working part time on our project, because we are still looking for an investor. People work in their free time on weekends, vacation days and so on. At first we tried to fix sprint timelines to certain dates, but that didn’t work at all. Working in your free time with (arbitrary) deadline pressure is horrific and far too much stress for everybody, so we skipped it.

Instead, Rafael put together a backlog in which the core game mechanics are written down as stories with acceptance tests. Stories get estimated by the programmers — not in a planning game, unfortunately, but the estimations do work out, because the team is quite experienced. It is very important that the stories do not exceed 2.5 points (most of our stories have 0.5 to 1.5 points). One point is a perfect day, so you need 2.5 perfect days to complete a 2.5 point story. This might take up to 2 or 3 weeks, depending on the time available. So the size of the story is important because of motivation issues: completing work in a short time gives you a very good feeling.

Step 3 – sprint demos are done for each story

We have always a working build and our designer is able to update the svn repository whenever he wants to. After updating he just has to start FlashDevelop, press F5 and can play the game. As soon as somebody moves the story to the “completed” section, Rafael checks the story directly in the current build and adds a comment if something has to change. If the change request is too big, Rafael writes another story and adds it to the product backlog. This works absolutely great so far; thanks go to Rafael for doing a fantastic job here!

Step 4 – established test driven development from the start

Fortunately there are some open source frameworks for Actionscript 3 which support test driven development. We are currently using one of them, which Manuel has improved a lot in the first weeks of the project. Maybe Manuel can explain what he exactly did in some of his future blog posts.

We used TDD from the very first moment, and it proved to be a good decision, because it helps us to have very stable builds. Having a stable version of the game is a must for distributed teams, because it will highly affect the motivation and performance of the team.

To be continued…

So I guess that’s it for today. There is a lot more to say about this topic, so I will write part two in the upcoming week. I hope you enjoyed this post and are able get some valuable info out of it.

Cheers,
Matthias

Share/Bookmark