Next in my discussion on how to do offshoring successfully is independence. You have to make sure the development team in the offshore location can work as independently as possible.

Like the earlier articles it is equally important to deal with the subject of independence in the planning phase of a project, but also each and every day of its lifetime.

Large enough backlog

It may seem obvious but a good start into independence is to make sure that there is enough work. Specifically, ensure there is enough work even when a few of the tasks require clarification or face issues that can't be resolved without the support from another office. Examples are an external system not being accessible due to firewall issues, a synchronization that failed, etc.

You don't want your developers to be idle as soon as a minor glitch is encountered. As we learned in the first part of this series waiting for a clarification can easily take the better part of a working day if you are working across time zones.

Naturally in the end of your sprint (if you do Scrum), your iteration or when you reach your next milestone all the tasks that are assigned have to be completed. The reality will be that you need to take into account the effort for clarifications and keep that in mind when you plan your sprints / iterations / milestones. So this is not a matter of being lax. It is a matter of being realistic.

Encourage your team to adopt an agile way of thinking. Encourage them to stay productive by switching to another task if another one is blocked.

Assign whole modules, split vertically

Aside from ensuring enough work you can increase the productivity by assigning independent modules. In order to do that you have to understand the difference between a horizontal and a vertical split and know the implications.

Each application probably contains backend code, business logic and database access code, certainly a GUI of some sort and maybe external interfaces.

A vertical split would be to assign the implementation of one whole feature of the application to one office - including the GUI, the business logic and everything else related to that feature - and another feature to another office.

A horizontal split would be to assign the GUI implementation to one office and the implementation of the backend to another office.

Note: Let's say you split horizontally. Any change in the business logic (done in office one) might break the GUI (done in office two). Now office two doesn't know if their GUI is breaking because of a change in the business logic that office one didn't inform about yet or because of a bug. Communication is required. Communication that takes time.

To complicate the matter further, office two can't fix the issue in the business logic even if it is clear as day that it is a bug because they are not responsible for the code! They might not even have sufficient permissions to that module in the revision control system!

It is important that each such module can be fully implemented and tested independently. So take the effort and divide your project vertically. You may think it is not possible but usually it is. Maybe it will take some effort but that effort will pay off soon.

Small support-work is possible but less efficient

Resist the temptation to do all the 'serious' work in the main office while assigning only service tasks or bugfixes to the offshore location.

This approach might lead to the unfortunate situation that the offshore office doesn't have a holistic view on your application or product. If the global picture is missing you risk a lot of harm by developers fixing a bug in module A but breaking modules B, C and D in the process because they didn't know those were related.

Remember: Your offshore team knows a lot less about what happened in the workshops with the client than you do. They were not there. They only know what you told them.

You might think that the developers in the main office are 'better' or otherwise more experienced than those offshore. My advice is to fly offshore for at least a month and spend a lot of time analyzing the situation from their side. Chances are that you discover impediments that you didn't see from the main office or that didn't seem that dramatic. Work on those first.

Removing these impediments will be easier and less expensive than to have your 'better' staff in the main office support the offshore staff continuously. You might even risk to disgruntle your main office staff if these impediments remain unattended.

Your view?

The aspects I discusses in this article certainly are only the top of the iceberg that threatens to sink your ship. Let me and my dear readers know what other obstacles and issues you encountered in terms of working independently and how you solved them. I'm happy for every single comment.

I give you some measures to keep the project on track and inform you about early warning signs.

If you missed the initial articles which handled the added complexities of time(zone) management, or the second one talking about the role of the coordinator, I recommend you click one of the the links and start there.

Preparation

You will want to make the project as well prepared, clear and free of uncertainties as possible. Yes, you always try to do that even when you're not offshoring. Here you have to try even harder.

The communication overhead in a co-located project is incredibly high to begin with. A week more spent on clarifications will save you a lot of trouble, time and hence, money.

Just remember: Your offshoring partner did not sit in those workshops with your customer. They are not on the phone with the customer. You know a lot more than your partner from offshore. It will be impossible to give them all the info you have but make sure you try real hard. Have a formal kickoff meeting (with physical presence!) and a workshop or two in the beginning.

Start face to face

It is a very good idea to bring your project manager, consultant and coordinator to the co-location for a couple of weeks during the start of a new project. A reasonable time frame is six weeks for a multi months project.

Make sure your management / consulting team arrives at the co-location a few days prior to kickoff to have enough time to settle down, get rid of jet lag and initial health issues due to change of climate, hygiene and food.

Plan time for the teams (main office and co-location) to get to know each other on a personal level. Go out at least once before kickoff. Dinner, bowling, cart racing... almost anything goes.

Setup checklist

Of course, there also should be enough time to set up the working environment prior to kickoff. Verify and re-verify everything. This includes but is not limited to

