Categories
Agile organization Parmatur

Agile product development

Agile Product Development success factors.
Agile Product Development success factors.

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 Parmatur 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 begin of the 1990’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 that are useful for agile product development:

  1. 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.
  2. 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.
  3. 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 two things that are useful for agile product development:

  1. Day-to-day management, just-in-time, reduces uncertainty when it comes to planning.
  2. 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 four things that are useful for agile product development:

  1. Reduced uncertainty through iterative planning.
  2. Use teamwork as much as possible.
  3. Just a few roles are necessary.
  4. Importance of 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. Parmatur 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.

Just-in-Time Management. Pulse is based on day-to-day management, just-in-time. We work in temporary teams in which information is shared through work. The shape of the company’s policy and direction is formed dynamically by company management.

Strategies. 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.

Teams & Mission Command. We have few roles, as CEO/site manager, marketing director, development director, program manager, assignment manager and project manager. The program manager is the equivalent of a product owner within Scrum and general in mission command. By using few predefined roles, we make teamwork based on mission command easier to achieve.

Network Organization. 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. Parmatur Pulse is a model for agile product development.

Read more in the book The Principle of Agile Management.

This site uses Akismet to reduce spam. Learn how your comment data is processed.