Ship Software OnTime!

So you are sold on Scrum, but having a hard time getting started, right? There are a lot of questions on your mind:

• How do I convince the team to use Scrum?
• How long should our sprints be?
• How should we handle bugs?
• What if our estimates are not accurate?
• How do we handle items with dependencies across sprints?
• What tool should we use to track everything?
• How do I get my team trained on Scrum?

We’ll tackle each of these questions in this article.

How do I convince my team to use Scrum?

Remember that “using Scrum” mostly means the following things:

1. Making a list of things that you need to get done for the project (product backlog)
2. Prioritizing that list
3. Estimating how long each item in the list will take
4. Meeting regularly to see the status of items and make small adjustments
5. Keep track of how much work remains until the project is finished (burndown chart)

So if you are getting any push-back from your team, management or executives on using Scrum, then don’t refer to it as Scrum. Come in with a plan that says you want to do the 5 things listed above. The resistance will immediately dissipate because there will no longer be a fear of the unknown. It’s hard to argue that “making a list of things we need to get done” is a bad thing. You’ll know it as the product backlog, but who cares if others call it that?

How long should our sprints be?

As a general rule of thumb, most dev teams have a typical “release cycle”. My standard recommendation is that make sure you fit at least 4 sprints to as many as 12 sprints into your release cycles. So if your typical release cycle is once every 6 months, it wouldn’t be a bad idea to have 6 sprints of 30-days each. On the other hand, if your release cycle is only 3 months, you still might want 6 sprints, but make them 2 weeks each.

How should we handle bugs?

There are two types of bugs. There are those that A) appear while you’re still working on a given feature PRIOR to the completion of the feature and B) bugs that are identified AFTER a feature is considered feature-complete. Bugs that are identified PRIOR to the feature being completed should be dealt with right away and the feature should never see the light of day without the bugs being addressed. However, the challenging part of bugs is how to deal with the bugs that are identified AFTER the feature is completed and released in the product.

There are two main schools of thought here. Neither is better than the other. Use the one that fits your team best. Here they are:

1. Log bugs just like any other product backlog item and in each sprint, take a handful of bugs to address in each sprint. In this scenario, bugs and features are thrown into the same product backlog and prioritized, estimated and dealt with just like any other product backlog item.
2. The other school of thought is to track bugs in a separate “Defects Backlog” and have dedicated sprints that focus on nothing but bugs to help everyone stay focused on creating the most stable product. The idea here is that with everyone in the team focused on fixed bugs, nobody is busy introducing new bugs by coding new features and as a result, the team will produce a more polished product.

How do we create more accurate estimates?

The first thing to remember is that nobody creates accurate estimates. The key is to create an accurate overall target release date that is manageable. So there are some best practice rules on creating better estimates. Here they are:

1. Involve at least 2-3 of your most experience engineers on creating estimates, along with the person who will ultimately be responsible for coding it. Take the higher estimate value if the group doesn’t agree.
2. Keep estimates at approximate values that are thrown into larger buckets. For example, your “estimate values” might be:
   • 1 Hour
   • 2 Hours
   • 4 Hours
   • 8 Hours
   • 2 Days
   • 3 Days
   • 5 Days
   • 2 Weeks
   • 3 Weeks
3. If an item is estimated to take 10 minutes, that falls into the 1-hour bucket. If it’s estimated to take 3 or 4 hours, that probably falls into the 8 hour bucket. Being conservative with estimates will address some of the unavoidable down-time for estimations.
4. Expect no more than 6 hours of productivity each day from each software engineer. That means the typical software engineer should plow through 30 hours of estimated work per week. Don’t expect more because they have overhead of meetings, checking email and Facebook!
5. Lastly, be sure to leave room in your overall schedule for unforeseen items, changes that will inevitably be made and other things that you simply can not predict. Generally speaking, you’ll want about 1 week of padding for each month of development. So on a 4 month project, don’t take on more than 3 months worth of work.

How do we handle items with dependencies across sprints?

Dependent and complex items are essentially the high-risk items in software development projects. To minimize the risk, there are two things you can do:

1. Use Proof-of-Concept prototypes as often as possible. These throw-away projects should help demonstrate the feasibility of high-risk items. These items include anything that the team does not have experience developing, which might include a new cool User Interface design, back end data storage, cool new web interface and so on.
2. Tackle the tough tasks in your first few sprints. This will help you identify problems early. You don’t want to find out two weeks prior to your ship-date that a task that was expected to take a couple of weeks will in fact take a couple of months. Putting high-risk items first, will help you get project visibility early that will allow you to change things up to address your timeline.

What Scrum tool should we use to track everything?

It’s always surprising when I find software development teams that still use Excel or even sticky notes, paper and white boards to manage the development of a software project. After all, we are all in the business of creating software that makes some manual tasks easier. There are dozens of software applications out there that are far superior to using Excel or an offline solution.

One example of such a tool (my favorite, in fact :-), is my company’s product, Axosoft OnTime. OnTime is designed to stay out of the way of software developers so they can focus on writing code, which is what software developers do best. But it also provides project managers, scrum masters and executives with all of the project visibility tools that are instrumental in helping them make decisions about the direction of the project.

Here is how OnTime helps Scrum teams:

The Product Backlog

OnTime allows for Scrum teams to manage their product backlog in either of two ways:

• Single Backlog for Everything – The ability to see everything that relates to a given product, version or sprint in a single product backlog is a nice way to view project information. It allows teams to deal with bugs in the same way they deal with any other requirements.
• Separate Backlogs for Defects (Bugs) and Features (Requirements) – OnTime also allows teams to separate defects, features and tasks into independent backlogs. This level of flexibility allows for each type of item to have a separate workflow, allowing defects to go through a different process than feature requests. For example, a defect might need to be verified, while a feature requests first needs approval.

Regardless of which way you decide to go with the product backlog, OnTime provides powerful backlog features that are useful for every user, including:

• Ability to create public and private backlog filters with powerful AND/OR functionality for combining conditions
• Ability to group backlog items to view them by assignee, status, workflow step or any other built-in or custom field
• Ability to create saved public or private views which save everything from fields being displayed, the sizes of each column, filter conditions and more
• Ability to set first, second and even third sort criteria so that you can view your backlog in the way that makes most sense
• Ability to apply a change (such as status, workflow, date or other changes) to multiple items with the click of just 1 button

These features make OnTime one of the most powerful tools on the market for Scrum teams who need fine controls on their product backlog management.

Sprint Planning

Sprint planning is one of the most important activities that Scrum-based teams perform. With OnTime, sprint planning takes form naturally from the product backlog. Assigning items to a sprint is as easy as dragging and dropping (in the OnTime Windows client) any number of items from your product backlog onto a planned sprint. Alternatively, you can use the multi-edit feature to assign a number of product backlog items to any given sprint.