• the required documents are on location, in the correct language and up to date
• development environment is functional
• a revision control system such as Subversion is set up, accounts are configured, known and working
• a bug tracking system is set up, accounts are configured, known and working
• a deployment system is available and visible from all locations
• a mailing list is generally a good idea
• for long term projects setting up a wiki makes perfect sense
• hand out lists of phone numbers with every person on the project being on the list
• do the same for the instant messenger of your choice
• make sure the offshore team sits together to facilitate mouth-to-mouth communication
• a few webcams are great to keep the team(s) connected and personally involved

Focus

In an ideal world the project manager and consultant of a project are assigned to it to one hundred percent and do not have any obligations outside of that. If you can achieve that, perfect. In fact, you should try real hard to achieve that if you start a new project at a co-location.

A not-so-ideal world results in project manager and consultant being involved with more than one project. This is the common scenario. During the start phase of a new project in an offshore location this imposes a great risk. The return flight is booked and changing it brings a lot of complications, so time is incredibly precious. Make sure your manager / consultant pair has no other obligations during the time they spend offshore with their team.

Here's a simple trick to ensure no one intervenes while you as a manager or consultant are in the offshore office: Be on vacation. At least officially. Do whatever is required as per your company's process to be on leave. Assign a vacation replacement. Inform your (other) customers. Make it very clear to the colleagues of the other teams that you will not be available except for disaster recovery. Stick to it.

Structure your communication

Even with small teams it is quite easy to end up with a communicational mess. I mean a situation where everyone is using instant messaging, mail, the bug tracking system and the phone simultaneously. The results: Information becomes redundantly stored in multiple communication channels. Only a part of the team is informed. Efficiency goes down.

Spend some time in the beginning of the project to craft a communication diagram. Develop the diagram together with your team to make them involved in it. The diagram has to have two design objectives: First and formost it has to streamline and unify communication. Second, it makes communication transparent.

Maybe it makes sense to assign a 'communication lead' from within the offshore team. That'd be the person that centralizes all statuses, issues and clarifications and takes the initiative to resolve them with the main office. If you're doing Scrum, that'd be your offshore ScrumMaster. The benefits are several. One, there is one person offshore who has the global picture. Two, the other offshore members can continue working (on other tasks) while issues are resolved. Three, for the management / consulting / coordination team in the main office the communication becomes much more efficient and less redundant.

The second start - remote

So now your project head has spent a couple of weeks at the co-location and the project started well. The communication is clear and efficient. Things run generally very smooth when your manager / consultant pair take flight and leave for the main office.

Be prepared for an immediate slump of efficiency.

It's easy to wrongly assume that things will continue to run as smoothly as they did initially, when face-to-face communication was the norm. Reality is that they probably won't.

Be on the lookout for a general reduction in communication. There is no save assumption that this would be ok. Instead, communication should go up, both in frequency and duration. If it doesn't, find out why as soon as possible and remove the impediment.

Do not believe that a team member who does not communicate is productive. Maybe he is, but chances are that he is stuck.

Mind those time zones. Ensure that any clarifications, issues and problems in the offshore project are resolved before you involve yourself in local projects.

Summary

The list of topics to cover under 'preparation' is endless. Largely it involves communication. Be aware of the fact that you will not be able to fully know what is going on at the other location and have tools and measures in place to compensate for that.

I'm sure I didn't cover every aspect. If you're stuck at a certain point or you've encountered different issues than the ones I discuss above, use the comments to inform me and my readers! For a more personal discussion feel free to get in touch with me through the contact form.

Here I will discuss the role of the coordinator and what its responsibilities are (and are not). What to look for in the person filling the role but also how to enable this person to do a good job.

Pick a good coordinator

Fact is, you need a dedicated coordinator with great social skills, management capabilities and thorough technical expertise to make offshoring a success.

There will be clarifications. There will be complications and missing pieces of information that no one did foresee. For all of these you'll need a solution as soon as possible in order to keep productivity high. Mind those time zones!

This is why you really want to assign one of your best employees to the position of coordinator.

Enable your coordinator to be successful

First, he has to be willing to do the coordination, he must believe in the whole endeavour and be willing to travel to the co-location every other month. If he doesn't believe in it and in him making it happen, you risk creating a self fulfilling prophecy and the project might fail. Also, coordination done purely from a distance is futile, so the will to travel is mandatory.

Second, you have to reassign all of his previous responsibilities to other people. The initial months of setting up will require all his efforts. It needs time for the offshoring "engine" to run in - during that time you will want the full attention of your coordinator on the endeavor. When the projects start to run smoothly he'll probably be able to take back a few of his earlier duties, but to expect that he will be able to do so from the start is an illusion.

Third, he will need to have the power to make decisions on his own.

Avoid to make him the responsible puppet. Give him power.

Chose the lesser pain

Yes, assigning one of your top employees to the coordinator and freeing him of all other duties is expensive and potentially complicated. You'll probably need to hire new staff. Other seasoned members of your staff may have to take the burden of extra work for quite a while. Customers might get slightly irritated when you remove your coordinator from their project.

It will hurt. A bit. For a short period of time.

Assigning a lesser qualified employee to the offshoring endeavor would hurt you much more. So will giving an excellent employee not enough time or power to do his job well.

