Agile Insights from Reengineering the Corporation: 1993

A few days ago, I was reading the book Reengineering the Corporation: A Manifesto for Business Revolution written by Michael Hammer and James Champy, published in 1993. At the time, the book presented a revolutionary idea for business transformation and the creation of process-oriented organizations. However, today the content is not new, and almost all organizations and managers are familiar with such an approach. Nevertheless, there are still valuable lessons to be learned from this book.

One of the most impactful lessons from the book is the emphasis on the Reengineering Team. This concept, as outlined by Hammer and Champy, provides foundational ideas that resonate with modern management methodologies, particularly Scrum. By delving into this section, it’s apparent that the early seeds of agile thinking were present, emphasizing teamwork, iteration, and adaptability. The parallels between reengineering teams and Scrum teams are striking, indicating that many principles of agile were already being considered in the early 90s, even if not fully formalized into the frameworks we use today.

In the context of reengineering, the focus on small, empowered teams is crucial. These teams are tasked with not just minor improvements, but complete overhauls of business processes. The ability to innovate, adapt, and execute radical changes is a core requirement. This mirrors the agile philosophy where cross-functional teams are empowered to make decisions and drive projects forward in iterative cycles. The iterative nature of reengineering, as described in the book, is another key similarity with Scrum. Both approaches recognize that planning and execution must go hand-in-hand, with constant feedback and adjustments along the way. This iterative process is essential for navigating the complexities and uncertainties inherent in major transformations.

I have included a relevant section from the book below, which relates to agile methodologies:

Key Excerpt from Reengineering the Corporation

The actual work of reengineering—the heavy lifting—is the job of the reengineering team members. These are the people who must produce the ideas and the plans and who are often then asked to turn them into realities. These are the people who actually reinvent the business. A small point before we dive into who these people are: No team can reengineer more than one process at a time, which means that a company reengineering more than one process will have more than one reengineering team at work. What we are about to say applies to each of them. Notice, we call these groups “teams,” not committees. To function as a team they should be small—between five and ten people. Each team will have two kinds of people on it, insiders and outsiders. We define insiders as people who currently work inside the process undergoing reengineering. They come from the various functions involved in the process. They know the process, or at least the parts of it that they encounter in their jobs. But knowing the existing process and how the company currently performs it is a double-edged sword. Intimate knowledge of the existing process will help the team find its flaws and trace the sources of its performance problems.

Reengineering teams must be largely self-directed. The process owner is their client, not their boss, and the system that measures and rewards team performance should use as its principal criterion the team’s progress toward its target. Moreover, team performance should be the single most important measure of individual member achievement. To function as a team, members need to work together in one place, which is not as easy as it sounds.

A reengineering team must feel comfortable with ambiguity. Team members must expect to make mistakes and to learn from them. People not capable of working this way do not belong on the team.

Conventional organizations are analytic and detail-oriented in their problem solving; they place a high premium on finding the right answer the first time. They enshrine what we call the “endless planning, flawless execution” model of problem solving, in which a lengthy period of analysis leads to a plan so perfect that any fool could supposedly carry it out. Reengineering, in contrast, requires the team to go through an iterative learning process as it invents a new way of performing work. Reengineering team members will have to unlearn the traditional problem-solving style, a difficult adjustment for some.