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.
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.
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.
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.
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.