Projects would be delayed or - god forbid - fail because the coordinator doesn't see the gaps or is not empowered to close them. Customers might get really unhappy and may pick another contractor. Your employees may burn out. A general negative image of the offshoring partners and developers may form among your own staff.

That'd hurt much more, much longer.

Coordinator without active project involvement

I argue that the coordinator should not be part of any specific project team. His major job is to keep the projects running smoothly and to identify areas that need improvement. He needs to have the birds eye view on all projects. Experience tells me that you miss the global scope quite fast if you are actively involved.

Note that it is irrelevant whether the coordinator is responsible for one or for five projects. Active personal involvement will make him lose his global scope.

Responsibilities

He needs to watch the teams spirit. Does communication between the locations happen frequently and soon enough? Are people happy or hesitant to use the phone? Does each side of the team see the other side as an equal partner? Do people know each other personally - at least a bit -  across the locations? If communication is good the battle is almost won.

He needs to aim for clarity. Are all tasks and work items understood and without doubts? Does the offshore team know who to contact? Do they know what will happen next week and how the project status is in general?

He needs to ensure efficiency! If hardware or software are inadequate or the working environment as a whole is not suitable this constitutes a bottleneck that needs to be removed. Are people working smart? Do they know how to use the tools they have efficiently?

Offshoring is hard. There are many mistakes to make, some obvious (in hindsight), some not so. Do not expect an immediate success. If you have the strength to sit through the initial months, it can be a good solution to compete, grow and react flexibly to changing environments.

Being largely involved in offshoring and on-site coordination myself, I'll present you with some of the success factors that proved to be most critical in my own environment.

This is the first article in the series, make sure you come back in a couple of days for more on the topic!

Mind those time zones

Working across timezones becomes an issue really fast. In my case, I deal with a rather small time difference of 3.5 hours in summer and 4.5 in winter (daylight savings...). The good news is that we actually have the luxury of sharing office time in both locations. This improves the overall condition tremendously. But let's take a closer look:

Timezone difference between Germany and India

The above graphic visualizes the typical office hours. Red cells mean "no way, no one will be in the office", gray cells indicate "people are slowly coming in" and white cells assume general availability. Lunch time (typically starting at 1pm in India and 12am in Germany) is also marked gray.

So even with only 4.5 hours of time difference you have only around 4 hours of office time left where you can be sure the other part is also present. Sounds obvious at first but let's discuss what this means with a few scenarios.

Pitfalls and how to avoid them

If you're in Germany and you find a mail asking for clarification in your inbox, you'd better reply before you leave for lunch or else it might already be too late for India to react.

On the other hand, if one piece of information is missing for you in India, you'd better write that request before you leave in the evening - Germany has almost four hours left to analyze and reply. Let's play this through: If Germany doesn't respond to that mail before they leave in the evening India will spend at least 5 hours the next day without that information. That's a lot of potential and money wasted.

Any conference calls must be scheduled during German morning, otherwise your Indian staff will work late and that will affect efficiency in the end.

Those are just a few examples of daily activities that need more consciousness in terms of time management. You get the idea.

So what's the solution? Awareness of course. But that is easier said than done. One thing that will help is to adopt a practice from the military: Think and communicate in Zulu time. In essence Zulu time is Greenwich, UTC+0. No matter where you are in the world, if you communicate meetings in Zulu time, everyone will know what you mean and will know immediately if that's ok for them or not. It takes a few days to get used to the concept that your office hours are 3am - 12:30am UTC if you're in India, but after that it works like a charm.

By the way: You can set a second timezone in your Outlook calendar.

Other experiences and solutions?

What is your experience with working across time zones? Did you encounter other issues not covered in my post above? How did you solve them? I'd be happy to read your comment!

For detailed discussions or requests feel free to contact me personally.

Make sure you also read the second article in this series about the on-site coordinator and how to enable him.

In this article I will present my current tool set of choice for the iPhone.

Word processor and spreadsheets

Quickoffice (iTunes) is pretty much what is claims to be. You get a Word editor and a spreadsheet application. Both natively work with Microsoft Office formats (old and new) and that is all I need.

The user interface for both applications is easy to learn and while the lack of keyboard and mouse does slow you down when editing spreadsheets, the app makes good use of gestures and multiple-tap events.

What I found to be missing however is the possibility to set headlines and other formats. Note that they are displayed and preserved correctly. You simply can't add new ones. The usual text decorations like bold, italic and the like work smoothly though.

You can up and download documents through a WebDAV interface. The MobileMe iDisk online storage is also supported but that isn't for me - I value the privacy of my data.

Strangely there doesn't seem to be a straight forward way to copy a file. You have to open the original, make a subtle change and 'save as...'.

Overall Quickoffice let's me get my work done and does it in a rather effective manner, for an ok price.

Aside from the 'pure' office functionalities Quickoffice supports a number of other file formats including images and .pdf, for which it provides readers/viewers. While rounding things up nicely, these readers lack some of the oomph that the Files app provides, see below.

