Man vs. Machine

February 8, 2019

I read an interesting comparison this morning. Pretend for a minute that you are a business owner. You decide that you are going to invest in a new piece of machinery. Something really special that you are going to base the success of your business on. Let’s say it costs you $500,000 to purchase this magical widget maker. If you invest that much in a piece of equipment, you aren’t likely to let it breakdown. In fact, you are very likely going to be well motivated to invest further in preventative maintenance, training and repair necessary to keep this machine, the thing so critical to your business, in peak condition. It would not be unreasonable to expect to pay 10% or even more of the original purchase price in order to keep your investment running. We see examples of these sorts of costs, to some greater or lesser degree in any sort of tool purchase, software or otherwise, that businesses purchase today.

You don’t buy something that important to the business without making a significant investment in training and upkeep. Not if you expect that machine to pay off. Why doesn’t the same logic apply to your employees? Let’s say that you hire 10 employees at $50,000 per year. Just like our hypothetical machine profiled above, it’s a total investment of $500,000 for the first year. And just like any finely tuned instrument, there is going to be training and maintenance required for these employees to live up to the highest performance expectations. What is a reasonable number to expect? Well, I’ll warrant that people are just as complicated, if not substantially more so, than any machine. So, let’s use our 10% number again. That means that we would be investing around $50,000 on these 10 people on an annual basis to help keep them performing at the highest possible level. That translates to $5,000 per person per year.

I’ve never seen a business willing to spend even half that much on employee development. And it’s usually with a bunch of judgmental, only for the best-of-the-best, sort of qualifications that limit that expense even further. The fact of the matter is that most businesses today find it much easier to justify spending money on tools and machines than spending an equivalent amount of money on people. Now to be clear, I’m not talking about stuff like health insurance. That’s just table stakes to even get in the game. You aren’t investing in improving my performance by paying for my health insurance. That’s just helping insure that I don’t die. Thanks. It’s good, but it ain’t investing in improving my performance. 

Somehow, even when we are able to say things like, “employees are our most important resource” we are still unable to invest as much in them as we would in a machine. Why is that? Why is it that we find it so hard to spend these dollars on people?

Simplicity of Measure

October 18, 2014


I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.

Using the Agile Cookie Cutter

August 2, 2008

How would you set up your next project? What would you require? I know what I’ve tried in the past – here’s a brief inventory of my standard Scrum Toolkit:

New Artifacts:

  • Team Working Agreement
  • Team Definition of Done
  • Task Board
  • Burn down chart
  • Impediments list
  • Release Plan
  • Backlog

New Meetings:

  • Sprint Planning
  • Daily Standup
  • Sprint Review
  • Sprint Retrospective
  • Backlog grooming

New Concepts:

  • Stories
  • Story points
  • Sprints
  • Releases
  • TDD
  • Continuous Integration
  • Cross Functional Teams

New Roles:

  • Team Members
  • Scrum Master
  • Product Owner

Boy, that’s a pretty long list of stuff. Looking at it, it sort of gives a guy cause to pause and wonder just how any team could absorb all of that. I guess that explains the deer-in-the-headlights look I get sometimes when I introduce teams to Agile processes. Do you need all of that to write good software?

This list is what I might call my “Agile Cookie Cutter”. It is the common set of ideas and practices that I try to role out with every team that I work with. But lately I’ve been thinking that slapping all this on a team all at once isn’t so smart. What I often see is teams going through the motions, adopting these practices whether or not they really need them. People get frustrated when they adopt processes wholesale and then run into problems with subsets of practices. What ever happened to gradually introducing practices and empirically testing their effectiveness?

Information Density and Project Tracking

May 29, 2008

One complaint that I hear from people who don’t like a given project tracking tool is that there is actually too much information on the screen at once. They find it distracting and it makes it hard to find the really relevant information. In response, usually I nod my head sagely, mumble something obscure, and move on.

