Agile project management made its entrance in new product development over the last few years over and above software. At the same time, the original method (e.g. Scrum) has been adjusted, sometimes more, sometimes less, to the characteristics of the individual industry and culture of the company. It is not yet foreseeable whether and how the methods will ultimately be established in the development of physical products, services and business models. The development of agile project management seems to be following its own set of rules: arrive quickly at something that functions, test it on users, learn from experience and further develop the methodology.
This progress report describes this type of learning cycle when implementing agile project management in the development of physical products.

In an earlier report, we explained that agile proceedings bring many benefits, especially in an uncertain project. Therefore, agile project management must also be especially good for the early phases of development of innovative products. In the area of software development, the application area of agile methods are primarily in the development phase and beyond. Scrum & Co hardly offer any methodology support in the early phases of analyses and conception.
Six project teams from two companies (one from the area of data and energy transfer and the other, a manufacturer of laboratory equipment) took the challenge together with five is, to utilize principles and tools from the agile methodology briefcase in the early phases (from the idea to the go to development).

The following lessons and insights were learned:

  • As stipulated in the classic Stage-Gate ® System, we worked with interdisciplinary teams. There was always at least one person from development, product management, production technology, and in some projects, someone from purchasing, on the team. The method of practice used in the companies up until then was to first define a market side customer requirement specification book that the technical side would perfect into a functional specification book. Working together with agile “forced” the members of the teams to grapple with the market side as well as the technical aspects of the project intensively. The Innovation Project Canvas tool supported and accelerated this process immensely.
  • The results of the work with the Innovation Project Canvas was used by the project teams to build a project backlog so they were able to prioritise the most important project tasks. The project backlog was made up of three parts:
    • Product Backlog: This contained all relevant aspects of the product (e.g. customer needs, requirements, specifications, etc.). At the beginning of the project, this was practically empty.
    • Risk Management: Here is where all the necessary knowledge needed to be developed (e.g. statements about possible patent violations) and was stored, which would eliminate uncertainties or reduce risks within the project.
    • Parameters: This is where the fundamental decisions made by the team (e.g. minimum quality requirements) as well as demarcations (e.g. focussing on the European market) were kept and, therefore, always in view of the team.
  • Core elements of the agile procedure were carried out in 2-week sprints or cycles.
    • Every sprint was started with a kick-off meeting. Here it would be decided which project members could invest how much time in the project during the 2-week sprint. If a person could only invest less than one day a week in the project, they would not take part in the sprint and were asked to pool the available time in the next sprint.
    • Taking the available resources into account, the project team defined the targets for the sprint. Under the motto “the most important first”, those aspects that would move the project forward the fastest were chosen. For each goal the team also defined the measure of quality that was necessary to achieve the goal (Definition of Done), and who would check if the goal was achieved. The goals were broken down into between 10 and 20 partial results and listed on a physical sprint backlog. Some of the teams constantly used the Kanban system of the sprint backlog while others waited until the sprint review to check it. The perceived usefulness of the Kanban system was limited for all of the teams.
    • An important insight from the first sprint was that those teams that used a common project room and carried out most of the project work in a common project room achieved better results. In order to take advantage of this effect, a few teams reserved specific days (e.g. Tuesday and Thursday) as project days. The rest of the week was used by the team members to go about their daily work or work on other projects. Most of the teams met twice a week for a stand-up meeting to exchange information about the progress of the project or to discuss and solve problems.
    • The results of the sprint were checked in the final sprint review. New results stemming from the activities in the sprints constantly led to new entries in the project backlog. The project backlog is also updated during the sprint review. The project backlog offers a good view of what is coming. It can be used as a physical tool on the wall but not as well for documentation. Some of the project leaders transferred the backlog elements to an excel sheet for the purpose of accurate documentation.
    • At the end of each sprint review, the team reflected on their method of working and thought about how their joint work could be improved and accelerated. During the next sprint the team adapted and/or changed their method of working. This led to the team working faster and improved common work. For example, the use of summarised, parallel joint work recognised in the first sprint was improved in the following sprints.
    • When introducing the method, the Burndown Charts, as a tool, was well received. On the other hand we noticed that using the burndown chart in the early stages was demoralising. The project planning was vague at the beginning of the project and in many cases the technological path wasn’t even known. With regards to the progression of the project, new tasks and activities were added. Result: the chart progression looked less like a burndown and more like a pile-up. This doesn’t mean that an overall project plan was waived. What happened was that the teams were satisfied with a very rough plan.

 

The advantages of the agile method was seen differently by the individual members of the project team: Their reactions were everything from enthusiasm to rejection.

  • Most of the project team members agreed that working closely together in the various disciplines in the early phases of the project made it easier to understand the project goals and facilitated a more direct exchange of information, leading to acceleration. Whether or not this advantage was brought about by the agile method or because of better project organisation was up for debate.
  • Some project team members doubted that the agile method could keep up with the efficiency of an orderly plan – provided the project was carried out in a classic manner and had similar, beneficial parameters to the pilot project.
  • Those project teams that were fully involved with the agile method reported a new, attractive “project feeling”: motivated cooperation and a lot of individual initiative within the team and that it was easier to work in a disciplined manner.

All in all, the experience was deemed as valuable. Most of the project teams were for another pilot application of the agile method in the early phase of a project.

Our insights from this pilot project are:

  • The Agile approach works in the early phase of a new product development. However, not all aspects and instruments from the “Scrum World” are suitable. The focus should be on the following 3 elements during the first steps of agile:
    • At the core of agile work is the tact of the project that is comparable to a heartbeat. Before each tact/sprint the project team thinks about what insights and/or results are best to move the project forward.
    • The team then uses this as the goal for the tact/sprint, depending on the resources available. The team members work together, intensively so that the quality of the result will make it possible to rate the goal as being achieved. This makes for clear orientation and reduces the danger of working too complexly or too superficially.
    • The experience gathered in each sprint gives the project team potential for improving further joint collaborations within the project. Difficulties, discontentment or missing coordination and communication are recognized early on and worked on immediately.
  • We had the experience, from a number of the project teams, that the “Scrum” language was not well received or already being used in other places. Therefore, we would recommend being flexible with the language and not insisting on terms such as “Sprints”, “Project Owner”, “Scrum Master,” etc.
  • The successful implementation of the agile project management in the early phase of new product projects depends on the leadership style of the middle and top management. The project team must be able to move the project forward independently without having to constantly give an account of their work. Otherwise, although the agile tools are being used, the actual agile procedure and its advantages will be prevented.