Mind mapping

I can't exist without mindmaps. To me they are the organizing and structuring tool of choice. On the computer I use Freemind, because it is open source and it's many keyboard shortcuts make creating and editing a mindmap really fast.

There are many mindmapping tools for the iPhone but I believe iThoughts (iTunes) is a clear winner here. It supports virtually all major mindmapping formats and makes clever use of drag and drop on the iPhone. Nodes can be individually styled and highlighted with icons - important for me for additional grouping and priorisation.

Once again, files can be up and downloaded through a WebDAV Interface or through an online storage service, in this case box.net.

Same as above, mobile storage doesn't work for me and I believe it shouldn't be an option for any business use. Your data simply isn't save.

Generic file storage

The Files application (iTunes) is a WebDAV accessible storage medium on your iPhone. Think of it as a WiFi stick.

You can set up a quota how much space on the device Files can take up and security is provided through an access password.

Note: It can savely be assumed that the content of the storage remains unencrypted, the password most likely serves only as access prevention.

What I like about Files is that it supports reader functionality for most common formats, including .pdf, office formats and an image viewer much like the Photo application from Apple.

Offline bookmarks

Instapaper.com provides you with a simple service: You can bookmark websites to read them later, categorize them, tag them, you name it.

What makes Instapaper stick out of their competition is the good integration. Granted, a browser bookmarklet is nothing special anymore, neither is an iPhone app. Make the iPhone app (iTunes) communicate with one of the most frequently used Twitter clients (Twitteriffic) and make that communication both ways and you have created a huge amount of added usability right there. This is what Instapaper did. Tweet your latest finds right from the Instapaper app. Push articles from the people you follow into your Instapaper list without changing the app.

This is what I do - each morning during breakfast I add all potentially interesting links from Twitter to Instapaper, update the archive in the Instapaper app and I'm ready to go, able to read those articles whenever I want and indepepdent of network availability.

Summary

With Quickoffice, iThoughts and Files, there are three applications that bring their own storage logic and their own WebDAV interface.

It would be great if Quickoffice and iThoughts could team up with the guys from OliveToast (creators of the Files app) to utilize their storage for easier maintenance.

A very similar cooperation is already in place between Amidio and Intua, both creators of top notch music creation and sequencing applications for the iPhone. You can record a sample in one app, i.e. Hexatone or Noise.io, then fire up Beatmaker and load that sample through a common storage to sequence it with other samples. Recently that was simplyfied even further: Now you can copy-paste samples between the apps using the iPhone copy-paste logic.

Doing this for the office apps would greatly increase productivity.

However in the case that you're just starting with Scrum I would argue that you might be better off without tools. All tools force you into some kind of process that works for somebody else, but might not be optimal for you.

So instead of jumping to a fancy tool that comes with all the bells and whistles instantly, I'd recommend starting as low-tech as possible, learn the basics and discover your individual needs. After that you are enabled to get the Scrum tool that does exactly what you need it to do.

How do you start low-tech? Use pen and paper.

Experience over tools

Scrum as an agile methodology has a very shallow complexity. It doesn't require many artefacts in the forms of documents, lists, reports or charts.

The artefacts defined in Scrum are the Product Backlog, Sprint Backlog and a Sprint Burndown Chart. Personally I find two more "artefacts" to be extremely useful: User Story Cards and one set of Planning Poker Cards for each team member.

No more than three documents plus two helpers for all your project management needs. Sounds like thin ice? Believe me, I know how you feel but hear me out.

I started off doing Scrum in a waterfall environment, using tools that where developed for waterfall projects. It gave me the advantage of familiarity with the tools (false security?) but at the price of bad usability and cumbersome overhead.

Only since my ScrumMaster Certification I see the benefit of using low-tech "tools" like pen and paper. It is faster, more fun, breeds involvement and identification, can be distributed without permission and data security problems and most important: You will get a much better understanding how Scrum actually works.

Granted, the "high-tech" tools mandatory for my company are still in use, but I already wrote an article how to utilize SDLC tools best for Scrum so let's keep that aside for a moment.

Doing Scrum "hands-on" with pen and paper is easier than you might think. There are no complex metrics or calculations to perform. You will see that your planning meetings get a totally different dynamic if you work with a stack of user story cards and pen & paper. People interact physically with each other rather than staring at the pale image of the projector.

The Product Backlog

My product backlog template is as simple as it gets. One column with the user story number, to make identification easy. A title and a complexity column is all that is filled out in the beginning, usually by the product owner.

In the planning sessions the team will use its planning poker cards to agree upon a complexity which we fill out together in the second column to the right.

Last not least I added a column for dependencies. This will contain the user story number(s) that need to be completed before the one at hand can be filled out.

The User Story Cards

The title of a feature in the product backlog serves only as a short summary of the feature itself. It will not explain the task, only give it a name.

User stories fill that gap. My User Story Card template is half of an A-4 size paper, print it on a duplex printer (so that page 2 of the template is printed on the back) and cut it in half.