To create the planned sprints, OnTime also makes the Scrum Master’s job easy. The OnTime Releases hierarchy breaks projects in the following way:

• Products – You can manage any number of products in OnTime
  • Versions – Each Product can have any number of versions
    • Sprints – Each Version has numerous Sprints

OnTime also provide auto-calculators for sprint start and end dates. You simply tell the system how many days your typical sprint is and OnTime will automatically calculate the dates.

Daily Standups

All meetings are overhead. With that in mind, the goal of meetings should be to keep them as short as possible (and as Einstein might say, “but no shorter!”). OnTime facilitates meetings, such as the Scrum Daily Standup, by having all the information that’s needed to make decisions ready at hand. A typical meeting starts in a conference room with the main OnTime screen being projected on a screen with a “Daily Standup” Previously Saved View applied to the system to show only the items of focus for the given sprint.

The team has the ability to go through the items right there, make notes, change status and so on, allowing the meeting’s decisions to be captured in real-time without further work that would typically be assigned to the Scrum Master.

Tracking Progress (Burndown Charts)

If you don’t track it, there is no way to improve it. Furthermore, project visibility is perhaps the most important factor for project success. That’s where Scrum burn-down charts play a pivotal role to making sure projects are on track and OnTime provides an extensive set of capabilities when it comes to Project Visibility and Burn-down charts, including:

• View a mini burndown chart on the main OnTime page, giving everybody on the team the same sense of urgency to move the project in the right direction
• Multiple burndown charts depicting one or more sprints, versions or products in a fully customizable Charts Dashboard
• View rollups of burndown charts for multiple sprints for a given version of a product
• Show trend (such as the burndown velocity) and project a ship-date for a given version or completion date of a sprint

The OnTime dashboard provides a number of other useful charts too, like the Treemap, or Trend Reports and even user workloads to make sure you are not overloading a particular team member with too much work.

It’s Scrum On-Demand

With Axosoft’s OnTime Now! Scrum teams can actually signup for and start using a 30-day, 10-user trial of the OnTime system in seconds! Axosoft has done an incredible amount of work to make the OnTime Now! system exceptionally unique with the following features:

• Choice of 6 Data Centers world-wide for maximum Hosted performance
• Ability to use either a web client or the rich OnTime Windows client (this is unheard of in a hosted solution)
• Ability to use OnTime Visual Studio or Eclipse plugins for developers so they never leave the IDE
• Ability to use OnTime iPhone client, a full-featured app that provides dashboards, access to all items and much more – incredibly useful for every team member, especially the Scrum Master

The best part of the OnTime Now! hosted solution is that there is no compromise and there are no contracts. You get to use both Web, Windows, iPhone, Visual Studio and Eclipse OnTime clients and the entire thing is hosted in any of 6 different secure data centers that Axosoft manages around the globe.

Learn More About OnTime Now! >>

It’s Inside of Your IDE (Visual Studio & Eclipse)

Designed to stay out of the way, OnTime provides the ability for developers to stay in the environment where they are most productive: The development IDE. OnTime supports both Visual Studio and Eclipse and allows developers to access the information they need right at their fingertips. The Visual Studio and Eclipse plugins allow users to:

• Add, Edit and modify the workflow or status of items directly in the Eclipse and VS IDEs
• Filter, sort and view items in a variety of ways
• Add notes, attachments and work log entries for items
• View items associated to a product, version or sprint

For developers, nothing is more productive than being able to stay in the IDE while modifying project management related tasks.

It’s Even in Your iPhone

Data was meant to be shared and viewed from everywhere. That’s why OnTime provides every team member with the ability to access their OnTime system from the convenience of their iPhone. The OnTime iPhone client provides some powerful features, including:

• View and edit all item types (defects, features, tasks and incidents)
• Filter and sort the product backlog(s)
• View items by project, product, version or sprint
• Add attachments, notes and comments to items
• Log work done on a given item
• View a number of built-in charts or create custom charts meeting any filter criteria

The OnTime iPhone client is intuitive and powerful. Exactly the type of features

How do I get my team trained on Scrum tools?

The last piece of the puzzle is how do you get your team trained on the tool that you select? Axosoft has a solution for that too. In fact, Axosoft offers a number of FREE Web-Based, Instructor-Lead classes on the following subjects:

• Implementing Agile / Scrum Methods with OnTime (Class code OT-302) – This hour-long class walks you through how to setup an OnTime database to use Agile or Scrum terminology, setup product backlogs and get going with burndown charts.
• OnTime End-User Essentials (Class Code OT-101) – This hour-long class walks typical users through the main OnTime interface covering the day-to-day operations of users, such as creating and applying filters and views, creating new items, comments, attachments and more.
• OnTime Administrative Essentials (Class Code OT-102) – This hour-long class walks your OnTime administrator through the setup process, new user creation, customization of fields and field templates and other administrative tasks.

Did I mention these web classes are free? But they are only available on a first-come-first served basis as class attendance is limited to ensure each person has an opportunity to ask questions. Learn More >>

How do you make an already great project-management on demand system better than ever? How about improving the performance by as much as 500%?

Here is how we did it…

A Little Background

Ever since the introduction of OnTime V2.0, Axosoft has provided a hosted option.  This allows teams that want to get going with OnTime right away the option to do so without having to setup their own installations. We expected this option to be extremely popular, but to our surprise, over the past 6 years, relatively few of our customers have chosen to go the “Software as a Service” route.

Don’t get me wrong, “relatively few” still means hundreds of customers, but we were expecting thousands.

So a few months back, we decided to deep-dive into the numbers and figure out what was going on. What we found was that the closer customers were to Axosoft’s physical data center location, the more likely they were to choose the hosted service.

Hmmm…that seemed odd.

So we did a bit more digging with the help of some external resources to see what the OnTime Hosted user experience was like from different parts of the world.

The results were shocking!

Depending on customers’ locations and bandwidth (with respect to Axosoft’s Tempe, Arizona data center), the performance they experienced could vary by as much as 500% over optimum performance. This was especially true for our European and Australian customers. That meant that an OnTime page that might have taken 1 second to load under normal circumstances might take as much as 5 seconds to load for some customers.

Clearly unacceptable.

The problem, of course, is not an easy problem to solve. Because regardless of how well connected our data center is, we are also bound by customers’ connections — and all of the connections in between. The longer the distance and the more hops between a customer and OnTime Hosted, the worse the performance.

So we focused our entire IT and product engineering team on solving this problem.

Introducing ‘OnTime Now!’

OnTime Now! takes all of the great OnTime features, usability and innovation, and wraps it up in a hosted environment that allows customers to be up and running in no time flat. But it has a unique twist:

YOU get to choose the data center where your OnTime Now is installed from 6 world-wide locations:

The OnTime Now! Data Center locations are:

• Tempe, Arizona (this is where all OnTime hosted customers were until now)
• San Jose, California
• San Antonio, Texas
• Herndon, Virgina
• London, United Kingdom
• Brisbane, Australia

During the OnTime Now! signup process, you now get to choose the data center that will house your hosted account. To make the decision easier, we created a speed test, allowing you to choose the best performing site:

Bandwidth tests from Axosoft headquarters in Scottsdale, Arizona

Once a data center is selected, OnTime Now! goes to work immediately creating the DNS entries for your chosen URL, a brand new OnTime database, your own OnTime Web Server, Customer Portal Server, Remote Server, iPhone Server, SDK and everything you need for your OnTime installation to go live. The entire process takes only seconds, and then you receive an email with instructions on how to get started. It’s pretty amazing.

So How Much Better is it?

While nearly every customer outside of Arizona will see a performance improvement, the most drastic performance increases will be seen by our East Coast (US), European and Australian customers. The chart below shows the relative performance that a typical European customer would experience. The Blue bars show the relative speed to our Tempe, Arizona data center while the Red bars show the performance those same customers can expect from our London, UK data center (shorter bars are better). As you can see, the difference is incredible:

OnTime Now! Performance from European Countries to Arizona and UK Data Centers

We’ve made a ton of other improvements too, but all of them pale in comparison to this one major improvement with performance.

Existing OnTime Hosted customers can expect to be contacted soon regarding these changes so we can transition existing customers to OnTime Now! and the data centers of their choosing.

Learn More About OnTime Now! >>

Try OnTime Now! Free for 30-Days >>

Unprecedented Innovation

Our multiple data center strategy, which allows customers to choose the best performing data center is unprecedented in our industry. It required an enormous amount of effort to execute, not only in identifying and setting up servers in remote data centers across the globe, but also:

• engineering new systems to manage these remote installations from a single location
• allowing customers to seamlessly sign up and choose which data center to use for their OnTime installation
• tying all this into Axosoft’s unique purchasing system (the Axosoft Online Store)
• giving customer control of their system through the OnTime Now! Customer Dashboard

This was an awesome challenge!

Axosoft is truly blessed with some of the most incredibly talented people I know in this industry. No matter what challenges I throw at them, they seem to come up with solutions that shine.

Now, we’re back to the drawing board, coming up with the next big set of innovations that will move our industry forward. It’s fun doing unprecedented things. Stay tuned…

If you have been following this blog, you already know that Axosoft is embracing SCRUM in a big way. We have adopted SCRUM into our own development efforts and we have also made it a top-priority to have full SCRUM support in OnTime 2009 (due out in Q1 of 2009 and currently in beta).

But as our own customer survey showed, even though SCRUM is the top agile development method, it is in use by only 12% of software development teams. So if SCRUM is so great, why is it not more widely adopted? There are several potential answers to that question:

1. There isn’t a single good source of information on SCRUM.
2. The few videos that do talk about SCRUM are either extremely long, obnoxious, boring or vague. In some cases, all of the above!
3. SCRUM classes are expensive. A two-day class generally runs in the neighborhood of $1800.
4. There is far too much talk and unnecessary debate about chickens, pigs and other minor details!
5. The few sources of information that do exist generally push their own products, tools or services.

With that information in mind, I felt that the software community could use a brief crash-course that covers the core concepts of SCRUM without any product, tools or services being promoted to distract the viewer. So I set out to create a video that would introduce SCRUM in under 10 minutes. It turns out, this is not such an easy task.

The SCRUM Script

I started writing the script in a style that might be familiar to a lot of boring college professors:

A product backlog is a list of features…a sprint is like a milestone…blah blah blah

Even as I wrote the script, I thought the script was bad, but I wanted to get something on paper as a starting point. I then shared the script with one of my partners in crime, Angelo Coppola. He immediately blasted it. He ripped into it calling it “boring”, “vague” and “obnoxious.” Wait a second! Those descriptions sounded vaguely familiar. I already knew what Angelo was telling me: a total re-write had to be done. But before re-writing the script, I went to our conference room white board and I created a storyboard of what I wanted in the visuals:

As you can see, I was meant to be an artist! I must have missed my true calling somewhere along the line. With the new visuals in hand (or I should say in my iPhone), I went back to re-writing the script. I brought in Derek Harju, our resident flash artist at Axosoft, asking him to take my storyboard and bring it to life! Pretty easy, right?

In the new script, I decided to introduce concepts and visuals simultaneously. In a previous video I made on a political topic, the impact of bringing in visuals and words together at the same time seemed to work  well. So the script changed from a boring “a product backlog is blah blah blah…” to something like this:

In SCRUM you work with THESE [show a product backlog], which is then broken down into THESE [show a release backlog]…and so on.

This time, I felt the script was much stronger and Angelo agreed. So it was on to the visuals.

The SCRUM Visuals

Over the next several weeks, Derek went to work to bring the visuals to life. From the beginning, Derek’s work was great. Here are a couple of the earlier samples:

The Team and a Product X Under Development

Illustrating the Product Backlog

The early illustrations were good, but they weren’t great. So with each iteration of the visuals, we would make minor adjustments. I would say “the people are too flat” and Derek would make 3D people, Angelo would say “the box is ugly” and would photoshop a potential box. Then Derek would take it and run with it. Eventually, after countless meetings and having way too many dreams about how to illustrate SCRUM, we were finally down the right path. The end results became this:

Illustrating that Feature Requests for a product can come from anywhere

Illustrating the product owner’s involvement in the product backlog

Showing how a release backlog is broken down into multiple sprints

Showing a burndown chart with burndown velocity and due dates

Daily SCRUM

Derek had done an amazing job with the visuals and animations. By now, Derek was probably having nightmares with my voice and the background music as he was listening to it for 8 hours a day! After he finished the visuals, I wasn’t happy with the script again. There were too many unfunny jokes and minor vocal mistakes in the recording. So I went back to GarageBand, which is an absolutely amazing product, to finalize the audio:

After a bunch of minor tweaks to the script and a few dozen more takes, the audio was finally done. I handed it over to Derek to finalize the Flash.

Making an HD Movie

To our pleasant surprise and complete amazement, a week before we finalized the SCRUM video, YouTube started hosting HD-quality videos at 1280 x 720 resolution. The HD Videos on YouTube were stunning and we wanted to be a part of it! The timing couldn’t have been better as the illustrations in our video look very bad at YouTube’s traditional 320 x 200 resolution. We had worked too hard on this video to let the fuzziness of low-quality video kill it, so we were extremely excited to host it in HD.

After getting the final video from Derek, there were still a couple of minor timing-related issues that Flash was throwing at us during the rendering process. iMovie to the rescue:

With less than 10 minutes of tweaking things in iMovie, the video that we had worked on for nearly 5 weeks was now complete. It was time to upload it to YouTube and wait for the HD quality video to show up.

SCRUM in 10 Minutes in HD

About 2 hours after uploading the video to YouTube, the HD version emerged and it was amazing. To have this video hosted in HD, something that would have been impossible just 1 week before, was an exciting feeling. Here is a link to the end result:

Click Here to Play SCRUM Tutorial Video

Within 2 days of the video being on YouTube, it had already risen to the #1 search result in YouTube for the word “SCRUM” and it has made all sorts of top “honors” lists in YouTube’s Science & Technology category. The reviews so far have been excellent and the feedback via email directly to me has been overwhelmingly positive.

So, there you have it…5 weeks of work by 3 people at Axosoft to make this video and not a single product or service promoted.

I hope you enjoy it and pass it on.

In OnTime V9, one of the most exciting features we are adding is a totally re-written customizable project dashboard that is extremely powerful and flexible.

The new dashboard features include:

• Savable Dashboard Views – As you configure your project dashboard graphs, you can define the number of rows and columns on your dashboard and configure each graph or table that it contains.  Then, you can save the configuration as a view, which can be shared with other users or kept private. This feature makes it extremely easy for project managers to create one or two common dashboard views for their teams.
• New Burn-Down Charts – The new project dashboard now supports burn-down charts. You can add any number of burn-down charts to your dashboard for any product, release or sprint. Burndown charts can be based on hours, days, weeks or even story points.

• New Treemap Charts - The new treemap chart is a unique way of seeing the really big items in a given milestone, release, product or project. In a treemap graph, the size of each item is represented on the chart based on the estimated amount of work that is required for completion. The color of the item indicates how much of that work has already been completed.

• New Chart Customization – Each of the charts in the project dashboard can now be filtered and grouped to show different types of information. So now you can view trend information or user workloads as a pie chart or bar chart. You can group by assignee, status, priority or other fields too.

I simply can’t do the new project dashboard justice with this article. The best way to see the new project dashboard is to watch it in action in this Fear The Bug episode (our weekly OnTime series of Video Tutorials) that covers the new Work Log feature and the Project Dashboard coming in OnTime V9.0:

By the way, these features will be included in OnTime V9 Beta 2, which will be released in about a week.

While OnTime has always been a great tool for tracking projects from inception to release, there has never been a built-in concept for managing specific products, releases and the milestones that go into those releases. Some teams have used the project hierarchy to manage releases, while others have used custom fields to track releases and milestones.

With V9, we are making release management exceptionally easy, and we’re differentiating it from the project hierarchy by introducing a new paradigm for OnTime:

• Releases – The Release Management in OnTime allows for the creation of 3 types of [easily rename-able] release types:
  • Products – A product is the name of the product that has a release cycle. In OnTime, this special type also allows you to associate the product to one or more underlying projects so that OnTime can quickly show users a list of items that are associated with the product. For Scrum teams, this list of items would be the product backlog.
  • Releases – A release would be “V8″, “V8.1″, “2008″ or “Beta 1″.
  • Milestones – A milestone is an incremental checkpoint that teams use to keep themselves on track for a given release. Teams generally have 3 or 4 milestones (and often many more) before each release. For Scrum teams, Milestones are easily renamed to “Sprint” so that each release contains several Sprints.

To get an idea of what a set of releases might look like, take a look at the following screenshot:

Notice that the release hierarchy is a special type of hierarchy in the following ways:

• Milestones are the atomic level release type and while technically we have allowed milestones to contain other milestones, we don’t recommend it.
• Releases can contain other releases or milestones. In the screenshot above, you can see that “2008″ and “2009″ are defined as releases, but each of them contains other releases. Containing other releases is a great way to organize a group of related releases.
• Product is the highest level release-type and can contain other products, releases or milestones. Generally speaking, we don’t expect products to contain other products unless they are part of a suite. To illustrate this, a product defined as “Microsoft Office” could logically contain other products named “Word”, “Excel” and so on. As a best practice, we expect products to always contain at least one or more releases.

By organizing items through this Product -> Release -> Milestone system, team members and project managers can quickly look at the items that pertain to a particular release or milestone for a given product. Visibility into a release is also vastly improved and since each release or milestone has a target completion date, the new Project Dashboard can be used to keep on top of how well work is progressing for a given release.

Important Concepts

There are some important concepts to understand with OnTime’s release management:

• When you define a new product in the releases tab, the product can be associated with one or more projects from your projects hierarchy. This association is only for convenience, so that you can easily select a product and quickly find all the items that are associated with that product, allowing you to quickly assign those items to a given release or milestone.
• Items can only be assigned to 1 product, release or milestone. However, as a best practice, we expect that items (such as defects, features and tasks) will only be assigned to a single Release or Milestone and not to a product.
• To see all the items that are assigned to a given release or milestone, a user would simply click on that release or milestone.
• To assign items to a given release or milestone, users will need to select the underlying product (or “All Releases” and from the list of items in the grid, select the items they want to associate to a release, then use the multi-edit menu to change the release. OnTime Windows users can also drag-and-drop items onto a release to change its release assignment.

Once you have created your Product -> Release -> Milestone hierarchy and assigned items to milestones, you will find that you have significantly improved the visibility into your project schedule.

Release Notes

As a result of the new release management system in OnTime, the commonly dreaded development activity of coming up with a list of “release notes” for a given release is nearly automated. Any user can simply select a release or even the underlying milestone to look at the items associated with that release or milestone. Running an automatically filtered report will also provide a PDF-Ready document that can be shipped as the release notes for a given release or milestone.

Release Management for Scrum Teams

If your team manages projects using Scrum, the first thing you’ll want to do is rename “Milestone” to “Sprint” using the Manage Release Types window (accessed from the Releases Toolbar):

You will then want to create a product the represents your product’s backlog list of items. Inside your product, you’ll have one or more releases, each of which will contain one or more sprints. When you create your sprints, pay special attention to the duration of a sprint as the duration will be used in Burndown charts:

To assign items to a sprint, you simply select the product which contains your entire backlog and assign items to the appropriate sprint using either drag-and-drop (Windows) or Multi-Edit menu (Web or Windows).

Summary

Successful project management is easy. Successfully executed projects have at least these 3 common elements:

1. Somebody (or everybody) maintains a list of everything that needs to get done, broken down into manageable chunks, with time estimates for completing each chunk;
2. Every team member has a prioritized list of those chunks, which they are responsible for completing;
3. There’s at least one person who monitors the progress to make sure things are on track.

Perform the above 3 tasks, and your project will have the highest probability of success. Sounds simple and it really is that simple! Even if you did the above 3 tasks on paper, without the use of any fancy tools, your chances of succeeding would be greatly enhanced. Project management is not rocket science, but rocket scientists performed the above 3 tasks to land a man on the moon in 1969 with less collective computing power than the iPhone strapped to my belt.

Over time, however, best practices for how exactly to perform the above 3 tasks have emerged into hundreds (if not thousands) of project management books. Numerous methodologies have emerged, many from NASA. Most of these process-driven methodologies detail exactly how teams should perform every nitty-gritty task. Yet, with all these awesome project management methods and years and years of experience, NASA, perhaps the icon of organized project management, cancels and/or delivers more late and over-budget projects than it did back in the 60s.

Why is that? Why is it that NASA, with all of its project management wisdom, couldn’t dream of doing what a few engineers did with the leadership of Burt Rutan — building a spaceship for under $30 million and winning the X-Prize? Rutan and his team built a rocket that can carry 3 people into space and an airplane that carries the rocket to launch to a high launch altitude.  And, they successfully launched it into space twice in two weeks.

The world is full of examples where “regular” amateurs with far fewer resources and a lot less project management structure end up beating out larger, well-established companies that have relatively unlmited budget and their process methodology down to a science.

What all of these amateurs have in common is that none of them use a heavyweight, well established process to manage their projects. There are no examples I know of where a new company or team used a six-sigma process to unseat a leader in the field, but there are plenty of examples of a couple of 20-year old kids who worked using the “fly by the seat of your pants” method on a computer, search engine, operating system, web site or some other gadget that ended up changing the world.

Corporate America is also taking note. Some companies have recognized that the biggest risk to their well-established business is the “fly by the seat of your pants” methodology and they’ve decided to embrace it, although most are doing so reluctantly, without enough urgency, and half-heartedly.

Adoption of agile software development techniques, such as Scrum, are rapidly growing as a result of the flexibility they provide in managing projects the way a team sees fit.  Google is a great example of a company who has whole-heartedly embraced the fly by the seat of your pants, entrepreneurial techniques. They have built their success as a company who employs little process, manages through chaos and has little structure in anything they do. The result is a company that is nimble, quick and surprises the industry and competitors with both its hits and misses.

Axosoft’s own customer base, as illustrated by a recent survey, is also of the belief that rigid project management techniques don’t pay. More than 60% of Axosoft customers don’t use any particular software development methodology.  But, of those who do, Scrum, a relatively new agile development technique, is the one that’s gaining the most popularity. That’s no accident.

A Quick Look at Scrum

Scrum’s popularity is rooted in its back-to-basics philosophy; its simplicity and flexibility in execution. If you are new to Scrum, you might want to start with this presentation that Ken Schwaber (co-founder of Scurm) delivered for Google:

Ken Schwaber Introducing Scrum at Google

When I watched this video, one thing that stuck with me was the fact that Google engineers were getting introduced to and encouraged to use Scrum. If Google, a company that thrives on chaos, is embracing Scrum to some level, then it’s worth investigating more. So I set out to learn as much as I could about Scrum.

There are a number of great resources on the web. The Wikipedia page on Scrum is a good starting place. After reading a ton of material on the subject, I started to truly appreciate Scrum’s simplicity.

Scrum can be summarized as follows:

1. Projects have a list of things that need to be accomplished. Since these items are not yet done, we’ll call this list the “Product Backlog“. It contains everything we’d like to have in the product.
2. To keep things manageable, we’ll select a handful of items from the product backlog, assign them to team members and focus on getting just those items to a ship-ready state. We’ll call this the “Sprint.” We’ll keep sprints relatively short so that in a particular product release, we have at least several sprints. The shorter our product release cycle, the shorter the sprint duration.
3. To keep track of where things are, we’ll add up all the estimated hours of work currently remaining and compare the total to previous days to make sure it is consistently going down at a rate that is in line with our expectations and will meet our goals. We’ll call this the “Burn Down.” Charting the burn down information is an effective way to visualize the progress.

With just the above 3 concepts, any team can successfully implement Scrum. To make sure I had the basic concepts down, I picked up the phone and had a conversation with Ken Schwaber (co-founder of Scrum, founder of Control Chaos and author of a few books on the subject). Ken and I hit it off right from the start. Scrum is about common sense. It doesn’t define a rigid process, but rather a flexible one. It focuses on project visibility while everything else is about the basics (making a list, prioritizing and checking them off one-by-one).

Flexibility is the key to success with Scrum. Some teams, especially those who come from a high-process background expect Scrum to have definitive bounds for everything, to explicitly define every detail. A sprint is exactly 30 days (it’s not!). A must-have stand-up meeting that’s precisely 4 minutes 30 seconds long. You get the idea. But Scrum is about allowing teams to define the ideal practices for their situation based on team size, project size, release cycles, etc. A 2-man team working in the same room on a new web product might have weekly release cycles and no need for meetings, while a 100-person team working on a 10-year old, mature accounting package will have vastly different needs. Scrum’s flexibility is what allows it to work for both teams.

To be sure, Ken Schwaber and Jeff Sutherland (the other co-founder of Scrum) have done a lot of work to define Scrum in far more detail. They define common terminology for roles, best practices for conducting meetings and other project management events that are generally required for a successful project. But the basic concepts, much like the basic concepts of boolean algebra, are simple.

Scrum and OnTime

If you are an OnTime user, you’re probably wondering how OnTime handles the needs of Scrum teams. Looking at the above 3 fundamentals of Scrum, OnTime manages them in the following ways:

• Product Backlogs – The default OnTime “Features” tab is an ideal place to store product backlog items. In fact, many OnTime customers who use Scrum rename the “Features” tab to “Product Backlog” or “User Stories” in order to use the Scrum terminology. You can do that from the Tools -> System Options menu.
• Sprints – The ideal way to manage sprints in current versions of OnTime is by creating a custom field called “Sprint”. The field could be a picklist populated with potential sprints. You can then assign items to these sprints.  And, since OnTime’s main list of items can be filtered, sorted or grouped by  sprint at this point, you can easily look at the items for a given sprint.
• Burn Down – Current remaining workload for a given sprint, release, project, or any other filtered list can be obtained by simply looking at the status bar in OnTime’s main window. However, OnTime falls short in providing historic burn down information in the form of a burn down chart.

Here are some screenshots of OnTime being used in a Scrum environment:

OnTime Used in a Scrum Environment

In the above screenshot (click to enlarge), the following areas are highlighted:

1. As you can see, the “Features” tab has been renamed to Product Backlog (this is done from Tools menu -> System Options -> Item Types). To illustrate a focus on Product Backlog, I’ve also removed all other tabs from the view.
2. I’ve renamed “Feature” (the singular reference to the item type) to “User Story” which is more inline with the terminology used in Scrum. So in scrum, you add a new “user story” to your product backlog.
3. I’ve grouped my view by Sprint. In this case, I’m looking at all the sprints for the currently selected project and I’ve created a custom picklist with my sprint names.
4. In the taskbar area, you can see the highlighted section identifies the current workload for the items in our current view. Since our view can be filtered to a project, a sprint or by a user, you can quickly see the workload by a number of different criteria and you can see how much work remains.

It’s also worth illustrating how easy it is to assign a bunch of items to a particular sprint:

Assigning Groups of Items to a Sprint in OnTime

In the above screenshot, you can see how a group of items are being assigned to a particular sprint using the multi-edit menu. In the above screenshot, the view is grouped by the custom Picklist field I’ve created called Sprint and since items not assigned to a sprint are shown in the “[None]” group, it’s easy to quickly identify those items in our product backlog and assign them to a sprint.

Future of Scrum in OnTime

OnTime is an extremely effective tool for managing Scrum projects, but I think we can do a far better job in future versions of OnTime. To make sure we fully embrace Scrum for future releases of OnTime, I had our entire team learn about Scrum. I also made sure we had multiple team members attend a two-day workshop with Ken Schwaber to become certified “Scrum Masters.”

Axosoft has embraced Scrum in a big way and we have made Scrum one of the main focuses of the next major release of OnTime. More generally, OnTime 2009′s focus will be on Project Visibility, which will help every single OnTime customer, not just those using Scrum. But for Scrum teams in particular, especially those hungry for some burn down charts and other visualization tools, you won’t be disappointed.

I can’t wait to talk more about the upcoming features, but that’s for another blog and another time.

I am working on a simple test that software development teams could use to determine whether or not their projects will ship on-time. I ran this test by Eric Sink who helped refine a couple of the questions. I think his input made the test stronger and I’d like to get some feedback from you.

It would be great to see what your results are and if you agree with the results based on this test:

To determine whether your team will ship the project on-time, use your Total Score and compare it to the following scale:

The goal here is to make questions easy to answer and still be able to get accurate results. I am going to make this test into a web-based calculator that any member of the development team could use to help determine their team’s chances of shipping software on-time, so I need as much feedback as you can give.

There are a lot of other factors that came to mind, but were omitted from the test to keep things simple. For example, you might be thinking “what about using past success rates” or “quality of estimates” in determining whether the team will ship on-time. However, I’m trying to leave out questions that are difficult to answer (too subjective) and allow for first-time teams to still be able to use the calculator to estimate their success rate (no reliance on historical data).

You might also ask “isn’t it subjective to categorize your team into 3 levels of productivity?” The answer is yes it’s a little subjective, but I bet most people would agree with your categorizations (with possible exception of the individuals who are being categorized in the negative or neutral category). Most of us know who the super-stars and the bozos on the team are. Everybody else is a normal, productive team-member.

So the questions are easy to answer, but the result should be extremely accurate. I’m curious to know if you agree.

Axosoft’s flagship product, OnTime (which is a software project management tool: bug tracking, feature management, team wiki and helpdesk), is constantly being improved. It’s been less than six months since its last major release, and we’ve already made tremendous improvements that will surely please even its most demanding user (usually, me).

In this article, I’m excited to share some of my favorite new features.

New Management Console

Over it’s 8 major releases (and countless minor releases), OnTime has flourished into an unbelievably powerful product. It keeps tracking and managing more as it matures. It keeps acquiring more of the “nice touches” software development teams appreciate. If there is a cost to all of this, it’s the fact that the complexity of the product has increased, a bit, too.

To help address this problem, we created a visual map of managing the OnTime system. Take a look:

OnTime V8.1 Management Console Screenshot (Web & Windows)

The new Management Console allows most management functions to be accessed from a single location.

“Hey, the Tools > Manage menu was a single location, too!” you say?

Sure, but what’s great about this console is that it provides:

• visual grouping of management categories, clustering related management features together (for example managing users and security roles are closely related);
• visual workflow cues for which order to perform management tasks (for example, you probably want to work on custom fields before designing a field template);
• detailed tool-tips that explain exactly what each management item is for.

The Management Console also trivializes another task: it effortlessly communicates what you can do with OnTime. With just a 10-second glance users can see that it’s possible to create custom fields, field templates, get email notifications or setup POP email accounts that will be automatically checked with OnTime.

With the new Management Console, I’m betting 90% of existing users will learn something new about OnTime, and 100% of new users will appreciate this feature for the instant crash course in functionality and for providing such a great place to get started.

New Color-Coded Items

Ever wish you could quickly see high priority, open items, items in a particular workflow step or items that are assigned to you without having to sort, filter or re-group your list? Well, now you can! OnTime V8.1 adds item color-coding so that items in various statuses, priorities, severities or workflow steps will naturally jump out at you. Additionally, items assigned to you can appear bold, so you won’t miss them.

This is an incredibly powerful feature that is guaranteed to enhance productivity. Take a look at this screenshot:

OnTime V8.1 for Windows Color Coding Screenshot

OnTime V8.1 for Web Color Coding Screenshot

In this case, you can see that high priority items are highlighted in yellow, critical items are red and items assigned to me (administrator in this case) are bold. Users can decide what, if anything, gets highlighted and which colors to use.

New Email Tab

If you use OnTime to manage your support incidents via email, you’re going to absolutely LOVE the new Email tab. The new email tab allows users who regularly respond to incoming emails to use an interface that is optimized for managing emails rather than incidents.

The result is a huge improvement to productivity for customer support reps.

OnTime V8.1 for Windows – New Email Tab

OnTime V8.1 for Web – New Email Tab

Now support reps can respond to a email-related tickets from a central place designed to manage emails. Users can also search emails, group, filter and sort emails as one might expect from a email-focused work area. 

Wiki Pages Through Customer Portal

The new Wiki page feature in OnTime V8.0 has been tremendously popular. We have seen teams use Wiki pages to collaborate on everything from the creation of standard procedures to team directories to useful web-links to descriptions of major components in their projects (and everything in between). But one type of wiki page that teams couldn’t create, until now, was a page that was visible (and even editable) by their customers.

So, in OnTime V8.1, you can determine whether or not wiki pages are visible and editable in your OnTime Customer Portal. This is a great way to collaborate with customers, share common documents: installation instructions, FAQs and more. You can even permit customers to create and modify documents through the new Wiki tab in the OnTime Customer Portal.

OnTime V8.1 Customer Portal Wiki

Move and Easily Close Main Tabs

While the ability to rename OnTime’s main tabs has been in the product for a long time, the visibility of the tabs was controlled only by security privileges. If you had access to a tab, you saw the tab no matter what. The order of the tabs was also carved in stone. So if you’re a support engineer who basically lives in the Incidents tab (the 4th tab), you couldn’t put that tab in the first position and you couldn’t get rid of the other tabs you don’t use.

All that has changed with OnTime V8.1. You can rename tabs (as before), remove them and add them on the fly and determine the order too! Even better is that the settings are saved on a per-user basis, so each user can determine their own tab order or whether or not they want the icon or text to be visible. We think this new enhancement adds a nice finishing touch to the customization of the main OnTime tabs.

Here are two screenshots to illustrate:

In the above screenshot, you can see the Incident tab being dragged to the first position and only 2 other tabs are visible (all other tabs have been turned off).

In the above screenshot, you can see 5 tabs turned on with only icons visible (the text has been turned off) and the default order of the tabs has been changed.

Big Notification & Alert Improvements

Alerts have been significantly improved with the following new features:

• Filter alerts can now provide users with notifications on their own assigned items only, versus all items that meet the filter criteria.
• Filter alerts can now remember the previous results each time the filter is triggered, and only notify a user if the results have changed since the last time it sent an alert notification.
• Alerts can be set to recur at a specific time on a daily or weekly basis. You can even set up a scheduled alert to only happen on Mondays, Wednesdays and Fridays at 9am if that’s what you want.

OnTime V8.1 for Windows – New Alert Schedules

OnTime V8.1 for Web – New Alert Schedules

Email notifications are getting an improvement too with the separation of edit notifications from item detail notifications. For example, it’s now possible to receive an email notification when an attachment is added or when a new SCM file is associated to an item or when a new email arrives about a particular item.

Big Performance Gains for OnTime Web

With each new release of OnTime, we have made it our mission to improve some area of performance, while still adding more functionality. With V8.1, the focus has been on Web performance improvements. Here are some of our accomplishments:

• Add/Edit Pages now load more than 30% faster in IE and more than 50% faster in FireFox
• Home page has received visual improvements, but still loads slightly faster than before
• Changing from Projects tab to Customers and Users tabs is now noticeably faster
• Switching main tabs (defects/features/incidents/etc.) is now noticeably faster

Support for Visual Studio 2008

We might not be able to keep up with Microsoft product names (Visual Studio, then Visual Studio.NET and back to Visual Studio again), but we keep up with their releases and OnTime V8.1′s Visual Studio[.NET] add-in now supports both VS.NET 2005 and VS 2008. In fact, it even supports Visual Fred 2008.

Lots of Nice Little Touches

There’s a lot more in V8.1. With all these new features, a .1 release is a little misleading. We should probably be calling it OnTime V8.5. Here are some minor improvements that you might find useful:

• Ability to send SMTP emails through SSL (that means Gmail works now!)
• Automatic update of actual time spent when work log entries are added
• Incoming Emails about an existing item can now trigger a workflow change (such as re-open a closed incident)
• Improvements to default security roles for new databases
• A new User Resources screen that allows new users to get the most from OnTime
• Improved item-lock management
• OnTime Express now has unlimited security roles
• Ability to search for customer and user email addresses when sending an email
• Added “Not Like” operator for filters

And of course, we’ve fixed numerous “unadvertised features” (aka bugs).

We think everyone is going to love OnTime V8.1. If you’re currently an OnTime V8.0 user, a V8.1 upgrade is a must-have and if you’re the user of on an older version of OnTime, what are you waiting for?!?! The productivity improvements offered by the new wiki pages and the slew of other improvements in V8.0 and V8.1 are definitely worth the 10-minute upgrade time, so get to it!

The Release Candidate for OnTime V8.1 is available now and the final release will be available in June:

Updated:
OnTime V8.1 was released on June 11th: 

Get OnTime V8.1 Now

There are a number of common-sense software development practices that can actually hurt your chances of success.

Here are 5 common-sense items you might want to avoid:

1) Treat Team Members the Same

