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.

Hope you find them as useful as I do.

If you're irritated about what pen & paper Scrum is refer to the original article.

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.

What is ownCloud?

I'll let Frank answer that himself:

You can use it to store your files in your personal cloud storage and access it from all your devices. It will also support versioning, backuping, sharing, syncing and other server based functionalities which are useful additions to KDE applications.

ownCloud is the central exchange point for my data and a companion for different KDE powered devices using the AGPL license.

So there you go. Your own online storage with connectivity to virtually all your gadgets. The benefits are obvious: You don't give your data away as it will still be on your own hardware. That alone is a big improvement over most other online storage systems. I hope my favorite mobile office applications, namely the Files, QuickOffice and iThoughts applications for the iPhone will support ownCloud once it has reached a certain stage.

Help a good idea to grow!

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.

Please note that the bits and pieces of information come from various sources and things may or may not be exactly as we think they are.

In order to understand what HipHop for PHP does it is important to understand how PHP itself gets executed. In this article I will give a rough overview of the PHP execution process and make a few educated guesses in what aspect HipHop for PHP differs from there.

Based on the little information available online I'll discuss how HipHop for PHP is suitable for large businesses and what might turn out to be obstacles that are yet to remove.

The PHP execution process

PHP code can not be executed directly, a property it shares with all other scripting languages such as Python, Ruby and JavaScript. What makes PHP executable is the Zend Engine, and it does so in a two stage process.

1. The scripts are parsed and analyzed, checked for syntactical and semantical errors and if all goes well the application is transformed into byte code.
2. Since the byte code is still not executable on a CPU, it is interpreted further into machine code (that is CPU dependent) and then executed.

For most PHP applications the first parsing stage takes most of the total time. The second execution stage is comparatively fast. So in order to speed up a PHP application, most code optimizers hook into the Zend Engine after the first stage has been completed and save the generated byte code into a cache. In a consecutive call to the webserver the cache will be fed back into the Zend Engine, thus skipping the entire first stage of the execution process.

There are quite a few products on the market that behave in such a way. Zend itself offers the Zend Optimizer (now part of Zend Guard), there is eaccelerator and APC, which comes as a PECL package.

The execution process with HipHop for PHP

What sets HipHop for PHP apart from these three (and no doubt other) accelerators is that it does not act as a cache. Instead, HipHop for PHP will transform your PHP application into C++ code and compile that directly into a binary which is executable.

In that sense, HipHop for PHP is probably very similar to Roadsend PHP which also generates executable code from PHP, albeit not by transforming it into C++ first.

In essence, HipHop for PHP will get rid not only of the first stage of the usual execution stage, but also of a big part of the second stage, namely the interpretation of byte code into machine code. Generally I believe it is safe to assume that HipHop for PHP has the potential to run an application much faster than any of the previously mentioned accelerators, simply because there is less for to be done at runtime. Time will tell.

For detailed information on the internals of HipHop for PHP make sure you watch the Facebook Technology Tasting video on ustream.

Possible limitations

The requirements
The requirements to run HipHop for PHP are available online. Nothing out of the ordinary at first sight. The page claims that HipHop for PHP is tested on CentOS and Fedora. Both are venerable distributions, no doubt. But both also come without vendor support which may or may not be a problem for your organization.

Granted, companies who's codebase can actually benefit from HipHop for PHP will no doubt have a team of excellent system administrators which maintain Linux in their sleep. But those companies might also be in the situation that their customers demand a Linux distribution with commercial support, such as SLES, RedHat etc.

So this is more an organizational issue rather than a technical. That being said it is not clear yet whether or not packages will be released by other Linux distribution vendors once HipHop for PHP is out. If at all, it probably won't happen soon.

Coming back to the requirements for HipHop for PHP, it requires customized packages of libcurl and libevent, which again may or may not be an issue for your environment. Here I see the same organizational issue, but also a possible technical issue - you might be in the situation that you need the original libcurl or libevent for some other software on the server. Only a practical test will tell.

Unsupported language constructs
As with most PHP caches and compilers, a few PHP language constructs are not supported. Most commonly known is the eval() construct which is simply not available in C++. Personally I believe that eval() is a bad thing to begin with and you can get around it in almost every cases. Sadly many PHP frameworks such as TYPO3, many PEAR packages, Drupal and Joomla make use of eval().

If you're intending to run one of these through HipHop for PHP you might need to wait for an update from the community, patch it yourself, or remove the code from the system if you don't need it. In any case this is a time consuming task.

Aside from eval() a few more language constructs may not be supported or may not benefit from the compilation in terms of performance, such as call_user_func_array() and other 'dynamic' constructs like dynamic variables, dynamic includes or built-in functions like function_exists(), class_exists(), get_declared_classes() etc.

HipHop for PHP is no different from other caches and compilers in these regards, so please don't make that affect your choice. Just be aware that things might not be as easy as you'd like them to be.

No Apache?
This is speculative at this point but the Running HipHop page on GitHub seems to indicate that HipHop for PHP will not make use of the Apache webserver but instead come with its own webserver. My assumption is that this means we'll have to handle HipHop for PHP through Apache, much in the same way that we frequently do with Tomcat. This is not necessarily an issue.

The potential of HipHop for PHP

Despite the limitations I mentioned above, I believe HipHop for PHP has the potential to take PHP much further into the enterprise environment than many of the existing solutions. If it can deliver what it promises it is definitely something we will take a very close look at to give our eCommerce framework a serious performance boost.

Very high on my wishlist is to run the transformation process from PHP to C++ but skip the compilation. If that's possible I see the chance to make debugging compile errors much easier.

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.

When you leave your comment on this blog you will be asked to type in two words which are displayed as distorted graphic. Most bulletin boards and free mail providers ask you to do the same before they allow you to create an account.