The head of the front page of the user story contains the user story number and the priority, both also found in the product backlog. Another header entry, the estimation is left empty. Here we will the required time (not points!) for the task, in the sprint planning meeting.

Note that I estimate the features in the product backlog in story points through planning poker, but the tasks of a sprint in hours. One user story is usually comprised of several tasks. The "estimation" value on the user story card is the sum of hours for all tasks of this story.

The main part of the front of the user story card is pretty much standard, it has to be filled with the role of the user ("as a ..."), a feature description ("I would like to ...") and the purpose of the feature ("in order to...").

For example "As a logged in user I would like to be able to edit and store my delivery address in order to have it pre filled in the shopping basket."

In short, the front of the card will give a good overview of a feature. The back contains additional notes and the acceptance criteria as given in the planning meeting.

The Planning Poker Cards

Planning poker is easy to perform but I find it notoriously difficult to describe. I will leave it to the ever helpful Wikipedia to give a good run-down of the process of planning poker.

I can provide you with a template to cut out your own set of Planning Poker Cards. Bring a stack of uncut prints to your next meeting along with a bunch of scissors and cut them out together. Play your first couples of rounds on non-critical features or even features that do not exist in reality.

The Sprint Backlog

In the sprint planning meeting I bring the product backlog along, which has the complexity column already filled out. It contains the complexity in terms of story points, derived through planning poker.

During sprint planning the team picks features from the product backlog that have the highest priority to the product owner. The priority is usually based on business value so it makes perfect sense to finish the most valuable features first.

The user story that belongs to a product backlog feature is read aloud and a discussion starts. Questions are raised and clarified. This continues for a couple of minutes until the feature is commonly understood. Then, the team breaks the feature down in smaller tasks, which are written into the sprint backlog.

The sprint backlog template once again contains the user story number to easily identify and group the tasks. The sprint backlog also contains a column for the name of the task and a whole lot of columns for numbers.

In the sprint planning session we discuss the overall complexity of each task of a feature and estimate an amount of time (in hours). This value is being written into the "Est." column, marking the initial estimation.

Note that some teams prefer to estimate both product backlog features and sprint backlog tasks in story points (planning poker) while others prefer to estimate both in time. You'll have to find out what works best for you.

The other columns marked "owner" and "1" to "15" are not filled out yet. During the sprint the team members will pick tasks for them to implement, and write their name into the "owner" column as soon as they do so.

Every evening before leaving the office the team members do a re-assessment how much time on their current task is left and write that into the column marking the Nth day of the sprint.

Let me say that again: The columns "1" to "15" contain the amount of time that is left. It is irrelevant how much time someone spent on a task. The criticality of a delay derives from too much work remaining.

The Sprint Burndown Chart

Finally there is the sprint burndown chart which will display the amount of work remaining on an every day basis.

At the end of the sprint planning meeting the sum of time in the "Est." column of the sprint backlog is transferred to the "day 0" column in the sprint burndown chart.

Note that the vertical axis doesn't have numbers assigned to it. Those vary wildly depending on team size, velocity and sprint length. Fill it out yourself.

During the sprint I will take the sprint backlog every morning and update the sum of time at it's bottom. This number is X'ed on the corresponding "day N" column of the burndown chart and the joining X's connected. Done before each daily scrum this is a good information radiator telling everybody how well the progress is without even talking about it.

It is a good idea to draw a line of "ideal progress" onto the burndown chart as well. This is a straight line, starting at the sum of values of the "Est." column in the sprint backlog, going straight to zero at the column of the last sprint day. This way you can easily real progress with ideal progress.

Conclusion

So there you are, a complete set of templates for your pen & paper based Scrum management needs. For your convenience I've also prepared a .zip file of all .pdfs that will also contain a set of Office 2000 compatible .doc and .xls files of the same templates.

Give it a try.

You can always come back to technical solutions or add a column here and there if you think you'll need them. The KISS principle applies. Keep it simple. I haven't really found a need for more columns in my projects yet. But your mileage may vary.

I will compare PERT and COCOMO, both being traditional techniques with a long history and Planning Poker, probably the most prevalent agile estimation technique.

All techniques have their pros and cons and it will be up to you to determine which technique will work best in your environment.

My comparison is purely based on experience, which is broader for PERT and more narrow for COCOMO and to some extend Planning Poker. Your mileage may vary. This article does not intend to be the definite guide on estimation techniques.

That being said, let's start shall we?

PERT

The PERT estimation is the standard estimation technique at my company. It is time-based and probability-based. The basic formula is to estimate an optimistic time (Topt), realistic time (Treal) and pessimistic time (Tpess) for an activity and generate a mean value (Tm) based on the formula Tm = (Topt + 4 * Treal + Tpess) / 6.

The realistic time Treal is weighted four times higher than the optimum time and worst case time, the sum of all three is divided by six.

For example if a task might complete in two days if everything runs fine, in three days under normal conditions and in five days if we run into complications the PERT value would be (2 + 4*3 + 5) / 6 ~= 3.2 days.