It’s common practice and it makes sense. It’s fair, right? Treat everyone the same. What could be wrong with that?

The origins of the “fairness” practice may come from early childhood when kids discover crying “no fair!” is a great tactic for getting what they want, or maybe it has something to do with the golden rule of “treating thy neighbor as thyself.”

But in practice, we usually do treat our neighbors differently. Some neighbors we hang out with, invite to our houses and party with into the wii hours of the night. Other neighbors we avoid like the plague. So why do we force ourselves to treat all team members the same?

Some team members contribute immensely to the success of the project; they are self motivated, get their work done on-time and get along with everyone. Others, we can hardly count on, they consistently miss self-projected deadlines, they are sick a lot (in the Bahamas) and frequently complain about others.

Why should these two personalities be treated or rewarded similarly? Doing so only reinforces the negative behavior and increases the risk of losing the preferred team member. You have limited resources, both in time and reward-money. If you spread them equally among the team, it’s a disservice to your organization.

You can count on your best team members recognizing that and not tolerating it for long.

2) Follow Established Procedures or Processes

Procedures and processes are there for a reason: to avoid mistakes and to identify the people who make mistakes. Following the rules only makes sense. Avoiding mistakes is a good thing.

Well it might be a good thing, until your best team members start to feel as though their hands are tied behind their backs and if it wasn’t for some stupid process, they would be able to get a task done in 1/10th the time.