CAPTCHA 101

The reason behind is the same most of the time: Preventing SPAM. Spammers use forums, blog comments and contact forms to post their ads. They use bots (quite similar to the bots that update the search index on Google, Yahoo and all other search websites) to automate that process.

So the idea of CAPTCHAs is to present a task to a website visitor that is difficult to solve for a machine, but easy to solve for a human. The graphical CAPTCHA is the most commonly used one.

There are other CAPTCHA variants such as audio-based ones or image recognition based CAPTCHAs. I've even seen a simple math question as CAPTCHA.

The arms race

In December 2009 Jonathan Wilkins announced that Googles' most prevalent CAPTCHA method, reCAPTCHA has been broken. It is now possible to identify the words presented by reCAPTCHA with an accuracy of around 20%. For spammers that is good enough. WIth a 20% sucess rate, every fifth attempt will result in a successfully placed ad. Mr. Wilkins argues that even a success rate of 1% is good enough since the resources used by spammers often are not their own, thus their utilization is free (think bot nets).

This is bad news for everyone. I really hope Google updates its reCAPCTHA algorithm to a variant that is harder to solve by machines. For the record, I also use reCAPTCHA here in this blog.

Update: As of December 31st 2009 reCAPTCHA seems to be updated. Google responded quite quickly. So far I can already say that the number of spam posts I get in this blog has reduced drastically, albeit not come to a stop. Anyways, thanks for a quick response Google!

This situation is critical because spammers do not need to be particularly good at breaking CAPTCHAs. If one out of five CAPTCHAs can be broken and spammers still make a living out of this the CAPTCHA itself is useless in the sense that SPAM will enter your system.

Jonathan Wilkins has a .pdf paper where he gives guidelines for the creation of strong CAPTCHAs. It is a really interesting read even if you're not involved with CAPTCHA development  directly.

Which is the best solution?

Well I guess your mileage may vary.

For now I will stick to reCAPTCHA [official homepage] although it is broken and I need to remove a few unapproved comments every day. I like the idea behind the project so I'm willing to accept the minor annoyance that it currently imposes.

Text-recognition CAPTCHAs such as reCAPTCHA require strong OCR solutions and to my personal surprise, that is still a field what needs a lot of improvements. So even if reCAPTCHA becomes to cumbersome for me, I'll stick to another visual CAPTCHA method.

Audio CAPTCHAs are not recommended by Jonathan Wilkins because he argues that the field of speech regognition is more advanced than that of OCR. Aside from their security, I don't want my visitors to do something unfamiliar, and listening to an audio file to fill out a form certainly is.

I like the idea of asking a simple question, such as "What color is an orange?" or "What is 3+5?". Not sure about the security though. The latter one can be automatically solved by Google itself for example. However, I'm half way convinced that this is an approach that has a bright future.

Promising examples of what might be next

SQUIGL-PIX
On the reCAPTCHA website you can find a link to the SQUIGL-PIX project, apparently the latest project by the reCAPTCHA guys. It presents you with three images and asks you to outline a certain object. Only if you outline the object correctly (after chosing the correct image) the CAPTCHA is solved.

Give it a try. It is fun, easy (for us) and I sure hope it is hard for machines.

CAPTCHA The Dog
Another interesting approach is Captcha The Dog. You are presented with nine images total and have to pick the one that shows a dog while all others show a cat. You have to pick the single dog several times (from different picture sets) and click 'ok' once there are only cats.

The idea is brilliant and the basic reasoning behind it is the same that makes SQUIGL-PIX good: Object recognition instead of text recognition.

Captcha The Dog goes one step further and allows you to use your own set of images, tapping on the financial feasibility to break your individual set of images. There is even a Wordpress plugin available but I have to give a warning: According to the installation page the plugin requires allow_url_fopen and allow_url_include both to be active. Sounds like trading one evil for another. XSS anyone? Too bad, the idea is great.

3D image rotation
The third approach I'd like to present is proposed by Taylor Hayward and apparently does not have a name. It asks you to identify an object appearing in two rotated 3d renders. You are presented with one control image, and a set of nine randomly rotated images out of which one is the (rotated) control image. I found it hard to imagine so go see the blog - it'll be much more clear.

Once again, the method relies on object recognition. Great idea.

"Do not try this at home"

When you google for "php captcha library" you find literally thousands of home grown 'solutions' for secure CAPTCHAs. Once again I can only urge you to read Jonathan Wilkins paper on secure CAPTCHAs before you use one of them. The bottom line probably is that they will not work very well for you because their authors try to obfuscate the letters in a way that poses no or only very limited issues to OCR software.

Just assume that if Googles' solution to CAPTCHA is broken, yours will get broken too once the incentives to try are high enough for the bad guys.

That being said, developing your own approach while sticking to Jonathans guidelines will most likely be an interesting spare time project.

Possible benefits

Believe it or not, I really see possible benefits coming out of this arms race. As the spammers' tactics to solve CAPTCHAs improve, the good guys are forced to improve their generation of CAPTCHAs. After some time, the newer CAPTCHAs will also be broken. The cycle continues.

Naturally, the only way for the good guys to verify that the new version of a CAPTCHA is indeed more secure than the old is to think like a bad guy and try to break your own CAPTCHAs.

This might - and I believe it surely will - lead to better OCR software, better audio recognition and in general a higher standard in 'intelligent' algorithms that are able to solve every day problems.

Audio recognition might help the deaf to read what people say, by other means than lip reading. A universal translator (famous in Star Trek) is not completely out of scope either, although it is still really far away.

Text-recognition is highly in demand on mobile devices. If a program can identify highly distorted characters from a CAPTCHA, I'm sure the same ideas can be applied to read hand writing.