Methods

Innovation is always uncertain. Risks, uncertainties and opportunities are not predictable. At the beginning of innovative projects, the initial positions of both content and technology are often blurred and thus provide room for interpretation for all project participants. Our values and principles such as equality, transparency, agility, courage, curiosity and openness, and flexible processes lead to mutual trust, respect, less bureaucratic procedures, and thus to innovation.

Added value of agile methods

  • Short development cycles achieve fast results, which one can react to in turn.
  • Different types of risks and problems are detected early and can be dealt with.
  • Not only will the product be continuously improved, but also the working process.
  • The strategic involvement of specialists in individual phases of the project is made possible.
  • Customers identify with the product due to their frequent involvement in the development process.
  • The final product does not have to be fixed from the outset and can be worked out together.
  • The division of roles creates clear areas of responsibility.
  • A bureaucratic superstructure becomes unnecessary.

Impartation

The convenient methods for a successful collaboration are best learned in practice.

The tool becreate.ch from interspin CreaLab provides an easy access to the application of the methods of design thinking. Here, you can easily create a tailor-made workshow program with different methods. There is also a good introduction to the proposed methods.

The application of agile methods is also best learned in concrete projects. Fluxdock offers the framework for this. The practical example from our work describes the procedure for a one-day workshop, which is the start of a cross-company, agile project: Interdisciplinary Idea Workshop - a practical Fluxdock example.

Sources and links

Agile methods on the web

Agile Manifesto

The Agile Manifesto, written in 2001 by the main initiators of agile ways of working, describes a system of values for a better way to develop software. The manifesto can also be adapted for other disciplines.

Principles behind the Agile Manifesto

Twelve principles that constitute the Agile Manifesto. They include practices on topics such as the production process, handling of change requests, collaboration and communication with customers and within the team and tips on sustainable efficiency improvements.

Why Scrum?
Scrum Values
Scrum Guide

Literature on Agile Methods

"Agiles Coaching - Praxis Handbuch für Scrum Master, Teamleiter und Projektmanager in der agilen Software-Entwicklung", Rachel Davies und Liz Sedley, 2010

"Scrum – use Agile Project Management successfully", Roman Pichler, 2008 dpunkt.verlag GmbH

"Agile Retrospectives – Making Good Teams Great", Esther Derby und Diana Larsen, 2006 The Pragmatic Bookshelf

Scrum Glossary


ROLES

Product Owner (PO)

The Product Owner plays a central role in the project. He is the interface between the customer and the team. He conveys vision, goal and requirements of the project and is responsible for ensuring that the team understands and endorses them. He is responsible for the formulation of the "what" and the "why" (objectives, requirements and reasons for them). He prioritizes the requests, often in consultation with the team.

Team

The team consists of all professionals needed. It realizes the coordinated requirements in accordance with prioritization in demonstrative or productive increments (as part of products, concepts or information in general). The team is responsible for the "how" (e.g. technical solution, software framework, the way) of the implementation of requirements.

Scrum Master (SM)

The Scrum Master designs the optimal process for the project, taking into account all conditions and always in consultation with the Product Owner and the team. He coaches the whole project team, settles any obstacles and optimizes the project process continuously.


WORK FLOW

Sprint

The Sprint is the production cycle of the team with a length of 1 to max. 3 weeks. In the sprint, the team focuses on the implementation of a selection of the highest priority requirements (= Sprint Backlog). The Sprint begins with the Planning. During sprints every day a Daily Scrum is hold. The Sprint ends with the review and is completed by the retrospectiven.

Planning

In the Planning, the Project Owner agrees with the team on the sprint goals. These form in the review at the end of the Sprint the basis for assessing the requirements. The selection of the highest priority requirements and the estimates of the workload to solve them form the Sprint Backlog. The team members decide how they want to implement the demanded requirements and discuss in the Planning the interdependencies and how they organize themselves in the Sprint.

At the end of the Planning all participants know to which sprint goals the team has committed, the form in which the results are to be presented, why the sprint goals are meaningful and which tasks must be fulfilled in order to achieve these goals.

Daily Scrum

The Daily Scrum is a daily meeting of the team with maximum duration of 15 minutes. Each team member answers the following questions:

1. What have I done since the last Daily Scrum?

2. How can I work until the next Daily Scrum?

3. Are there things that hinder me in the execution of my work?

The Daily Scrum is used to coordinate team members among themselves. Necessary consultations will be held with the necessary stakeholders afterwards. The Scrum Master moderates the Daily Scrum and takes care of the elimination of any obstacles.

Review

At the end of each Sprint, the team presents the results in the Review. The individual team members share their knowledge and experiences and present exclusively finished results.

The team is oriented towards the following questions:

1. What have we achieved?

2. What have we not achieved and why not? (factual description of the reasons of non-achievement)

3. What have we learned? (with respect to the product and its development)

The Product Owner checks (ideally with the customer) whether the Sprint results correspond to his requirements. Findings are discussed together and possible amendments can be made as a basis for the next planning in the product backlog in the form of extensions, changes of priorities or by removing elements.

The Review is organized by the team and moderated by the Scrum Master.

Retrospective

In the Retrospective the past work process is considered with the team. In this meeting the team together with the Scrum Master reflects on the process, collaboration in the team and with the Product Owner and other stakeholders. Improvement measures are prioritized and assigned to a responsible (person, team or organization) to be implemented as early as possible.. The findings and improvement measures that affect the team itself will be implemented directly in the next Sprint.

The aim is to shed light on the past Sprint and learn from it in order to make the upcoming Sprint more efficient.

The Retrospective takes place after the Review at the end of each Sprint.

The Scrum Master prepares the Retrospective and moderates it.

The retrospective is based on the following questions:

1. What went well?

2. What have we learned?

3. What do we want to do better next time?

4. Who is responsible for measures of improvement?


ARTIFACTS

Product Backlog

The Product Backlog is the list of requirements of the customer. This list is continuously updated by the Product Owner in close cooperation with the customer, reviewed and re-prioritized. The Product Backlog is the basis for the implementation of the project and describes what is to be implemented by the team. It is not a closed document and changes as the project progresses. At regular intervals, the elements of the Product Backlog are evaluated and re-prioritized. Existing elements can be removed and new ones can be added. High-priority requirements are described in great detail in contrast to low priority requirements and thus serve the team as a basis for creating the Sprint Backlog. Thus the Product Backlog is not a to-do list, which is processed in every case, but provides a pool of requirements that are processed in order of priority, as long as the time or financial resources are available.

In summary, this means:

  • The Product Backlog contains all the requirements of the client with regards to the project target.
  • The requirements are prioritized according to criteria such as ROI, risk and overall importance.
  • Ideally the requirements give information on the “what”, the purpose and its target audience.
  • The Product Backlog is managed by the Product Owner in digital form.

Sprint Backlog

The Sprint Backlog is prepared by the Product Owner in a first version and discussed within the planning with the team. The team complements the individual requirements with specific tasks that lead to fulfill the request. The Sprint Backlog is thus a refinement of the Product Backlog and contains all tasks that are necessary to fulfill the Sprint goals. In the planning only as many tasks are planned as the team can handle, because the team commits to the execution of these requirements).

In summary, this means:

  • The Sprint Backlog is the refinement of the Product Backlog.
  • The Product Owner prepares a first version of the Sprint Backlog for the Planning.
  • The team discusses the tasks in the Sprint Backlog and accomplishes them during the Sprint.

For the organization and the follow-up of tasks from the Sprint Backlog, the team uses a task board (digital or physical).