Agile product development is the ability to impact the market, utilize this impact and to have the ability to make use of new opportunities appearing in the marketplace.
In this article I will define agile product development. I will start with a definition of product development, followed by a short history of the term agile. Finally I’ll describe how the different strands of development of agile converge in Pulse.
The Definition of Product Development
Product development is the transformation of an opportunity on the marketplace into a product in the client’s hands. The opportunity may have been created by the company through analysis, campaigns, technology development, collaboration or other measures.
A company can also make use of an opportunity that has appeared on the marketplace. Product development presupposes the ability to (1) create business models, (2) establish cooperation between clients, suppliers, distributors as well as other stakeholders, and (3) develop and nurture products and production systems.
The History of Agile – War
Agile/agility is a term that came into use among military researchers at the end of the 1970’s to describe the need for more agile military operations. A deciding factor of success in military operations is the ability to acquire information about current events, create an understanding of the situation, choose a plan of action and to implement that plan.
The first military strategist to discuss agility was the Prussian general Carl von Clausewitz in the beginning of the 19th century. After a life-long career in the military he drew the conclusion that a battle contained so much uncertainty that the plans quickly turned obsolete once faced with reality.
His solution was quite unconventional: instead of creating even more intricate plans (which many still presume to do today), he told the soldiers what the ultimate goal was. Clausewitz’s idea was to let the soldiers solve the challenges as they appeared.
It was an idea that a lot of people had trouble accepting. Despite this opposition, this agile philosophy was partially used in the Franco-Prussian War (1870-1871) with great success.
By World War I the Germans had forgotten about this success and once more relied on top-down detailed management with well-known results.
After World War I the Germans introduced what came to be called mission command (auftragstaktik) and control freedom (truppenführung). When these were implemented in the German army they realized the importance of keeping the generals at the front – not to micromanage but to better put what happened on the battlefield in a strategic context.
The German army was initially very successful (1939-1944). However, when the war dragged on the British could make use of their agile abilities on a political level.
Nazi Germany never understood the purpose of democracy. Their political system was based on strong leaders with overlapping responsibilities and where information was power. In the democratic United Kingdom the power came from the work involved in acquiring and sharing information.
From the military we can learn three things.
- There is great insecurity in detailed plans and control needs to be given in small steps as it happens. This step-by-step planning and control is preferably done by the people who have to perform the task.
- There is a need for a “general” at the front who can put events at an operative level in a strategic context. Overall strategic plans must be able to be adjusted as the situation changes.
- Superiority in the battlefield is not enough to win a war. One must also be superior at a political level within the highest leadership.
The History of Agile – Car Manufacturing and Lean
The fact that plans become obsolete the moment they face reality is something that Taiichi Ohno, the product engineer of a car company, realized in the 1950’s.
His solution was to replace top-down planning with day-to-day control out in the production line. He developed a method that made it possible for the operator in the production line to order more materials as they were being used.
This method is known as just-in-time. By working in this manner he decreased the uncertainty involved in planning and management. With just-in-time there is considerable less material in circulation and faults and flaws become more visible.
He complimented the just-in-time principle with jidoka, a method to take control of the problem at the source. With these methods, the operators were given the mandate to identify and solve problems themselves. Just-in-time and jidoka created an almost magical increase in both productivity and quality, which were consequences of reduced uncertainty.
Much later on these principles came to be referred to as lean.
From lean we can learn that day-to-day management, just-in-time, reduces uncertainty when it comes to planning. We can also learn that management and problem solving at the source improve a company’s ability to make decisions.
The History of Agile – IT Projects
In the 1980’s and 1990’s many companies introduced decidedly more bureaucratic models for product development. These models led to a decline in productivity and quality. As early as the 1960’s, researchers demonstrated that bureaucratic models lead to stagnation.
Eventually there was a counter-reaction against the bureaucratic models, particularly among the developers themselves. In the 1990’s Sutherland and Schwaber produced a development model that utilized short planning cycles.
They called their model Scrum. Within Scrum the project manager was removed and instead it’s the team that is in charge of planning and solving problems as they come up. A decisive role in this model is that of the product owner, who has a responsibility to put the project work in a strategic context. In Scrum there are few roles and the model is so simple that it can be explained using a few sentences.
Scrum was inspired by research. One example of this is the article The New New Product Development Game in which the rugby term Scrum is used. Scrum is one of the few models that conforms to the Agile Manifesto which was first published in 2001.
From Scrum we can learn lessons about reduced uncertainty through iterative planning, teamwork, how just a few roles are necessary and the importance of an increased role for the product owner.
The History of Agile – Research in Complexity
Complexity research has helped organization theory explain basic phenomenon. From Edward Lorenz we’ve learned that in complex systems only short-term plans or forecasts are possible.
Lorenz was a meteorologist and studied weather patterns. He discovered that weather forecasts are impossible to make for periods longer than a few days ahead. It’s the same mechanics that make it impossible to plan projects in detail.
Complexity research also shows us how normal abnormal events are. Each abnormal event by itself is rare but put together they form a major part of the managing product development. This is what causes development models and process models such as PROPS to create more problems than they solve.
Complexity research also show that groups in which people work together and share information have a superior ability to solve complex problems. A team can generate more versatility and more inner complexity, which is necessary for understanding increased complexity in the surrounding world.
This explains why mission tactics, teamwork, and other decentralized working methods are better than top-down efforts such as order management and target management.
The History of Agile Product Development – Pulse
Scrum is a model for managing projects. Pulse is a model for managing an organization. At Pulse we’ve built on earlier, pragmatically developed methods. We’ve advanced the development of these methods and complemented them with new methods based on research in complexity.
Pulse is based on day-to-day management, just-in-time. We work in teams in which information is shared through work. The shape of the company’s policy and direction is formed dynamically by company management.
Strategies are formed with the aim of creating an impact on the market, and based on the possibility of new opportunities. This happens through a network of daily “pulse meetings.” The strategies are implemented in the form of projects related to, among others, marketing and R&D.
We have few roles, namely vice-president, marketing director, development director, program director, mission director and Pulse project manager. The program director is the equivalent of a product owner within Scrum and general in mission command.
At Pulse, the network of Pulse meetings determine the organizational structure. Information is shared at Pulse meetings, in workshops and at demonstrations. By using this network of organization, Pulse builds agility. Pulse is a model for agile product development.