Avoiding mistakes is a good thing, but at what cost? Software engineers are essentially problem solvers. That’s what they do all day. The best of them enjoy and derive fulfillment from solving problems with the least amount of effort (both personal effort and computing resources). They are by nature very intelligent people. Every developer on the team probably possesses well-above-average intelligence. They will find ways to solve problems, but if they are bound by some arbitrary rules that prohibit them from deviating from standard procedures and processes, their productivity (and creativity) is limited.

This isn’t to say teams should avoid processes all together. But as a team, there are two ways to view processes: one is to view them as the laws of the land which should be followed at all times and the other is to view them as a set of recommended guidelines that seem to work well, but feel free to deviate as you see fit. The latter is far more productive for intelligent people.

To invoke another biblical adage: The process is created for the team, not the team for the process.

3) Create a Detailed Design Before Starting Development

Seems like a great idea. A detailed design is like a step-by-step instruction list on how to get the job done. Having a detailed design makes the programmer’s job much easier. Nearly brainless. If X is the input, Y is the output. Don’t think about whether or not it makes sense. Just do it.

With detailed designs, you nearly guarantee an increase in productivity and you nearly guarantee a result that’s mediocre at best. Without the ability to refine and adapt a solution as the work is being performed, you eliminate hundreds of branches of potential evolution, which could have made the result that much better.

But having evolutionary branches of a potentially better solution scares a lot of project managers. What if the branches are never-ending and the solutions never get done? That’s a real possibility if the project manager doesn’t do his job well, because a huge part of that job is to help guide the evolution to an outstanding result.

Plus the up-front savings of avoiding a detailed design and opting instead for rough design guidelines will often produce better solutions in less time.

4) Make it Difficult to Change Requirements Mid-way

