Is this a good question to ask?
Some expressed frustration that I was even addressing the question, suggesting in effect that I was introducing a red herring. My response is that since people ask me this question quite often, it does seem appropriate to try to answer it. The web traffic and many retweets and further questions also confirm wide interest.
More importantly, the discussion has the possibility of shedding light on the Agile movement itself and its future. With Apple [AAPL], we have a company that has proven itself to be the most agile large company in history, a big firm that has managed to transform itself from a dying bureaucracy to a hotbed of sustained and astonishing innovation. Yet it’s also a company that doesn’t explicitly adopt the Agile Manifesto. What can we learn from this about either agile or Agile or innovation or the future of organizations? It seems like a potentially fruitful inquiry.
The “halo effect”: Apple is cool: so what?
Another comment (by @massonpj) was: “This is a bit forced: "Hey, agile is cool and Apple is cool, so Apple must be 'agile.'"
I agree that we do need to wary of succumbing to the “Halo Effect” which is pervasive in business writing. A firm makes a lot of money in the marketplace and then writers rush to endow the firm with every kind of virtue and competence. The firm can do no wrong, until its profits falter and suddenly the same writers can see no virtue or competence in the very same firm. Cisco might be seen as an example of the phenomenon, and Google may be heading down this path. Phil Rosenzweig’s interesting book, The Halo Effect gives many fascinating examples.
Inquiring into whether Apple is Agile isn't necessarily committing the sin of the Halo Effect. The discussion has proceeded by examining what we mean by “Agile” and then asking whether Apple has those characteristics. This in turn raises an interesting set of questions: Is Agile a set of predefined processes, or a set of labels that must be used, or a set of values, or a set of operational outcomes, or some combination of the above? In pursuing the analysis, we may learn things both about Agile and about organizations that we hadn’t thought about before.
Is DRI (individual responsibility) compatible with self-organizing teams?
Some questioned whether Apple’s focus on individual responsibility, enshrined in the company acronym, the DRI, or“Directly Responsible Individual,” is compatible with self-organizing teams, a defining element of Scrum and something that I have also emphasized a great deal in radical management.
As it happens, self-organizing teams are not mentioned in the Agile Manifesto itself, which talks only about “individuals and interactions,” “working software,” “customer collaboration,” and “responding to change”.
The Agile supporting principles do include: “The best architectures, requirements, and designs emerge from self-organizing teams.” However, even Scrum, with its intense focus on self-organizing teams, recognizes individual responsibilities in the roles of the Product Owner and the Scrum-master. The issue is not whether some individuals are held accountable where appropriate but rather whether this done in a spirit of blame and fear as in traditional management, or whether it is about creating a setting where small teams can contribute with all their talents and creativity.
Clearly, Apple under Steve Jobs was a mix of the two. The fact that Jobs was the sole and supreme Product Owner, with dictatorial behaviors and attitudes, meant that the work environment was hardly open and free of stress.
As Lashinsky writes in Inside Apple, “’The Apple way is that Steve picked the color he liked and that’s the color,’ the former Apple engineer concluded. ‘He was willing to listen to counterarguments. But if you [were] arguing taste or opinion, it was a losing battle.’ This view of Apple as a kind of consumer-electronics fashion house leaves little hope for a new creative and entrepreneurial genius to rise from the ranks.”
At the same time, it’s useful to read Sachin Agarwal’s interesting article, “8 Management Lessons I Learned Working At Apple”. Agarwal reflected on his experience at Apple and notes that at Apple most of the project teams are small, and driven by the engineers. There was a culture of respect between managers and those doing the work. The employees were given the freedom to own and improve the products, without having to deal with layers of bureaucracy to get approval. The employees were encouraged to grow by getting progressively harder task. It’s not formally Scrum or Agile, but it does sound awfully like the values of Agile and Scrum.
How are teams coordinated?
Another set of questions concerned how all these small teams were coordinated at Apple. Just from reading Inside Apple, it’s not entirely clear, but we can make some educated guesses.
The fact the CEO (Steve Jobs) was the Product Owner (i.e. the person who makes the decisions about what will be worked on to delight the customer) for even minor decisions like picking colors and shapes must have meant that a lot of decisions had to be elevated to the level at the small Executive Team that ran Apple in the Jobs era.
Is that plausible or realistic? Clearly it would only be possible if the Executive Team met very frequently, if the whole management structure was very flat, and if the Executive Team was very decisive and if there was strong alignment around a single vision, and if there were a limited number of products to manage, and if there were few if any middle managers in the normal sense of that phrase. Inside Apple suggests that all of those things were true in the case of Apple in the Jobs era. This view is also supported by the unofficial “organization chart” that Fortune devised which is basically a ring of vice presidents surrounding the Executive Team.
The question of course going forward is how this will change without the Designer-in-Chief, Steve Jobs. We shall have to wait and see.
Can a firm be saved by great teams?
Reading between the lines of some of the comments and questions, I get a sense that there is a deeper mindset issue, that is implicit in the Agile Manifesto and that is still lurking in the various Agile/Scrum/Lean/Kanban software development communities. This is the mindset that if we can just get the teams working really, really well, and create really great workspaces with really energized workers, then everything will work out ok. The teams will produce great products. Customers will love those products. The company will make a lot of money. Everyone will be happy.
The problem with this mindset is that it doesn't work in today’s marketplace. Arguably, the most productive software team--ever—is the legendary Borland’s Quattro Pro team, where extraordinary productivity gains of 5,000 percent were documented: Coplien, J.O. and Harrison, N.B. Organizational Patterns of Agile Software Development. (2004), p. 323—337. Unfortunately, its product was crushed in the marketplace by Microsoft [MSFT]. Similarly, the legendary Scrum team at the Easel Corporation in 1993—the first ever—couldn’t rescue that firm from its market mis-steps. Indeed, Silicon Valley is littered with the wreckage of firms which generated great software but which didn’t find a market.
The point is that the great teams and great products are not enough. In a global marketplace in which the balance of power has shifted from seller to buyer, successful firm must delight its customers, i.e. continuous add new value for the customers and deliver it sooner. This obsession is what characterized Apple in the Jobs from 1997 to 2011 and what made it so truly agile and successful—an important lesson for the Agile/Scrum/Lean/Kanban software development communities.
Adam Lashinsky, Inside Apple: How America's Most Admired--and Secretive--Company Really Works Hachette Book Group.
____________
Follow Steve Denning on Twitter @stevedenning
Want to delight your customers? Training on radical management in Washington DC in February, April & May 2012.
Join the Washington DC Leadership Breakfast–an informal forum for top executives to discuss challenges, trends and solutions
