You’re Doing Agile; So What?

By now you’ve heard about agile. You likely have agile teams in your company. Like most people at software-driven companies, you hope that doing agile will solve your big business and organizational problems: missed commitments, bad quality, lack of visibility, high costs, poor collaboration, stalled innovation (the list goes on).

Unfortunately, many companies find they aren’t getting what they expected from their agile investments. The truth is, doing agile -- especially at the team level -- isn’t at all the same as being an agile business. Frankly, doing agile is not of much real value.

Image: Shutterstock/astephan

It’s not the team's fault. Too often they’re building the wrong things because the company doesn’t have a way to connect strategy and execution. These companies have a big hole, a chasm, right in the middle of their organization. Those that learn how to bridge this chasm can invest in the right things and build them the right way. Most importantly, they can regularly and inexpensively change what they are building to stay ahead of their markets and generate the most value from their development effort. That’s the promise of Lean/agile at scale, of truly becoming an agile business. But how do you get there?

Lost on Scrum Island

When consulting, I ask:

Typical answers focus on number of teams, roles, technologies, processes, estimating story value, sprints lengths, and so on. We can always improve team-level disciplines, but so what? Everybody has Scrum teams. Scrum won’t solve the big problems facing your company. In fact, if all you do is implement these individual Scrum teams, you’re probably worse off than when you were doing waterfall.

Let that sink in, the agile guy said we’re better off doing waterfall. Here’s why: In waterfall, we make decisions up front when we know the least about the work. Experience tells us projects will be late and over budget, but we will know what is built because scope is fixed. Compare this to what I call “Feral Scrum,” optimized teams that deliver software fast. They’re on Scrum Island doing their own thing. Sometimes their only connection to the organization is a single, shared product owner. They are putting a lot of something into production, but we don’t know if what they deliver is what we truly need.

Problem at the top

Let’s put aside that great team-level execution has failed to solve our business problems, and move to how work gets planned and staffed. Here, conversations shift to project charters, business cases, funding and resource approvals. We discuss how often they plan, who’s involved and how much time and effort it takes.

One client told me their annual plan approved 71 projects for their BI teams, and that all 71 were currently active “because managers need to see progress.” Half were holdovers from the previous year. The final blow landed when they told me they expected none of the projects would wrap up this year!

We can solve this WIP problem by giving it the Kanban treatment. Prioritize projects by value to the business, list steps a project must pass, and limit how many can be “work in progress”. Teams only pull new work when current work is done. Presto! Project delivery becomes predictable and we’re only building what the business values most. We’ve solved our problems, right? No.

Becoming an agile business

Markets change every day. New customer demands never stop. Every company’s survival depends on being able to regularly, and inexpensively, change portfolios of projects to stay ahead of new business realities. To shorten the time it takes to select winning ideas and consistently deliver them to customers requires that we solve the disconnect between our strategies and the work of our teams.

The answer lies in how to break down initiatives, keep teams aligned with changing priorities, automate progress reporting, and choose metrics that drive continuous improvement. At the core of this is a quarterly group planning ceremony, Big Room Planning, where teams and leaders align to build shared, realistic release plans everyone can commit to. Now each team’s work stays aligned with strategy changes, and Scrum teams can “look up” to understand the rationale behind what they are building, and how their work contributes to company strategy. But, we need one more thing.

Feed your agile culture

An agile business knows that strategy, capabilities and culture have to be designed together to achieve real organizational change. Culture results from how people interact, so we seek interactions that promote constant learning and improving. Retrospectives and good performance metrics help.

Finally we’re not just doing agile, were being Agile. We’ve got everything necessary to solve our big problems: excellent team execution, prioritization by value, connection from strategy to execution, a platform to support the need for alignment, communication and improvement. We are focused on creating customer value instead of just creating process. We’ve bridged the chasm in our organization and now we can actively steer our company in response to the changes in our markets, truly becoming an agile business.

Doug Dockery is an architect of agile solutions and has served as an Enterprise Agile Coach with extensive experience in leading Agile Transformations. Doug has led transformations and worked directly with companies in the Fortune 100 to adopt true business agility.  At CA Technologies, Doug is the Senior Director of Agile Management and is an author, presenter, and thought-leader at events world-wide.