Tag: throughput

Posted on by

Collaboration

Contemporary software development methods emphasize collaborative work over solo work. I remember this idea gaining momentum from as far back as the 1990s, when Extreme Programming was becoming known, including one of its core practices, Pair Programming.

In retrospect, I can recall many instances when people collaborated in an ad hoc way to solve specific problems, going back to the beginning of my IT career in 1977. I’ve read articles and heard stories about the value of collaborative work in engineering going back at least to the 1950s. There was even a deliberate experiment in 1975, carried out by the US Army, on the value of “two-person teams” in software development (the article does not appear to be online anymore, but there is an excerpt in this old blog post: Does pair programming work?).

In all these cases, from formal studies to informal “war stories” told over coffee or beer, direct collaboration provided immediate and palpable benefits to the people involved. That has been my experience, as well. And yet, it seems as if solo work continues to be the norm.

Continue reading Collaboration
Posted on by

Relief valve for Product Owners

In a pressurized system that contains a liquid or gas, when the pressure is too high the system can rupture at its weakest point, causing a halt to operations, damage to the system and, possibly, leakage of dangerous materials into the environment. To protect against this, people install relief valves. The valves guard against excessive pressure and wrong-way flow. One type of relief valve vents into the atmosphere. It is used in applications that do not have hazardous liquids or gases. Another type can direct dangerous fluids to an alternate route, possibly collecting them in a reservoir of some sort, while protecting the system from damage.

In large organizations that use an "agile" process with a formal role similar to the Product Owner (PO) role defined in Scrum, a common problem is that the individuals assigned as POs are asked to work on more projects concurrently than they can handle with due diligence. Often, they are simply asked to add PO responsibilities to their existing workload. Thanks to the historical preoccupation with maximizing individual resource utilization in management "science," the PO’s existing workload usually does not provide any slack. In short, they are already too busy to begin with. Continue reading Relief valve for Product Owners

Posted on by — 3 Comments

Pros and cons of dedicated teams

One concept that’s been getting a lot of play in recent years is the idea of dedicated teams. In the context of software development and support activities, the concept boils down to this:

  1. Any single team is assigned to just one development initiative or to the support of just one set of technical assets at a time; and
  2. Any individual is assigned to just one team at a time.

With this model, you might dedicate Team A to ongoing enhancement and production support of the company’s call center systems. Team A does not do any work to support other business operations or other technical assets, such as contributing to the development of a loan underwriting system, or providing production support for the company’s enterprise service bus. In addition, if Stephan is a member of Team A, he is a full-time member of Team A. He is not assigned 75% to Team A, 15% to Team B, and 10% to Team C.

The dedicated team model is an alternative to a matrixed model of personnel assignment (or “resource allocation,” if you can tolerate speaking of humans as “resources”). With a matrixed model, teams are formed specifically to carry out particular initiatives (typically when the discrete project delivery mode is used), and disbanded at the conclusion of each initiative. Individuals may be assigned to more than one of these temporary teams at the same time, and expected to split their time among multiple initiatives.

Managers who are accustomed to thinking in terms of maximizing individual resource utilization often have difficulty understanding the potential advantages of the dedicated team model. I thought it might be helpful to summarize some of those advantages:

  • Avoiding artificial dependencies between projects
  • Reducing induced administrative overhead
  • Reducing context-switching overhead
  • Increasing domain knowledge
  • Increasing team cohesion
  • Improved visibility and clarity on progress

There are also potential disadvantages to be aware of, such as:

  • Stagnation of technical skill sets
  • Boredom and its associated morale problems
  • Reduced opportunities to learn about other areas of the company’s business, with the risk of developing a narrow perspective on the work
  • Missed value from deep specialists

Continue reading Pros and cons of dedicated teams

Posted on by — 1 Comment

Utilization thinking vs. throughput thinking

In helping organizations achieve their goals for process improvement, I have found the single most prevalent conceptual barrier to be the notion of throughput as opposed to resource utilization. Many, and possibly most organizations hinder their own process improvement efforts when they try to maximize individual resource utilization rather than trying to maximize throughput. Once they are able to move beyond utilization thinking, many other challenges fall away naturally.
Continue reading Utilization thinking vs. throughput thinking