Project managers are all about delivering their projects on-time and on-budget. The number one risk-factor for delivering a project on-time is a change of requirements.

And, that’s why we have change committees involving numerous people from different departments whose job it is to approve any changes to the established project scope. They analyze the impacts of a change on the project schedule and the budget, often inflating both to increase the likelihood of rejection or at least provide some padding in case the change is approved.

The results are predictable. Changes are nearly always killed by the change committee. Who in their right mind would approve a change that increases the cost of the project and delays the delivery date?

Here’s the big problem with killing nearly all changes: some change is good and by making changes difficult in general, too many changes are killed. It’s a chemotherapy approach of dealing with change…kill nearly everything and hope that the few surviving cells happen to be the ones you wanted to keep in the first place.

That’s definitely one way to do it. But, development teams that employ a democratically-run change committee (1 person, 1 vote) will never create outstanding products. Ideally, changes should be reviewed by teams of 3-4 people, with 1 person having the ultimate say, after considering the input of the committee.

5) Assign Tasks Based on Resource Availability

Gantt charts are a project manager’s best friend as they allow the project manager to view the entirety of the project in a visual representation with dependencies and they can even provide resource assignments. But one of the drawbacks of the Gantt chart (such as Microsoft Project) is that project managers are encouraged to simply assign tasks based on resource optimization and leveling features.

The problem with this should be obvious: important tasks are often randomly assigned to team members based on their availability rather than their skill sets. This is a huge mistake!

Another one of the project manager’s major roles is determining the strengths and weaknesses of each team member and assigning tasks based on this information. Assigning critical or show-stopper tasks to a weak team member is a recipe for disaster. Likewise, assigning trivial tasks to your most talented team members is a waste of your best resources (not to mention a risk of decreasing job satisfaction for those team members).

No Gantt chart is going to identify this information for you. That’s your value-add to the team.

Hopefully by avoiding these common(-sense) mistakes, you can improve your development success. Remember, a lot of the above hinges on the quality of your team, which I wrote about previously. I’d love to hear your thoughts on the above suggestions. Leave a comment if you agree or disagree with some reasons or examples why.

Let’s get one thing out of the way fast: There is no possible way to build and ship quality software on a tight schedule by outsourcing the development, period. If you are in the business of software, then be in the business of software and suck it up and build a team that can write the code. Outsourcing your primary application development is the equivalent of outsourcing the defense of a country. Here’s the primary thing you are admitting when you outsource:

By outsourcing the development of your software, your company is admitting that another company is better than you are at creating the very product that you want to create. You’re also admitting that they can do it cheaper and they can do it better than you can while still making a profit selling it back to you.

If that’s true, then why are you in the business of building software? You should be selling dogfood or cat litter. If you are in the business of selling dogfood or cat litter, then great, continue outsourcing. But even Amazon.com, a company that by any measure is in the ”retail” business, builds their own technology and they consider it one of their primary business advantages. If Amazon.com considers it a major advantage to build their own technology and doesn’t outsource its development, then why would you even consider it?

Outsourcing breaks some of the primary laws of building great products. To build a great product, you must have a great team. Notice I didn’t say “you should” or “it would be nice to” have a great team, but rather you must have a great team. A team is inclusive of the designers and developers and testers and trainers and support personnel! If you think that the designers can throw the design over the wall and have the developers give them back a great product, you’re sadly living in a dream world. Although the threshold of importance is substantially reduced with each of the latter items (such as testing, training and support), the quality of those items are also substantially reduced when those items are outsourced.

Lets take a closer look at the most common area of outsourcing: support. Of all the parts of software development, support is by far the easiest to outsource. It requires the least amount of technical knowledge and support managers will often tell you it’s all about “respecting the customer” and “having patience.” So if you can find people in India or Romania who can provide respect and patience to your customers at less than 1/3 the price, theoretically, you should be golden. But anybody who has spoken to a support rep recently from Microsoft, Dell, HP or any other larger tech company who is supposedly saving money by outsourcing support knows from experience that no matter how much “respect” these customer service reps provide, you end the conversation more frustrated than the start, swearing into the air and vowing to never buy from that company again. Of course you end up going ahead and buying from them again because you have no choice, but this time you know, with a heavy heart, that your purchase price doesn’t really include the promised support. Ironically, from the perspective of these companies, their outsourcing strategies save millions of dollars and not just because of the lower cost of labor. The fact that you are less likely to make a 2nd call into an outsourced support center provides an even bigger savings. So here’s what happens when a large company outsources support:

• Initial costs are substantially reduced due to lower labor costs.
• Call volume is reduced (due to frustrated users who give up calling) implying that the new call center is doing a fantastic job or the overall support strategy is working great, reinforcing the behavior that outsourcing was the right thing to do.
• Surveys will reveal nothing because A) nobody fills out 20 minute surveys and B) those who do are almost always complaining, so the percentage of complaints does not appear to be any higher than when the support was in-house.
• It does not appear that outsourcing support has had any impact on sales. This is, of course, is only a temporary effect as customers often don’t have a choice, but as soon as they do have a choice, it’s over!

So, the outsourcing strategy may initially seem like a success, even while it’s failing miserably. If you can outsource support, then why not documentation or testing? Eventually, why not development? Nobody dares outsource Design. At least not yet. But the metrics are flawed and those who rely solely on metrics for the operation of their business shouldn’t be in business. They’ll get what’s coming to them.

Note that I’m not picking on India or Romania. It would be equally stupid for an Indian company to outsource its software development or support to a US company if labor costs were reversed. I’m also not against outsourcing from the standpoint of “keeping jobs in America.” That’s about the worst possible reason not to outsource. It disrespects humanity and implies that an American’s life is somehow worth more than a non-American. Outsourcing simply doesn’t make good business sense. At least not for a company that wants to be great.

The Optimum Team

At Axosoft, we often move people around, even as little as 20 feet, just to be closer to somebody that they expect to work with on a project. It’s amazing how much productivity can be gained by being next to a person vs. 20 feet away. It encourages conversations and questions about design items, issues, features and things that would have been passed on if the people were simply 20 feet further apart. Having these conversations allows the teams to build a better more solid product in a shorter period of time with fewer defects. Increase the distance by 20 feet and you lower the overall productivity and product quality by some amount. Increase the distance to 20 miles and your productivity and product quality tanks. Increase that by to 10,000 miles and an equally large cultural gap — and you can imagine what will happen. There is a reason why companies like Microsoft, Google and Apple have built corporate “Campuses” that are focused in a single location. The close proximity of all the engineers to one another is a good thing. It creates a healthy feedback loop, which helps increase productivity and increase the overal quality of products and what’s possible. So the optimum team is one who’s physical proximity is as close as possible and its different functions such as design, development, testing and support are not outsourced.