Agile Otter Blog

There are some special challenges with dealing with productivity of knowledge workers. Most of them have to do with the invisibility of the work and the difficulty in managing invisible work. Programmers and testers don't assemble machinery or bend paperclips or mold parts from molten goo. They don't stack boxes or bricks, or swing hammers. The work they do has no physical manifestation, which makes it both hard to observe and hard to understand. I don't blame managers in the 70s and 80s who counted lines of code. It was one of the few visible manifestations of the work programmers do. It was entirely misguided of course, and several of us have experienced net-negative lines of code in consecutive weeks of work (I've even had awkward and unpleasant meetings with managers for "messing up the metrics," ending in an admonition to stop it). Other attempts to make the work visible count data fields on screens and in databases and on reports. This is a bit...

Queuing  If only one person on the team understands the database, then any work done by other programmers that affects the design of the database must wait up for the one competent individual.  Sometimes that queuing becomes significant and impedes the group. If the expert is not available, the work must wait, or else be done in an inexpert way. Loss Experts can go away. Teams euphemistically refer to this phenomenon as the "bus number" of the team -- the number of people who, if they were hit and killed by a bus, would doom the entire project to failure.  A "bus number" of one is an unacceptable risk. A bus number of 10 represents a well-mitigated loss-of-knowledge risk. Thankfully, few developers are hit by buses in the street. Instead, experts tend to be hired away by competitors or companies working in entirely unrelated industries. When this happens, teams do their best to muddle along, sometimes making poor decisions along the way and damag...

Wherever I go, I find people who want to "implement agile" but they want to start with processes and tools. They could develop techniques first, but they want to begin with working at a very large scale and comparing capabilities across teams and maintaining individual accountability and individual review. They want a big program they can plug into their existing system. A lot of organizations want to "go agile" starting with long-range planning, so that they can control the direction and results of the agile teams and track their progress toward n-year goals. They want an agile way to drive their teams in a straight line. Some corporations have layers of hierarchy devoted to contacting customers, usually in the interest of controlling perceptions and getting marketing intelligence. They wouldn't let developers within a mile of anyone who actually uses the software, for fear that they would let the internal culture and personality of the company leak out. O...

(note: I added a 15th, but was worried that changing the title would invalidate links, so you get a bonus observation at no extra cost) I frequently have to address questions about velocity, so in the interest of time I present all the answers here in a short post: Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying. Velocity is (frustratingly) a lagging indicator. It primarily tells you about the fundamental process and technical work you did weeks, months, or years ago. You seldom get an immediate, true improvement. Though velocity is a gauge, it is subject to  Goodhart's Law . It is rather dodgy when used as a basis for governance. Velocity value is highly derivative of many factors, chief among them being the work structure of the organization. The more governance and procedure (permission steps, queuing and wait states, official limitations,  risk of personal blame, reporting and rec...

A friend of mine (Hi George D) suggested that this would make a good poster, but all I have is a couple of blogs, so here is the message that inspired my buddy. My experience is that the less well a team has done in the past, the more oversight is piled on, and that oversight reaches higher and higher levels. There really is no legitimate reason for the CEO to want to know which programmer 5 or more levels below was assigned to a particular task and if he's behind schedule by a week or so. In healthier organizations, the groups and managers that interface with the development group tend not to have the same meddlesome urges. In our transitions, the biggest problem we face tends to be peeling back the expensive and unnecessary oversight. If the team can be rebooted and work with a single stream of smaller, simpler stories (rest of agile practices included) then they can win over the rest of the org in relatively short order. Sometimes in only a year or two, som...

On Aug 4, 2008 I moved from Object Mentor where I was an Agile coach and mentor to various companies to Textura where I have been an internal coach and now am managing a team of developers. I realized that I need a new professional outlet now since I won't be filling up the pages of the Object Mentor blog. My friends recommended that I start working on personal branding by starting up an individual pro blog outside of my work environment. I will be writing from myself, and not from the point of view of any employer. Welcome to the result of that. Now I am working the agile transition from a whole different angle. Hopefully, this will be a great time of growth for me as well and I intend to blog my observations about agile practice as usual. I hope it will be a place where people can participate by giving me new observations, advice, and even possibly an occasional boot to the head. Enjoy. We will cover many miles together.