If you estimate all tasks of a project with PERT you can generate the variance and get a buffer value out of it which can be pretty handy. Don't trust that buffer blindly though.

One of the pros for me is that PERT acknowledges the fact that humans are particularly bad in estimating a task down to a single number. The thought of optimistic, realistic and pessimistic cases alone works wonders in discussions. The formula usually does a decent job to come up with a mean value.

Also a pro for PERT is that it is reasonably fast. Estimating a 3 month project on a level of abstraction needed for an offer usually takes no longer than a couple of hours.

My biggest con against PERT is that it is easy to misuse it. What I see frequently is that a discussion starts whether or not a particular task has a risk. Often that leads to optimum and realistic estimation being the same, let's say 2-2-5 instead of 2-3-5 as shown above. Or in a similar manner, realistic and pessimistic estimation are the same: 2-3-3.

Instead of the above mentioned 3.2 days for 2-3-5 we get 2.5 days for 2-2-3 and 2.8 days for 2-3-3. In a nutshell that ruins your buffer. You do not want that.

Another more general issue I have is that PERT is time-based but I'll get to that in a bit.

COCOMO

For me COCOMO is the rocket science approach for estimations. It is complexity-based and rooted on calibration through historic data. The algorithm behind COCOMO will get fine tuned over time, while your "database" of historic data grows.

The key figure in COCOMO is the lines of code (LOC or SLOC), more frequently thousand lines of code (KSLOC). You need to know - or in the first project, estimate - how long it takes to produce 1000 lines of functional code. Analysis, design, coding, testing, ... included.

Then you need to do an estimation of how many lines of code will have to be written or changed for the new project.

A set of factors or "cost drivers" such as project complexity, required quality, team experience etc. is applied to the estimations and after putting all this into a formula you get the estimated amount of time.

By far my biggest issue with COCOMO is that it is slow and too complex. You can't get decent estimation quality with COCOMO in a short manner of time. Even intermediate COCOMO takes into account no less than fifteen cost drivers, all of which affect each and every task. The bottomline is that you need a tool for estimating.

Disclaimer: There is a variant of COCOMO that is faster than traditional COCOMO. Personally I don't find that to be very exact, though and hence not very useful.

The second con against COCOMO is that it is fragile. Change your team constellation from one team to another and your historic data is useless. The same applies more or less for all other cost drivers.

I like the idea that COCOMO gets calibrated with time through your historic estimations. But in the reality of changing teams, hardly comparable projects and time pressure that leads to historic data not being available in a clean form frankly I never saw that work. Granted, that is not a failure of COCOMO but rather the methodology not working for us.

What I generally like in COCOMO is that it is complexity-based rather than time-based.

Planning Poker

Planning poker is an agile estimation technique. As the name implies it is based on playing cards (my .pdf for download) . The estimations in planning poker are relative, complexity-based and consensus-oriented.

Each planning poker card will show a number: "0.5-1-2-3-5-8-13-20-40-100-?-infinity" are a common set but there are other variations. The card "?" indicates that the estimating person can't estimate the task and "infinity" translates into "really, really huge" and can be seen as a sign that the task should be broken down into several smaller tasks.

The estimation works as follows: Each team member has a set of cards on his own. A task is explained, usually by the product owner / customer. A discussion takes place to clarify doubts from the team. After the task is clear, each team member picks a card out of his stack secretly and in unison they show the cards to each other.

If the numbers on each team members' card are reasonably close together (i.e. 8-13-8-8-5-13) a rough mean value is "calculated" (probably 8 in this case) and the next task comes up for estimation.

In case the numbers vary wildly the team members with the lowest and highest numbers explain why they picked their number. This is to reveal misunderstandings and generate a broader understanding for all team members. After that a second estimation round is performed. The process repeats until all numbers are reasonably close.

By now you may ask what the numbers are indicating? They do not indicate time. The card "5" does not mean "five days" or "five hours". The cards indicate complexity. There is no unit for the numbers, they are commonly referred to as story points or points for short.

What points show is that a task with a complexity of 2 is twice as complex as a task with 1 point and roughly half as complex as a 5 point task.

When estimating with planning poker it is absolutely mandatory to understand that each tasks complexity is only relative to another task. So what you do is you pick a comparable task that has already been developed (from your last project or the last sprint in the current project) and assign a medium sized number to it, for example "eight". Now for the current bunch of tasks you ask your team to compare the new task to that one and pick a card from their stack based on its relative size.

What you get is a consensus-based estimation how big or small a current task is related to one that is well known and understood. Since a task with complexity "eight" is almost twice as big as complexity "five", and you know how much time "eight" took to plan, develop, document and test, you have a rough idea how long the new task with complexity "five" will take.

My biggest pro for Planning Poker is that it will enable your team to estimate their own work. Usually this will take a few iterations as they need to get to know their own pitfalls but the long term benefits clearly outweigh the initial pains. Once the team knows how to estimate, you will not find anyone outside the team who can estimate the teams own work.

