Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Can agile scale and does it matter?

Matthew Heusser | Jan. 20, 2016
Most of the literature on scaling addresses overcoming objections and how best to do it. Matthew Heusser posits that ‘Does agile scale?’ is simply asking the wrong question.

Ultimately, though, it’s another example of a small team out performing a large team. Even after the success of Project Eagle, the members of the project mostly scattered shortly after it shipped. Tom West was transferred to Japan, a move he referred to as "effectively fired." After saving the company – not to mention the PR coup of the book itself – Data General couldn’t exactly fire him; he was promoted to research roles for technology that was never commercialized (and to sign deals and trade show work), retiring as Chief Technologist in 1998. 

Project Eagle is a story about de-scaling – of doing with a dozen people what couldn’t be done with 500. The point is that ignoring the system and human forces at play in an agile transition is to ignore history and human nature. In order for a change to succeed, people need to see a personal win. 

Moving forward 

If "that won't scale" is a smoke screen, then one thing we can do is ignore it. Here are a few quick ways to improve the large organization without using the “S” word.

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. 

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. 


Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.