But when I give my talk on the pros and cons of using physical vs. electronic project tracking tools I neglect to mention this difference. If I stop for a minute and take a good hard look at the task board our team is using right now, it doesn’t say a whole lot compared to the electronic tools we use. For one thing, the team and I keep a pretty sloppy task board. Stuff gets crossed out, notes are written in the margins, extra stickies are tacked on top of other stickies. We know what it all means, mostly, but I’m not sure that anyone else could easily parse it all out. There’s a lot written between the lines in both a literal and metaphorical sense.

On the other hand if I use my electronic tools, they pretty much force me into a much more orderly state. There is a lot of explicit information displayed – it takes a while to setup. But it’s neat and orderly. If I need to make notes, then I can put something in the “notes” field. Unfortunately the notes field is not normally displayed. I have to “open” a story to view the notes. Information is cleverly hidden. Like I said, it’s neat, it’s tidy, there is lots of information, but some parts are hidden.

Hmmm…Of course there is hidden information in my physical task board too. I have a confession to make: As a team, we’re pretty lazy – and proud of it. We’re firm believers in helping our environment by practicing the conservation of syllables. Why use two words when one will do? Mike Cohn said it best, The user story is a placeholder for a conversation. Amen brother! It’s remarkable how much we can read into so few words!

So both types of tools have their own forms of information density. And they both have different types of data that is “hidden”. Of course, I have more control over the physical taskboard than the electronic one. I’m pretty much forced to display certain data using electronic tools – even if it isn’t necessarily relevant to me. That’s probably where the information density argument comes in. I don’t mind information density if it is exactly the information that I want to see. However, if it’s not relevant to me, then it only serves as a visual impediment.

Something to keep in mind the next time you are tool shopping.

Agile Planning Tools Revisited

May 28, 2008

Since my last post listing Agile planning tools a few more have come to my attention including:

Check ’em out. Thanks to those who helped by pointing me toward these products – I appreciate it!

Happy Planning,

Agile Planning Tools

December 5, 2007

A few notes on this list:

I tried to collect just the tools that are written specifically for the purpose of Agile planning. I know that a lot of teams use 3×5 cards and/or Excel for tracking and managing their projects. However, although you can use Excel to manage your planning process, Excel was not created with Agile planning in mind. So Excel doesn’t belong on this list. There are plenty of planning products that make the claim of being compatible with Agile planning. For instance, Microsoft Project has a Scrum plug-in. But MS Project was never really intended to support Agile planning. And if I may be so bold, the support it does provide sucks. So I have left out products that are basically Gant charting tools that some might consider using for planning Agile projects.

This list is by no means comprehensive. If you are aware of additional products that I have missed, please let me know. So here they are in no particular order:

  1. Rally
  2. Scrumworks
  3. XPlanner
  4. Mingle
  5. VersionOne
  6. TargetProcess
  7. xProcess
  8. Extreme Planner
  9. ProjectCards
  10. CardMeeting
  11. XP Story Studio
  12. PlanningPoker
  13. Acunote
  14. SilverCatalyst
  15. PlanB

I learned a few things researching this list. First, everybody and their cat has a planning tool these days. It was only a few years ago that there were only a handful of products available if you were interested in a tool for planning Agile projects. Now they are a dime a dozen. It’s starting to look like a pretty competitive market. There still seems to be a healthy mix of open source and commercial applications, so alternatives are available to fit whatever budget you have (or don’t have).

I’ve provided some minimal information with each product so that you can investigate them yourself. For those of you who want the “Cliff’s Notes” summary, over the next few weeks my plan is to write reviews for these products. Some of them are products that I have used before quite extensively, others I will install and try out.

Stay tuned.

Rally vs. Scrumworks

December 4, 2007

My first impression is that these are two applications that have come from very different backgrounds. ScrumWorks started off as a java based desktop application. Rally is based on an ASP model where the application and data are all hosted at a remote site. Both applications have grown their feature sets over the last two years with what appears to be 2 different objectives in mind. Rally has taken the approach of adapting to a wide range of customer needs, both Agile and traditional. Their goal seems to be to reach the high end customer and integrate with existing high end systems on the market. Their feature set is very broad and has been adapted to fit in a variety of different scenarios. In addition, Rally has also significantly beefed up their integration support in the last two years. There is no doubt in my mind that when it comes to integration and customization, Rally is the clear winner.