Another big pro for Planning Poker is that it is by far the fastest approach and that it is fun. Calculating numbers for hours and hours is boring, planning poker is more of a focused discussion.

One negative aspect of Planning Poker is that it is somewhat fragile. If your team size changes often, getting good estimations out of Pllanning Poker might be hard. But in agile the team constellation should stay constant even more than in traditional methodologies.

Bottomline

That's it, the three estimation techniques I'm most familiar with.

If you work in a traditional environment, give PERT a try. Use COCOMO if you can afford the overhead and if you have comparable projects in a very stable environment.

In any case I urge you to try out Planning Poker. While the methodology itself is agile, I don't see why Planning Poker should not work for you, even if you're in a traditional waterfall of SDLC environment. It will give your team a much better understanding of the upcoming work and enable it to participate in a project at a much earlier stage than usual. Through that, the team will feel involved and motivation will go up.

I own a bike here in India, the Royal Enfield Bullet. The apartment I live in provides each tenant with a (car sized) parking lot. So my bike spends quite a bit of time next to an Innova van owned by a business man.

The sheer number of people in India makes labour really cheap. Not to have a maid for house keeping is rare. Even employing a maid, a cook and a driver does not raise many eyebrows when you're in the middle management.

While I have none of those yet, the gentleman owning the Innova does employ a driver. The driver also washes the car every other day. That guy is a nice fellow and although his English is really bad, we're greeting each other and have a three half-sentence long chat every now and then.

My experience I'd like to share started on the day where he started washing my bike.

I didn't ask for it and the bike was not in a state that implies he washed it out of pure mercy. He also didn't ask for money. I thanked him and that was it. I was happy to have a clean bike and he smiled even brighter after I thanked him. From that day on he washed the bike a couple of times.

I don't know if he is a marketing genius that just happened to be a driver or if he's just being friendly. No matter which, this week I suggested that we can come to a simple agreement: He washes my bike two times a week and I pay him. That'd save me time better spent elsewhere and helps him financially - as I said labour is cheap, a driver is far from rich.

Whatever his intentions were when he started this, he's making a bit of money out of it now.

Transfered to the online business I'm familiar with something similar. Every now and then we develop a cool feature internally and show a beta to our clients - RnD, idle time, crazy idea turned useful, there are many reasons how that starts. If the clients are interested we calculate a price partially covering our costs and sell it to them on a non-exclusive base. Usually that works out.

I can think of at least one big company which is doing something similar: Google

For them the motivation is different, they don't charge a fee when the product gets out of beta. For them it is marketing. People love Google. Sometimes I'm surprised there is no Google religion yet.

Of course the early release of betas also enables Google (and us) to test the demand for a certain feature and thus cut development costs to a minimum if there is none.

The early feedback aside I'm convinced the major benefit of these free gifts is marketing and the chance of generating future, unrelated business out of it.

The good part: The development of these betas is almost free of cost, even if no clients buy it. Quite often I see these features are developed In someone's spare time or as a distraction from work. So no real harm done. A happy developer working overtime even without you asking for it is as close to perfection as it gets.

So encourage your team to do RnD, to check upon latest trends and to do something cool, even if it is out of scope. Chances are that the topics he learns about during that RnD will be useful in a future project.

Even more important: Let RnD be lean! Don't muffle creativity with an "innovation budget approval" process or something even worse.

Software is an art form! Leave your artists some creative space. It will pay off.

As always, I'm curious. Did you encounter something similar? Share your thoughts in the comments!

What I mean by this is: A job is delegated to you and it is made clear that you are responsible for the success of that job. This can be the implementation of a feature, managing a new client, bringing a certain amount of business this year, correctness of your project estimation, whatever. The responsibility is made yours, but you can't make the decisions required to get the job done most effectively and most efficiently. You have to stick to what someone else thinks is best.

In this conflict, the course is already set. You're standing on the command bridge of a proverbial ship where all controls have been removed. Yet you are responsible for the save arrival of all passengers. Sounds familiar?
It is important to me to make clear that this is not an issue only affecting non-management employees. It affects everyone in a hierarchy.

I recall one particular incident which I'd like to share. I was the assigned consultant for a new client. The responsibility was to identify all tasks required for that project and come up with an estimation. I did and do that regularily. The catch? We already knew the maximum budget the client had, and also the required release date. In fact the offer had already been sent and signed based on both. Even worse, a quick glance through the requirements made it clear that it was unrealistic to expect everything in good quality, for that budget, at that date.

At that time we did estimations mostly for the purpose of creating a realistic offer, only rarely were these estimations used internally for quality control and such interests. In that regards, an estimation was not required anymore. Think about this. If the goal of the job (a realistic offer) is already obsolete (offer had been sent and signed), the job itself might be obsolete as well. Nonetheless I finished that estimation as I saw a chance to track the actual efforts and compare it to my estimation after the project was over.

