The right Balance

In simplified terms, there are two dimension that drive the efficiency of an agile business:

• Latency: the speed of response to factors/events
• Ambiguity: the level of certainty, confidence in understanding these factors/events (cause, effect)

Examining this along the popular "quadrant" approach of analyzing business, let's consider the following points:

Red Square:

A business with a fast response rate ("low latency") to events of uncertain understanding ("high ambiguity"), tend to be perceived more on the "chaotic" side.

Blue Square:

Businesses which take their time to respond ("high latency") to well understood events ("low ambiguity") are not particularly effecient and may come across as "bureaucratic".

Green Square:

When the overall business environment, in terms of markets and operations is rather stable ("low ambiguity"), the business can afford moving quickly ("low latency") in response to a well understood environment. The benefit is a "efficient" performance (and typically a high maturity level).

Yellow Square:

When business opportunity, or market dynamics (e.g. competitive landscape) cause a high level of uncertainty ("high ambiguity") it might be prudent to invest more time in understanding the risks and benefits of responses to events ("high latency" in response). The benefit is risk mitigation, but must be balanced against lost opportunity cost.

So far common sense business wisdom. But not so commonly seen in when applying "agile" practices to projects, development, and business intelligence.

You can use these two simple dimensions to quickly (agile) gauge the risk & estimate effort of your initiatives, and weigh the cost/benefit implications.

Organizational Agility

There are two points I am trying to make today:

1. Knowledge Workers need Autonomy
2. Agility and Micro-Management don't belong together

What is the difference between a manager and a leader? The manager gives orders, the leader inspires to follow.

In a highly dynamic business, like startup companies, agility is paramount, on every level. Not on a project or development methodology level, but all throughout the organization. It has to be an intrinsic part of the organizational culture, since top-down indoctrination would cost too much latency.

But Agility does not justify chaos. Speed yes, but not at the expense of applying intelligence and common sense, nor not being held accountable for acceptable results.

Knowledge Workers need Autonomy.

(see "Thinking for a Living", by Thomas H. Davenport)

There is a big difference between task-orientation and goal-orientation.

Often people confuse task-orientation with process-orientation. And agile-cultured folks tend to be allergic to "process", rightfully so. Task focused work, in my mind, is even worse than process. Because process focus implies that at least someone spent some thought on how to do things, even if that may be out of date or not always applicable. 

Task delegation without much regard for the higher purpose of the business, the value proposition of the work, has a tendency to create chaos, and often misses the goal. Yes, I hear you Scrumsters, "but we have Planning sessions". Why would we have to plan tasks, why not goals (on a value-added grain)? 

I understand that tasks are intended to track progress on an atomic level. But what we really should track is progress toward a goal, not of a task. In an agile business, a team lead should not have to track things at the task level. That's so outdated in the knowledge-worker age! And those are often the managers who then "hold accountable" their individual contributors (IC) for the high-level goals, that the very manager prevents them from addressing, to to constraining the ICs autonomy (by clobbering them with tasks). 

The accountability focus on tasks invites micro-management. And that is not conducive of the kind of flexibility required in an agile business. Why do you hire smart people, when you end up telling them how to do their job anyway?

If a development supervisor, project lead, or product owner feels they need to task-delegate, because they don't see their subordinates do exactly what the team lead has in mind, then the superior is not a goal-oriented leader, but a manager of tasks. They cause a trust problem on both ends. The superior doesn't trust their troops' capabilities and goodwill, and the ICs don't trust the superior's leadership competence. 

Agility and Micro-Management do not belong together!

(Bernd Durrwachter, 2011)

What evolved out of growing pain...

I can't count how many projects, teams, organizations I have been involved with that claimed to be "agile", or even use a particular methodology, like "scrum". Yet, as a person with common sense, I just did not see the premise, the value proposition of the agile spirit fulfilled by what these places did in name only.

It seems that the best learnings are from practical experience. And this is what I aim to capture in this series. Lessons learned in the streets, so to speak.

Please join me in the journey of discovering what works, and what doesn't.