Consider the federal organization. When Peter Drucker studied General Motors in the 1940s, he saw an organization with hundreds of thousands of people that was doing better at the Hseih test than most. The secret Drucker found and documented in Concept of the Corporation was what he called the “federal organization” – breaking the company into business units that are as small as possible, while retaining a central core that provides services. For example, managed hosting services, test environments, processes to acquire and provision software and hardware that actually speed up the delivery process. This is not the same as changing IT to support specialties – the marketing team, accounting and so on – but instead changing the organization to be more agile. That’s a change that could happen at a glacial pace, or require a crisis, as IBM had to do when it created the personal computer division.
[Related: Introducing the scaled agile framework]
Consider culture and values over big bang reboots. So much of what makes agile work – like limiting work in progress and planning in short increments – falls apart completely under the classic management paradigm of pushing work onto teams. Provide coaching and culture, and people might "get it," but a process cannot compensate for bad decisions. As my colleague Michael Bolton likes to point out, "If your find yourself in a hole, your process model isn't going to pick up the shovel."
That brings to mind the work of companies like Leading Agile, detailed in “Comparing scaling frameworks.” Strictly speaking, Leading Agile doesn't offer a "framework." Instead of process and plans, the company focuses on executive coaching, helping drive decisions that could lead to changing the way people think about delivering services.
Let a thousand small teams prosper. In The Principles of Product Development Flow, author Don Reinertsen provided his research on large projects, showing that the percentage of time slipped tends to increase as projects become larger. They also take longer in the first place. A larger percentage of a larger number means a bigger slip. Yet inside of every large, capital project of eight or nine figures there are a dozen smaller projects with a chance of being successful. Organize software development groups as streams of value, given them appropriate-sized problems, and develop a way they can all deploy without requiring staged hardening sprints. Web services is one common way; it seems to work for Amazon.
Using the Lean Management methodology, for instance, every level of the organization can visualize the flow of the work with a board with columns. Every level can talk about the work each day in front of the board, plan work in time-boxes and meet periodically to review performance. Reviewing the differences between boards – at different levels – can cause problems to surface that might otherwise go undetected.
The approaches above are continual improvement approaches. They can start right now. They scale. And they won’t scare the executives whose buy-in is necessary for any evolution to succeed.
Rethinking our examples
The broader tech industry is obsessed with companies like Apple, which takes mostly new ideas and makes them commercial successes. When it comes to scaling agile, we may be better off to look at 3M, the company that was once called Minnesota Mining Company. Yes, the same company that used to make your floppy disks when you were much younger, if you even remember the floppy disk. 3M measures the age of its patents, and has policies in place to create new patents, put resources behind them to make the commercial successes – and abandon the market before it becomes too old.
These teams may be a little bigger than your classic agile "small team"; it takes more than 20 people to run a manufacturing plant. What they do have is a federal organization with divisions, each with a holistic view of the work that can zoom in and zoom up, the ability to respond to change, a focus on customer value and technical excellence.
I don’t mean to overly praise 3M. It does, however, seem to present a compelling argument for what the agile organization might look like. So forget scale. Ask yourself what an agile organization might look like, and how to move in that direction.
Even if it is only an inch or two. Find glory in that inch, take pride in that inch. And let us know how it goes.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.