The estimation caused a huge uproar in the management, who claimed it was too high. I had a long discussion to convince them that the efforts are realistic - in the end it took a second estimation done by a colleague who came to a similar figure. Nonetheless the client had been convinced that time and budget were fine and no one wanted to change that. So there I was, responsible for a project that I already was convinced would not meet time, budget or quality (pick one), yet unable to do something about it.

I believe everyone of us can recall a similar scenario?

Of course I am not free from comitting the same crime. I have a vision for a new feature and stake out the route I believe is best and 'convince' my team to stick to that. But during development they might learn that another approach might be better. Yet, I staked the route, so they will tend to try to follow it. My fault, not theirs.
Yet I frequently see that if decisions are left to the team, after a learning period they usually come up with pretty clever ideas. They prove that I can trust them. Sure, guidance and mentoring is required every now and then but that is good - I hope not to become obsolete any time soon.

This is a call to all managers and leaders out there to trust your people. Give them the responsibility, delegate to them, but don't forget to give them the power and freedom do act as they see fit at the same time.

By no means do I want to advocate anarchy. Rules and guidelines are there in all but the smallest of organizations. They are there for a reason. So yes, we have to stick to that rule. Unless they make no sense and you can prove it. What is wrong with that? I don't see the point of sticking to a regulation 'because it is there', knowing that another approach might be better, faster, cheaper.

Managers! Trust your team! Let them make their own decisions! Ask for their opinion and listen to it! Mentor them instead of keeping them on a short leash.

Team! Learn to say no! Do what is right, not what is easy! Be opinionated and share your thoughts and doubts! Make suggestions, especially when no one wants to hear them!

How about you? Did you experience similar conflicts? Let everyone know how they were resolved. I'd really like to know so leave your comments!

Go and read the thread for quite a few interesting points. In a nutshell though, the question was how Scrum can help in fixed price contracts. I think that's an interesting question since at first sight a fixed price environment - and hence a fixed time environment - is contradictory to the agility that Scrum offers in terms of rescheduling tasks that have not begun yet, replacing items with others etc.

The consensus in the Yahoo group seems to be that fixed price contracts generally are a bad idea, will fail and that Scrum will not help you with that other than in damage control.

Well, in part I agree to that. Fixed price environments are tricky. Maybe they come into place because the client does not trust the agency, maybe it is a new relationship. Maybe they come to be because the sales staff of the agency gives the wrong impression in the first talks and no one dares to tell the inconvenient truth to the client after that, before the contract is written.

Maybe it is just how it always has been and we've all grown used to the process and the suffering involved?

I agree that some clients are politically important, door openers, key players. Whatever you call them, you will want a contract with them. Not for the sake of that contract but because of the things you believe you can get after that first contract runs well. And yes, in that situation it might not be very important to make profit on the initial contract.

But let's muse a bit on that thought. What good is a disappointed door opener client?

What I often see happening in fixed price contracts is that the agency over promises (too many features for too little money/time). With that being the base line the developer team is forced to deliver more functionality per day than they can deliver in good quality. Due to time restrictions, development becomes sloppy. Bugs creep in, further delaying the progress. In the end the developers are exhausted, the project manager has a hard time convincing the client that 'everything is still going really well' and the client senses that something is off. In the end he is presented a system that is riddled with bugs and sub-standard usability, and with reduced or missing features.

What happens next is usually a free-of-charge bug fixing period. In the meanwhile new requirements come in, which again tend to be priced below what the actual effort is. To make the client happy, after the initial disappointment. This vicious cycle repeats.

So in the end, don't we have a project in debt and an unhappy client? Did the agency really impress that client? Will he play the door opener role that management had hoped for?

So what might be the solution to that? What role might Scrum play?

Well I think the solution is trust. If the client is convinced that you're not stealing from him he probable is willing to agree to a more flexible approach.

So deliver early, deliver often. The sooner the client sees what you are doing, the earlier he will trust you.

Make sure that the client understands the MoSCoW method and that his feature list has a lot of 'should' and 'could' items. Deliver the most important features - those with the highest business value for him - first.

That way, even if progress gets delayed, the most important features will be done, and in perfect quality.

Ensure that the client spends a significant amount of time checking the interim states on the staging environment. You will need his feedback early. As Pete Deemer explains it, bugs are like tigers: At first they're little cute babies but if left unattended they become man eaters hiding in a thick jungle, waiting for the kill. So better to take care of them early on, and don't let them enter the thick undergrowth of your project where they will hide and grow.

I believe to some extend this picture applies for features in general: Only the client knows what he really wants. So the sooner you show him a working part of what you think he wants, the faster he can correct you, while the gap is still small and easy to bridge.

Bottom line

Being honest with the client is not the easiest approach. He might be irritated when two people from the same company (Sales, Project Manager/ScrumMaster/...) tell him two different things.

Management in your own company may not approve this seemingly radical paradigm change. Make sure you introduce it gradually.

Not all clients may be willing to work in an agile way.

So there is no silver bullet. There is no single solution that works every single time.

But I'm convinced that with open communication (think: full disclosure) and early delivery, Scrum can do a lot in damage control. Fixed price contract or not.