Update: Scrum Metrics for Hyperproductive Teams

 

The Scrum Metrics for Hyperproductive Teams: How They Fly Like Figher Aircraft will be presented at the IEEE HICSS Conference in Maui in January. A preliminary copy is available online at the link above.

Previously, OpenView Venture Partners videotaped the Scrum metrics presentation that Scott Downey and I presented at Agile 2010. It consists of an animated slide presentation and an Excel spreadsheet that supports RoboCoach, the automated tool for generating a retrospective on your Scrum.

In the presentation, we fine tune the backlog and the Scrum meetings to help create a culture of hyperproductivity. High performing teams are constantly removing impediments. As they go faster and faster the impediments become smaller and smaller, yet constant attention to removing them is critical. Failure to do this is similar to failure of the flight control computer in a high performance jet aircraft. It is always making slight adjustments to keep the aircraft stable. If the computer fails, the plane will spin out of control.

The metrics here are simple to collect and detailed in their capability to assess the stability of a team. For the first time we have comparable metrics across Scrum teams which are useful for identifying opportunities for coaching and improvement.

Videos of the Agile 2010 presentation can be found here. The latest RoboCoach spreadsheet can always be found on rapidscrum.com. The version of the presentation prepared for Openview can be downloaded here.

Outsourcer Says: Do Not Outsource

Guest Blog By Peter Vaihansky, GM Americas, First Line Software

Do not outsource your software development.

Yes, you read that right. I work for a software development outsourcing firm, and I am telling you not to outsource.

But why not? Everyone’s doing it, and everyone can’t be mistaken, right? The common perception is that outsourcing saves money based on labor arbitrage. There may be other factors, but mainly companies do it in order to get more software, probably faster, for less money.

However, the economics of outsourcing are far less straightforward than the labor rates comparison suggests. There really is no such thing as “labor arbitrage” in software development. Unlike copper or wheat, all developers are not created equal, so you are not exactly trading commodities. Furthermore, outsourcing is definitely not without risk, as discussed below. So the concept of arbitrage doesn’t apply, and with it goes the whole proposition.

First of all, are we comparing apples to apples? Yes, that overseas firm only charges you $20/hr for a developer. But how much value are you getting in that hour? How competent is that developer? Are you getting strong people on your team, or mostly recent college grads with questionable skill levels? What experience do they have? One experienced $100/hr in-house developer may well produce more value for you than 5 or even more junior $20/hr people overseas.

Also, remember that you need to train external resources. Initially, they don’t know your product, they don’t know your process, and you haven’t worked together before, so it takes time before they can begin to produce value. While necessary, the investment in a learning curve definitely eats into projected savings. And that senior in-house developer who is fully up to speed will be outperforming them again.

Now let’s say you are beyond the initial knowledge transfer. Are you realizing those savings yet? Hardly. With software development, communication is key. It's hard enough at times to explain to an experienced person in the same room what you want them to build. Imagine doing the same with someone who is thousands of miles away, relying mostly on email and IM, and sometimes on voice and video Skype calls. Software development is a highly involved social process, with people sharing complex ideas and abstract concepts. And no, documentation won’t completely remedy this: you can’t really document everything about a system up front, and any written text is always subject to multiple interpretations. Plus, the market changes so quickly that, by the time your documentation is complete, it's typically obsolete and new requirements are driving a different system. Software development deals with tacit knowledge and emergent understanding. Again, hard enough in-house and even more challenging with an outsourcing supplier (think cultural differences, accents, communication barriers, etc.).

What about the ability to put more bodies on a project? For example, you are late in your release schedule and tempted to add cheaper offshore resources to meet deadlines. Unfortunately, if you do, Brooks’s Law is likely to take effect. This famous principle states that adding resources to a late project will make it later or, as formulated more colorfully by its author Fred Brooks, "Nine women can’t make a baby in one month". Even when a project is not late, more people does not equal more value. With the complexities of communication, a larger team moves more slowly, sometimes significantly so, and productivity is consequently lost. Your investment may buy you more developers overseas, but not necessarily more value in the form of marketable software for your dollar.

Also, don’t forget the extra management costs you'll expend communicating with and monitoring the performance of your supplier. Aberdeen Group’s research shows that over 76% of customers report project administration and vendor management costs to be far higher than expected, which won't come as a surprise to anyone who has done any outsourcing.

Finally, consider the overall risk of project failure. The stats vary but, depending on the source, between 30 and 50% of outsourced projects fail outright: they are either abandoned completely (and the work is brought back in-house at additional cost), or fall radically short in terms of the functionality and business value they deliver. Granted, not all in-house projects are completed either but, with outsourcing, the risk of project failure is higher.

So please, do not outsource your software development.

Unless you absolutely have to. And unless you do it with Agile. More specifically, Scrum.