This content is syndicated from LeadingAnswers: Leadership and Agile Project Management Blog by Mike Griffiths. To view the original post in full, click here.
Forbes ran a nice article a couple of weeks ago on how agile is the next big thing for management, but its unlikely origin in the software industry may hamper its adoption. The article provided some nice analogies:
1) When the British government, in 1714, offered a prize for determining longitude at sea, of £20,000 (£3M in today’s money), a Yorkshire carpenter called John Harrison eventually solved it, but the scientific community refused to believe that a carpenter could have solved the problem that had thwarted the best scientific minds. In 1773, when John was 80 years old, he received an award of £8,750 but not the actual prize. A Yorkshire carpenter was the wrong person to have solved the problem.
2) In 1865, Gregor Mendel, an unknown professor created a theory about gene inheritance after studying pea plants. It answered inheritance issues that had stumped the finest scientific minds. The paper was ignored by the scientific community for the next 35 years until people eventually realized that Mendel had indeed come up with the solution. His theory later became known as Mendel’s Laws of Inheritance. His work had been ignored; a researcher on peas was the wrong person to have created the theory.
3) In 1981, Barry Marshall, a pathologist in Perth, Australia, came up with a bizarre new theory that ulcers were caused by spiral bacteria. No one believed him so in 1984 he drank a batch of spiral bacteria and sure enough developed ulcers. Eventually in 2005 he received a Nobel prize for medicine for his work, but it took that long to be accepted. An unknown pathologist from Perth was the wrong person to have made the discovery.
So then we come to agile; for decades management had struggled to balance execution with innovation. How do we simultaneously get work done yet still drive improvements without one factor stifling the other? Now we know agile methods do a great job of balancing delivery with improvement.
Agile methods also provide a framework for sense-making and managing ambiguity when there are significant gaps in our understanding of requirements, approach, or technology. These uncertainties have a habit of stalling plan-driven approaches that struggle to reach escape velocity from the process of gathering requirements and planning. Agile methods instead choose to build what we know, evaluate, gain consensus on where to go next and iterate to a final solution.
The credibility problem we have is that software people, those weird IT geeks with poor communication skills are the wrong people to have proceduralized a complex communication and collaboration process. It should have been some management professors at the Harvard Business Review or Sloan School of Management at MIT. How can that IT crowd, who some believe have trouble making eye contact and describing an issue without resorting to techy speak, have figured out a way to collaborate and communicate on unique problems with unprecedented solutions?
That is as far as the Forbes article
goes, and it is a great read that also recommends Mark Addleson’s “Beyond Management: Taking Charge at Work
“ book as one of the few non-IT books to recognize the benefits of agile.
Of course if we go digging into the origin of agile we do actually find some of those fancy HBR articles. Scrum for instance has its roots in the 1986 HBR paper “The New New Product Development Game
” and my work on DSDM was influenced by Enid Mumford from UMIST. However it did get me thinking about the issue and reminded me of Toyota after WWII and how “Necessity is the mother of invention”.
Faced with few resources after the war, Toyota had to figure out a whole new way of making cars if they were to compete with the West. If they had capacity to build vast stockpiles of parts, then lean manufacturing may never have happened. I feel a parallel with agile methods.
Software projects populated by a majority of analytical engineers needed to communicate about a product that was invisible, intangible, and liable to change. Had software been easy to reference and stable then agile methods may never have happened because we could have got by with methods resembling physical design and manufacturing processes.
Yet, faced with the high variability of evolving requirements and technologies, an incremental approach of building something, getting some feedback and moving from there was created to overcome the gulfs of understanding that exists between stakeholders. Through lists and feedback loops, the challenges of dealing with changing priorities and incomplete specifications were solved. We don’t need to know everything right now; we just need to know enough to move to a better viewpoint.
The fact remains though, that software will be viewed by many as an unlikely source for new ways to manage the knowledge worker. Yet history repeats, and just as companies started touring Toyota plants to learn about the TPS, I am aware of several companies that have had business folks reusing their Kanban boards and stand-up meeting approach.
What do you think? Is the software world the obvious place for new collaboration models to emerge, is there a Sinatra effect “if it works there it will work any where”? Have you had the business copying your agile methods? I’d like to hear from you.