Jul 052015

[For some related posts about application lifecycle management, click here and here. For my video series on ALM, click here.]

Software teams are usually very responsive either to their own organization or the customer; it’s harder to find a team that is good at responding to cues from both. For example, I’ve known teams within corporate IT that are so enmeshed with their customer that the business, for all practical purposes, manages and runs them. I’ve also seen teams in software companies that are primed to respond every time an executive clears her throat, but far less responsive to customer issues.

In part, these behaviors are the result of corporate culture: for example, in vertically-oriented bureaucracies with little tolerance for chaos or error, teams develop the sensitivity to executive eyebrow-twitches as a matter of survival. When you ask the organization to change, it’s typical for teams to see a threat to their preferred orientation, to either the customer or the organization. During Agile adoption, I’ve seen teams so submerged in their own organization that they had never spoken with a customer in person. Imagine their response to phrases like, “the collaborative co-creation of value.” In contrast, I’ve also seen teams who were so in love with their product, and so dedicated to the prompt resolution of their customers’ issues, that the idea that their product didn’t merit its current level of investment was harder to grasp than string theory.

From years of working with teams, or working in them, I don’t think that team-level measures alone can fix these imbalances. A team over-focused on customers might see Agile or UX as reasons to hyper-focus. (See, the experts tell us how important customer collaboration is! Now go away.) A team over-sensitized to its own organization might take Lean or improved portfolio management as just a new language of internal directives. (Too busy to talk to customers, must eliminate waste!)

In the video series I posted recently on ALM, I identify alignment as the important measure of whether teams are delivering value. When teams are focused too much on their own organization, or on the customer, they’re not delivering as much value as they could. Like a parent guilty of doting too much over a favored child, they’re guilty of neglecting everyone who needs their attention.

Alignment is a critical part of ALM for these very reasons. While you can quantify alignment, as a diagnostic tool, I’m grateful often just to get people to see that there is more to delivering value than making your company or the customer happy. At least then, teams can start addressing both the neglect, and its costs.

A great example of this principle in action is technical debt. (I’m privileged to be part of a working group on technical debt for this year’s Agile 2015 conference here in the Washington, DC area, so I have technical debt on the brain.) Why do people incur a lot of technical debt? Why are highly professional people, who usually take a pride in their work, willing to take shortcuts that increase cyclomatic complexity, make it harder to fix production issues, inspire rage in people trying to understand undocumented code, and inflict other costs?

  • They’re afraid to anger their corporate masters. This software needs to go out the door tomorrow. It’s already late. Get it done.
  • They’re afraid to antagonize customers. Yes, I understand, all of these requests are important. We’ll do everything we can to deliver these capabilities.

I’d submit that increased alignment would compel teams to reduce technical debt. Yes, you can push software out the door faster, by incurring technical debt. Congratulations, you’ve just reduced your ability to adjust to unexpected customer issues, because the code is too hard to maintain, and you have less time to devote to the customer. Yes, you can lavish attention on your customer, working hard to give them everything on their gift list. The gods help you if you discover that a lot of that code you’re committed to delivering and maintaining is something that matters only to a few customers, not the larger customer base. The more corners you’ve cut to keep the existing customers happy, the harder it will be to deliver what new customers want.

Technical debt becomes a reason for teams to become even more entrenched in their current fixation on the customer or the organization. The technical debt backlog exists because of the over-eager effort to make someone happy. To preserve their love, you have to clean up those messes for them, so there’s no time for other distractions.

It’s the rare team that can change direction on its own. The larger organization must introduce measures that deflect teams into trajectories that advance towards more than one target. ALM is one way to describe those new trajectories, and to help teams understand the value of following them.


Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>