May 082012
 

Big Agile is “agile as far as the eye can see.” It is not “one Big Agile organization.” The distinction becomes clear when you consider the context of size: team versus whole organization. While it is certainly possible, and desirable, for a company as a whole to be influenced by agile practices and principles, that doesn’t mean that agile alone can make a whole company move more quickly and easily.

Agile, as both a theory of management and of software engineering, is tuned very well for one to several teams of individuals working closely together. Beyond that scale, agile alone won’t address all organizational challenges — no agile transformation initiative alone could do so. Solving larger-scale problems will require other management and engineering methods, some of which I discuss below.

When companies grow beyond a handful of individuals or teams, many changes will affect the organization of work and people. One of the first results of large scale is decreased information sharing, both across teams and for individuals joining existing teams. At small scale, and for a limited period of time, a team can organically “remember” its own history. Beyond that small scale, though, organizations need to promote mechanisms that encourage learning and sharing across the organization.

Mentoring

Today’s organizations are heavily focused on knowledge work — the creation and application of knowledge. It is truly the people that are the most valuable resources. Learning can’t be rushed or accomplished in a quick orientation. The 10,000-Hour Rule says that it takes approximately 10,000 hours of deliberate practice to master a skill. That is about five years of working full time at something in an environment where feedback and progress can occur.

Mentoring is a mechanism for long-term leadership and growth. It encourages learning and transfer of knowledge within and between parts of an organization. Mentoring is used extensively in Japanese management, and it is the foundation of craft and artisan learning. In such organizations, everyone has a mentor who assists and actively guides them.

Value Stream

Beyond the challenges of sharing information effectively, organizations at scale frequently structure into functional silos. This is often the result of focusing on efficiencies of scale in the attempt to keep individuals fully utilized and working on the most appropriate tasks. This functional efficiency comes at the cost of cycle time and responsiveness, though, and it doesn’t account for the cost-of-delay economic tradeoff.

Value stream-based organizations will optimize for the flow, and reduced cycle time, of valuable product features. Instead of trying to maximize efficiency of any one function, this approach measures the whole system while trying to reduce total time to delivery. In this method of managing work, deep queues of work don’t exist to cause significant delay.

Aligning toward the customer and stream of value promotes another benefit for individuals and teams: it is easier to define a vision and more motivating for people to work toward that vision when they can connect themselves with delivering actual value to real customers.

Risk Management

Planning work at scale involves committing resources with energy and momentum behind them, often with a fairly detailed budget for a fiscal year or more. This commitment creates an inertia that is a particular challenge for agile teams, which by definition assume the future is going to change, yet are pressured by a static plan.

Risk management can be applied during yearly planning cycles to projects and technical investments alike. Assuming “economics is an exchange of risk and opportunity,” we can conclude that budgeting and financial planning activities should account for the temporal nature of both risk and opportunity.

At smaller scales, risk management can be as simple as creating what-if scenarios, but as investment and commitment scale, so too should risk management. Such topics as technical debt, new or old technologies, competitive landscape, and so on, should all be represented in the planning cycles to mitigate the risks posed by the unknown. It may be very appropriate to take a risk, but it is never appropriate to forget about the facts — your economic outlook depends upon it.

Real Options Theory

In addition to avoiding or mitigating risks, deferring the planning or execution of work until the appropriate time is a planning option that can be used effectively at any scale. Real options theory holds that options have value, and options expire. Never commit early unless you know why.

Options thinking encourages us to delay commitment instead of trying to lock things down as soon as possible. This delay improves our position by giving us time to acquire more information and, when it’s time, make a better decision. This style of planning blends well with agile teams: both the decision making process and execution evolve together over time.

Evidence-Based Management

Finally, in a large-scale environment where it’s all too easy to be less connected with customers, colleagues, and other teams, it is even more important to pursue empirical data of what is truly needed and actually happening.

Evidence-based management is the “conscientious, explicit, and judicious use of current best evidence in making decisions.” There is a long pedigree of methods based on this idea:

  • W. Edwards Deming taught using data to make decisions in TQM.
  • The Toyota/Lean process has both “go to the source” (the Japanese word gemba means “source,” or where the work is actually being done) and data-driven continuous improvement toward target conditions.
  • OODA/maneuver warfare teaches both gathering information and making decisions with imperfect information. (John Boyd defined the OODA [Observe, Orient, Decide, Act] loop for fighter pilots while a member of the US Air Force. It is now a theoretical basis used in maneuver warfare.)
  • The Lean Startup method is strongly focused on growing knowledge through experiments.

This is the scientific method applied to business and management: have an idea, experiment to prove it out, then either alter the idea or invest in it. Agile teams are very good at doing exactly this sort of experimentation and changing direction based on the results. Overly lengthy and detailed planning horizons or “hope-based” management (which skips right from idea to investment, skipping over any real validation) often leads to death march projects.

Discussion

  4 Responses to “Beyond Big Agile: Theories of Management”

  1. John, excellent article.
    The only area I was hoping for that was not mentioned is the close of the circle between agile and process orientated IT. Agile is great to capture low hanging fruit and time to market, but on the other hand you then have an IT department where everything is about the reduction of costs and that is not an agile domain following the old saying cost, speed and quality – you can only have two out of three. So the area where most pain occurs is in transition from speed and quality (agile) to cost and quality (IT operations). I hope to see that in a later article.

  2. avatar

    Interesting article! I think you may be confusing Agile and specific frameworks like Scrum. Scrum or (insert term here) are very specific practices that have been successful in the messiness that typically constitutes a project in-flight. Agile is a mindset and applicable to a broad spectrum of organizational effort and as such is quite scalable beyond the small, collocated team recommended for framework practices.

  3. Hi John,

    Thanks for this article, but I wished to get a bit more.

    Perhaps I’m wrong, but it sounds that our article is made from developers perspective.
    In large scale organization testing “Lean Management” all these topics have been tested +/- correctly.
    At Governance level:
    – decision are taken on evidence (+/-) and audited by external providers (representing stakeholders interests)
    – real options are +/- used with BSC (!)
    – Risk management is the guideline
    – VSM is badly performed top-down (missing Gemba)
    – Mentoring should be

    Agile is for every layers of the organization also if it’s globally distributed. Organization have understood that the governance should support a system based organization skeleton: Lean, Hoshin Kanri, Beyond Budgeting, etc…

    We can’t reduce agile as Software and Engineering. It’s giving to organization the feeling that the whole structure is moving to a certain goal. Agile is the glue to federate the behavior of orga people at is linked to “corporate social responsibility”.

    New challenges in Agile transformation is to reduce the gap between back office and front office in order to increase wealth.

    Then new questions are emerging: how can I get office people (accountants, assistants, trainees…) into the agile dynamic?

    My reaction on “Agile is not possible everywhere” is try it.

    Thanks again

    Pierre
    Scrum/Lean Coach
    Agile Transition Advisor

  4. Hi john,
    Interesting article!

    What about people/team management/leadership aspects? what you think about the radical management way (http://www.stevedenning.com/Radical-Management/default.aspx) ?

    About the 0000-hour-rule ( http://blog.zintro.com/2012/08/10/10000-hour-rule-malcolm-gladwells-10000-hours-of-practice-theory-from-outliers-visualized/) from my experiences i use a gamification approach (improve my practices ny gaming).
    In particular, use games forthe risk management (http://leadinganswers.typepad.com/leading_answers/2012/08/agile-2012-conference-downloads.html) or for real options

    best regards

    .

 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>

(required)

(required)