Raise No More Devils: Improving Organizational Capacity

The title is based on a quote from the 2007 movie, Ghost Rider. Johnny Blaze catches Blackheart, son of Satan, in his apartment, where he is searching for a contract that would cede him the souls of Earth. The two fight briefly. Johnny backs Blackheart up against a wall, and Blackheart admonishes him: “They say raise no more devils than you can lay down. My father raised one too many.”

I consider it to be good advice, generally. The sense is that we ought to be careful about starting things we can’t finish, or starting more things simultaneously than we can handle properly.

Connection with Software Development

Software development teams often find themselves tangled up with more work than they can handle gracefully, if at all. Inundated with requests and desiring to please, teams start work on several items at once in hopes of satisfying multiple stakeholders who all seem to be annoyed at the slow pace of delivery.

The pattern is fractal.

Zoom in from the team to the individual level, and you see individuals trying to do more than they can handle, leading to stress and fatigue which further reduce their capacity in a downward spiral of worsening performance and eroding morale.

Zoom out from the team level to the organizational level, and you see organizations starting more projects than they have the capacity to complete, and agreeing to meet impossible deadlines, in a downward spiral of budget overruns and eroding trust.

The solution doesn’t require any fancy buzzwords or scaling frameworks:

• To the extent feasible, organize people around products or value streams to minimize cross-team dependencies.
• Collaborate with stakeholders to understand the relative priority of the various requests based on objective criteria; don’t assume a requester’s level of emotion or theatrical skill is an indicator of the objective importance of the request to the business.
• Address the highest-priority items first; not necessarily the smallest or the easiest, but the highest priority.
• Limit the number of items in play simultaneously, to reduce context-switching overhead and maintain flow.
• Focus on completing one item at a time rather than juggling many items that are all in an incomplete state until the dealine looms near.
• Begin with the end in mind; start with a clear definition of the desired outcome and steer the work toward that mark through frequent feedback.
• Take the time to repeat questions and clarify information, to maximize clarity and shared understanding.
• Look for commonalities, to help avoid overlapping and incomplete local solutions and to minimize duplicate effort.
• Tie up loose ends; do a completejob of every task, including code clean-up, tests, documentation, regulatory compliance, usability, accessibility, etc.; cutting corners only results in the illusionof speed.

Easier Said Than Done

Conceptually, it’s simple. Practically, it can be challenging.

How do you organize people around products or value streams when you aren’t sure what those are, when leadership has never conceptualized the business in those terms?

How do you assess priorities objectively when you have no measurements in place, and you aren’t too sure what to measure anyway?

How do you address the highest-priority items when there are incentives in place driving you to deliver small things quickly, to “show progress?”

How do you maintain discipline in limiting work in progress when everyone is demanding that you show progress on theirrequest?

How do you focus on getting a single work item finished when every day brings new urgent issues and new requests?

How do you get frequent feedback when stakeholders are overloaded with other work, and don’t have time to work with you; and when there are so many dependencies between technical teams that it’s impractical to deliver incrementally?

How do you make sure everyone has a shared understanding of needs and plans when you will be seen as unintelligent for asking the same questions multiple times?

How do you identify commonalities when all the work in the organization consists of highly localized, independent requests from mid-level and low-level managers whose own performance reviews are based on individual performance within the bounds of their particular group?

How can you take the time to tie up loose ends when there is so much pressure to start the next work item before you’ve had time to properlyfinish the last one?

A Little Help

The so-called “agile scaling frameworks” seem to add administrative overhead, new roles and titles, and procedural “rules” without addressing practical problems. And they are difficult to implement: The recently-released SAFe 4.5 guide is 816 pages long. Kanban training is aimed at helping leadership understand Lean thinking; it helps make problems visible, but does little to solve them. Previous models and frameworks seem to have had similar effects: Total Quality Management, Kaizen, Six Sigma, etc.

What if there were a group of top-drawer professionals with skills spanning the gamut from enterprise strategic planning down to step-by-step code refactoring and software engineering, and a general roadmap for guiding organizations through a series of milestones from wherever they are today to wherever they need to be tomorrow? What if they were pragmatists interested in results, and not married to any given branded framework? What if they helped alleviate the inherent complexity of the situation using an easy-to-understand metaphor such as, perhaps, mountain climbing?

That might be useful.