ScrumWorks, on the other hand, has kept focused on a goal of serving just the Scrum and XP community. As a result, they have a much narrower feature set that is easier for the typical Agile team to understand. This is just speculation on my part, but I think it doesn’t require as much training to use ScrumWorks. I would describe the ScrumWorks product as more fit for a specific use – in this case for Scrum and XP projects.

In general, when it comes to ease of use, ScrumWorks benefits from the fact that it has a thick client that can take advantage of OS features that web based applications can’t do quite as easily (Drag and Drop, etc.). So in terms of usability, ScrumWorks is currently the clear winner. However, Rally is not resting on their laurels, and they are implementing new usability enhancements that will quickly come to rival those of ScrumWorks in short order.

When we look at reporting functionality, ScrumWorks comes out ahead. ScrumWorks has a custom report generator utility that allows you to create your own customized reports. All of Rally’s reports are fixed and can’t be changed or added to. Once again, Rally is acutely aware of this issue and not likely to let it rest for long.

Cross Team & Program Management – Both products claim to have some cross team and program management features. Neither product really possesses a strong feature set in this domain. Rally defines a program as a combination of a specified product and a specified release – a very loose definition. ScrumWorks uses a separate mechanism that is completely orthogonal to the Stories and releases – instead you can create arbitrary groupings of features which can represent programs. This is a more flexible approach, but it still doesn’t provide the financial tracking features that I would expect from a full fledged portfolio management tool.

Detailed Feature Comparison



ScrumWorks Pro

Desktop (Fat) Client



Web (Thin) Client


Yes – Not all desktop features are available on the web client

Local Database

No – hosted by a 3rd party

Yes – Built into the default installation

Impediments Log


Yes – Tracks dates, resolution, and responsibility

Records blocking issues



Burn Down Charts

Yes – Sprint Burndown/Cumulative flow, Release burndown/cumulative flow, Bug & Test Tracking

Yes – Mike Cohn style ‘enhanced burndown’, Sprint & Release burndown

Customized Reports


Yes – Customizable report builder GUI




Time Tracking

Yes – optional

Yes – optional, but supported with custom reports

Supported Object Types

Release, Sprint, Story, Task, Test, Program, Defect, Defect Suite

Release, Sprint, Story, Task, Theme, Program

Supported Methodologies

RUP, Scrum, XP

Scrum, XP

Drag n’ Drop UI

Limited to certain screens

Used almost universally

Hierarchical Relationships


No – Uses themes instead

Built in collaboration features

Yes – Wiki & IM integration


Test management



Defect management



Program Management Features

Release Status – not really configurable

Release Status + configurable feature sets, Good cross product functionality

Sprint Task Tracking


Yes – nice web based task board UI

Assign Business Value



Product and Role based permissions



LDAP Integration




Yes – Excel, XML

Yes – Excel

Supports Use Cases/Non-functional requirements




Yes – RSS, email


Detailed Change History


No – very superficial

Product Integration

Eclipse, Mercury, Salesforce, Bugzilla

Bugzilla, JIRA



$249/person/year ($21/month)

Admin functions

User accounts, Roles, Custom features, Workspace management

User accounts, Roles

Hardware Requirements

None – externally hosted

Server must be allocated for clients & web app to connect with

Frequency of Updates



Built-in Support for pairing time management


Yes – There are “Team hours” and “individual hours”

Usability for teams

OK, some complain of delays and there are complaints about charts

Good, The thick client offers more natural DnD style of interface – good web interface for task board – natural for teams to adopt

Multiple Teams/Common Backlog

Possible, but awkward

Pretty well thought out


Online, Forums, Coaching, Training

Online, Forums

Integration Technical Options

REST, SOAP, Others