About a year ago, I started the Agile journey. At the same time, I decided to reread Peter Drucker, the father of modern management. As I read The Essential Drucker, I realized that the principles embodied in the Agile Manifesto sounded like Drucker. I wondered, could Drucker have presaged Agile in the 1950s?
The authors of The Agile Manifesto postulated four principles that put people at the heart of software development. It was a bold, democratizing move that favors people over process or technology. The Manifesto is anchored in the following statements of preference:
Individuals and interactions over Processes and tool
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
In his book, The Practice of Management, Drucker cautions about the misuse of reports and procedures as elements of oversight and control; he wrote:
Reports and procedures are necessary tools. But few tools can be so easily misused, and few can do as much damage…There are three common misuses of reports and procedures. The first is the all too common belief that procedures are instruments of morality…The second misuse is to consider procedures a substitute for judgment…But the most common misuse of reports and procedures is as an instrument of control from above.
I believe that technology organizations should consider Drucker’s wisdom and the principles of the Agile movement when deciding how to manage software projects.
Procedures are neither an instrument of morality nor are they a substitute for good judgment:
Procedures create the opportunity to establish consistent, repeatable processes, which is the basis for efficient project delivery. Imagine the chaos and waste if project managers did not have a set of standard practices or a common language. It would be like reinventing the wheel with each new endeavor.
Processes and procedures should not be treated as if they are moral code. The PMBOK® and similar standards provide a valuable lingua franca and framework for managing and executing projects. Following a methodology or framework is a best practice. However, strict adherence to codified procedures is not an imperative.
Procedures are not a substitute for good judgment. Good process does not make good software, good people do. A values based culture, where the team is empowered and expected to make the right decision, is more effective than one regimented to strict procedures. Nordstrom’s has famously created a value-based, customer-centric culture—return an item and enjoy the experience over a rules-based retailer.
Good process does not make good software, good people do
Agile software development principles embrace self-managed teams with limited process overhead. On agile projects, documentation is minimized because the goal is working software that meets customer needs. Within the scrum room, good judgment is valued over externally imposed procedures. In fact, the team is encouraged to create its own rules.
Reporting should be used to enable the project team rather than be used as a form of external control:
In many organizations, formal project reporting is primarily an instrument of management oversight and control. To be clear, the process of reviewing project status and metrics within the team is a critical component of organizing work and tracking progress. Transferring this information into PowerPoint status presentations or project management information system entries provides limited direct benefit to the project.
Project managers working in large organizations must balance what is required to execute the projects with the enterprise need to oversee its portfolio. At the project level, we should limit the reporting to what is minimally necessary to successfully complete the project. At the enterprise level, we should similarly strive to limit the oversight and control reporting to essential elements.
Drucker’s thoughts on reporting and control are at the heart of the Agile principles of simplicity, communication, and engagement. When integrated project teams work in a collaborative environment, the need for ‘control reporting’ is less because there is full transparency. Even in traditional waterfall projects, regular communication with all stakeholders reduces the need for oversight reporting.
In consulting on an Agile project, I noticed that the team conducted a series of weekly status meetings supported by a large, data intensive PowerPoint deck. In discussing this seeming contradiction, it was clear that while the organization was on the Agile path, they were not ready to fully relinquish the oversight and controls that were part of the broader enterprise culture.
In the 1950s, command and control was the prevailing management practice. Computing was in its infancy and adopted controlled, mass production processes. Against this backdrop, Drucker warned of the pitfalls of putting process and tools before people. Nearly fifty-years later, The Agile Manifesto called for similar change in the software industry—put people and human interaction first.
Did Drucker directly influence the Agilists? We many never know. But we do know that they both believed in the same things.
Sources:
Drucker, Peter F. The Essential Drucker: Selections from the Management Works of Peter F. Drucker. New York: Harper Business, 2001. Print.
Drucker, Peter F. The Practice of Management. New York: Harper & Row, 1954. Print.
“The Agile Manifesto.” Wikipedia. Wikimedia Foundation, n.d. Web. 27 May 2015. http://en.wikipedia.org/wiki/Agile_software_development#The_Agile_Manifesto
“Peter Drucker.” – Wikipedia, the Free Encyclopedia. N.p., n.d. Web. 27 May 2015. http://en.m.wikipedia.org/wiki/Peter_Drucker
Highsmith, Jim. “History: The Agile Manifesto.” History: The Agile Manifesto. N.p., 2001. Web. 30 May 2015. http://agilemanifesto.org/history.html
“Manage Uncertainty with Commander’s Intent.” Harvard Business Review. N.p., 03 Nov. 2010. Web. 29 May 2015. https://hbr.org/2010/11/dont-play-golf-in-a-football-g/
© 2015, Alan Zucker