Knowledge management is controlling the transfer, distribution, and availability of knowledge. Traditionally, knowledge management processes are predefined e.g. it is laid out in detail which document template, data structure, system, or work flow steps have to be used in order to manage knowledge. But knowledge management itself is complex. It is simply not possible to predefine the typical flow of work in knowledge intensive processes in advance. So rather than trying to determine the procedures it is more promising to analyze which factors can be used in order to control the outcome of the knowledge management process. By respecting the lean knowledge management principles, developed and first presented within this book, any manager can control the success of knowledge management in a lean software project any time. Enterprise 2.0 and Web 2.0 technologies perfectly support the lean knowledge management principles, and far better than any traditional approach, based on text processors, presentation software, spreadsheets, and E-Mail can do. Together, the lean knowledge management principles and Enterprise 2.0 form a new approach to knowledge management, which delivers value that can not be reached otherwise.

Chapter 2.1.2, A Lean Software Development Method: Scrum: Scrum is an agile software project management method, which emphasizes iterative development. Because of its simplicity and focus Scrum has a proven success record. In his book Agile Project Management with Scrum Ken Schwaber presents a compilation of case studies where Scrum has helped to deal with critical situations in software projects. E.g. Schwaber describes the following situation at Service 1st: Service 1st is a development organization which delivered a new release of its software every six months. The last two months of each development cycle meant very hard work for everybody at the company. At the end of the cycle the staff was typically total exhausted and the delivered software was buggy. The staff needed a couple of weeks to recover from the last development cycle. This happened even though Service 1st planned each release in advance in detail. The work was divided into small tasks with little dependencies. Developers where told to work only on their tasks until the release was finished. Consequently required interaction between developers was very limited which was thought to help developers concentrating on their job. But as a consequence developers felt isolated, and got little feedback about the total status of the next release, about what was important and what could be neglected. Furthermore, it turned out that the project was so complex that the project plan was obsolete as soon as work started. Nevertheless people where told to work on their assignments. When the next delivery date approached management finally gave up the plan and rigid control. The staff then tried to make up for the things that weren’t completed within the first months. This situation where detailed and sophisticated planning failed was finally solved by applying Scrum, which principles and rules are explained in the following: The fundamental principle of Scrum is the concept of empirical process modeling. Empirical process modeling is used in situations where a process is complex, not understood, and the fundamental laws responsible for its behavior are unknown. Since an attempt to model such systems is not likely to deliver any useful results, a process is then treated like a black box and only its reaction to input is identified. Scrum treats software development like a black box. That is, Scrum does not try to model the processes involved when software is developed. It rather focuses on controlling this complex process. A Scrum project starts by compiling the product backlog. The product backlog lists the desired features of a software system, ordered by priority (business value). The product owner (customer) is responsible for the contents and prioritization of the product backlog. The product owner presents the product backlog to the team, starting with the top requirement in the Sprint planning meeting. The Sprint planning meeting is held before each development cycle (a Sprint) and is time boxed to a maximum of eight hours. A Sprint is typically a period of 30 consecutive days. All work in a Scrum project is done in Sprints. During the Sprint planning meeting the team may ask questions about the items listed in the product backlog and make suggestions on further items to be added. After the team feels it has fully understood the requirements it decides which items can be completed during the next Sprint. The team commits itself to deliver the selected functionality at the end of the Sprint and creates a Sprint backlog, which contains the development tasks planned for the fulfillment of the requirements and assignments of these tasks to developers. During the Sprint the team meets every day in a 15 minute meeting, the Daily Scrum. The goal is to synchronize work of the team members. Each team member has to answer three questions: What do you have done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? What impediments stand in the way of you meeting your commitments to this Sprint and this project?”. At the end of each Sprint the team presents in an informal Sprint review meeting the functionality developed to the product owner. The goal of the meeting is that the product owner and the team collaborate and define what the team should do next. This meeting is of significant importance for both customer and the development team. It offers a platform for feedback, information and expectation exchange. After the Sprint review meeting, the team gathers for a Sprint retrospective meeting. Here the team discusses how it can change its practices in the future – within the rules of Scrum – in order to be more effective. The functionality delivered at the end of a Sprint has to be complete. Complete means in this respect, that no more additional work is left to do. E.g. a function has to be tested to be complete. Anything that is not complete will not be presented at the Sprint review meeting and is not considered to be done. This way Scrum assures that the customer is not tricked by presenting half finished functionality and the team does not pile up unfinished tasks. Through the continuous inspection of results (daily) by those who actually work on the product Scrum assures that any problem will be visible very quickly. Since the team is responsible for delivering results and has the power as well as the knowledge to adapt further proceeding itself, problems are addressed immediately. The customer is expected to review the results of the team every thirty days. He can rely on the fact that each time complete features are delivered. At this point he can also set new priorities according to his business needs. Because of the direct, face to face interaction between customer and developers it is assured that no knowledge or information is lost through intermediaries, be it people or documents. Scrum fulfills most of the lean software development principles. It eliminates waste in terms of extra processes, because the process itself is very simple and the contact between developers and customer is intense and direct. Through the daily Scrum meetings and the review meetings learning is amplified. The team has constant feedback. Scrum is an iterative process and thereby ideal for learning. Scrum delivers results quickly and implements a simple pull system. Scrum empowers the team and the team itself is responsible for organizing its work. Scrum delivers flexibility and simplicity in planning, due to the short development cycles. Scrum introduces few and simple rules and demands strict adherence to those rules. For example, stakeholders who are interested in project may attend Daily Scrum meetings, but are not allowed to talk. Developers who do not follow the rules of the Daily Scrum are to be removed from the development team. Scrum does not allow extending the time boxes defined for the different meetings. Scrum itself introduces only three artifacts: the product backlog, the sprint backlog and a burndown chart. The burndown chart is used to measure the actual development speed of the team and estimate the final delivery of a software system which has to be developed in multiple sprints. It can also be used to measure if requirements keep on piling up. The lean software development principles and the agile software development method Scrum so far did not introduce a complex set of different documents to be managed. Lean software development in particular discourages the creation of documentation if it does not directly add value for the customer. Since most communication and collaboration is done face to face one might question whether there is a chance for knowledge management or technology to manage documentation in a lean environment. The next section explains how knowledge management can be successful in a lean environment.

• Wissensmanagement

• Softwareentwicklung

• Lean Knowledge Management

• Enterprise 2.0

• Lean Software Development

• Web 2.0

• Collaboration technology

• Software

Frederik Dahlke, Diplom-Informatiker der Medizin, MBA, hat als Software-Entwickler und Projektleiter in kleinen, kreativen und dynamischen Unternehmen wie auch in deutschen Großkonzernen gearbeitet und dabei Erfahrungen mit ganz verschiedenen Software-Entwicklungsmethoden gesammelt. Derzeit arbeitet er als Teamleiter in einem großen deutschen Versicherungsunternehmen.