Categories
Enterprise

Promote Corporate Agility

Corporate Agility

Large companies pursuing agility should ask this question: What do we want from agile, and how long do we want it?

As a company, we sustainably adopt continuous-improvement techniques (iterate, measure, reflect, and adapt) everywhere to rapidly identify market need, explore demand, establish product plans, deliver products and delight customers, and support employees, so we gain greater profitability indefinitely.

Agile practices are surprisingly fragile: you can lose them with a manager resignation and/or a bad hire. Agile drives measurable improvements in companies, and it probably fuels your most intimidating competitors. However, when non-self-improving managers discover the implications of agile—they must iterate, measure and improve, but have few mentors and little support from the organization—they legitimately fear for their careers and livelihood. They may take action, conscious or unconscious, to subtly sabotage agility. If we don’t know how to vet new management hires, particularly in the executive suite, we could hire someone claiming agile experience who ultimately erodes or eliminates much of our hard work to become more agile. I have seen these things happen, even in the face of metrics that show agile brought huge profits and market share improvements.

Refactoring line management jobs or descriptions for agile contributes to agility, but it doesn’t go far enough. If we hire and compensate people in compliance with antiquated role descriptions, we create misalignment between this corporate agility goal and individual behavior. If we use waterfall job descriptions in hiring, we risk hiring people that derail us from this agile goal. However, this doesn’t just apply to line managers; it applies to all positions.

Many of us are painfully aware of structural impediments costing us 10s or 100s of millions per year, which managers could tackle. Yet many, maybe most, of our managers continue to look downward at their employees, thinking that their only role is to help make their employees better. Here, our Scrum training is right: this sort of tactical management becomes the responsibility of the team. Working together, our managers have a much more important role: helping make the company become more effective, providing a rapid escalation path for problems, finding better ways of communicating and producing value. This type of strategic work is hard to measure, hard to motivate, hard to do. Tactical thinkers wonder what the hell agile managers contribute. If we don’t support them, we have a big problem.

We should teach and motivate managers to collaborate and solve systemic problems. Agile managers, of any rank, strategically lead, they don’t tactically “manage”. They delegate tactical decision-making and activities to whole teams (not necessarily “theirs”), with clear, shared goals. They collaborate to meet those goals. Likewise, agile managers focus, together with their peers, to identify and eliminate structural impediments. They collaborate with the skilled and willing, wherever they come from and whatever rank, to get important stuff done.

We do a disservice when we say “agile manager” is an oxymoron, instead we should better understand this role and promote it. We have many enormous structural impediments that are largely invisible to developer Scrum teams, until a team strikes the dependency iceberg, the user-experience delay iceberg, the producing-lots-of-useless code iceberg, the swoop-and-poop iceberg, or the hostile-ignored-team iceberg. Sometimes the developer boat just goes down.

Few companies are agile above the level of developer teams; we see few disciplined agile (iterate, measure, reflect, and adapt) cycles or teams. Most agilists have little visibility on this. We are cogs in this big machine, and it’s hard to take a step back to apply systems thinking to the whole fleet. What war are we trying to win here, and how will we win it?

Here’s the war I want to win: I want large companies to have self-sustained agility. I don’t think it will happen unless the whole company uses systems thinking, and adopts an empirical strategy to assess and refine all processes. So here’s a list of possible practices, all of which are really “Theory Y” practices: Lean, Agile, Beyond Budgeting, etc.

  • Measure the value production and agility of the company, and use those measurements in an double-loop feedback loop to
    • Diagnose problem areas
    • Hypothesize improvements
    • Run organizational experiments
    • Assess outcomes
    • Identify better metrics, throw out bad ones, improve feedback loops
  • Align job descriptions, individual goal setting, performance evaluation and compensation with agile principles:
    • Have job descriptions that make sense for agile development
    • Reward leadership, not management. Reward collaboration, not heroism. Reward systemic impediment removal, not compliance with rigid constraints
    • Transform lone-cowboy specialist heroes into valued instructors
  • Structure corporate product management as agile. Use Enterprise Scrum. Here we  embrace agile ideas to decide what projects to pursue:
    • Limit work-in-progress
    • Measure production in short (1 to 4 month) efforts that deliver user value
    • Put rituals in place that reinforce agility: EBI Ready and Done Criteria, incremental funding, service alignment with Enterprise Backlog, Weekly Standup with everyone relevant invited, etc.
    • Have service providers use the Enterprise Backlog as their default prioritization guide.
  • Establish a thoughtful and scalable curriculum that involves outside and inside trainers, considers on-boarding, formal training in CSM and CSPO, advanced training that brings in a variety of ideas orthodox or heretical. We should respect that the frontier of scaling agility is littered with complexity and problems.
  • Establish coaching priorities, reporting responsibilities, focus attention on the whole company and the areas in the company most needing help.

These bullets I have spewed are mutually-reinforcing. If we do a little on each one, in synchrony, we will likely reap more benefit than putting our eggs in a single basket.

Working together, we can accelerate implementation of sustainable agile practices, and win big in profit, market share and employee happiness.  Sustaining agility in a large company is bigger than any of us.

By Dan Greening

Dan Greening is a serial entrepreneur working on his fourth startup, where he leads implementation of two agile practices, Lean Startup and Scrum. Between the third and fourth startup, he was the lead agile coach for Citrix Online, Skype, Overstock, and other companies. He holds a Ph.D. in Computer Science from UCLA. He is a Certified Enterprise Coach with the Scrum Alliance, and a Scrum@Scale Trainer. He has published innovative work on agile management, parallel processing, and chaotic systems.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.