What's better than Scrum

Project management

Project-related work is steadily increasing in all countries and industries - a trend that has been observed for a long time. The aim is to promote the efficiency and targeted action of employees. As a result of this change, the different approaches in project management are becoming more important. Today, not only are classic methods widespread, but there are also new approaches, including agile project management. Incidentally, the latter is not only applicable in software development projects, even if it originally comes from this area. Agile project management can be transferred to any project that has a certain degree of complexity.

Digitization drives agile project management

The speed of change and the diversity of digital business traffic are leading to an increasing gap between business and IT. Not only the software development business is exposed to an ever faster changing market environment, the business is also confronted with the following requirements:

• Faster changes in the company and the resulting shortened product cycles and time-to-market duration.

• Personalization of products and services such as lot size one and new consumer habits.

• Inevitable technology integration, that is, disruptive and dynamic changes in technological capabilities (skill shift).

• Diverse digital business opportunities based on technologies such as AI and IoT, as well as improved products and services through analytics.

The more uncertain the sector in which a project is carried out, the more difficult it is to plan such a project or to stick to such a plan. However, this is one of the main strengths of agile project management. In order to successfully manage projects in this complex world, which is more than ever characterized by uncertainties and risks, knowledge of agile project management and lean management is required. The challenge here is increasing complexity.

Planning does not become superfluous - on the contrary: it is important. With complex projects, however, it is not possible to act with a big plan. Achieving the project objective requires more frequent and segmented planning, such as a three-week sprint plan. It is not enough for project managers to start the project with an extensive planning phase at the beginning of the project and stick to a plan that cannot be fulfilled. It is not necessary to formulate extensive requirement documents, specifications as well as requirement and functional specifications.

Agile project management is the answer to complexity. To be agile means to be able to react to changes. Agile project management increases the performance of projects and enables quick and efficient implementation (faster delivery of a product), innovation transfer and improvement of scalability (reaction to changed requirements and project orientation).

Scrum and Kanban - agile methods at a glance

Two of the most common agile project management methods are Scrum and Kanban. Both support the principles and values ​​of the agile manifesto. And both methods aim to capture complex challenges with a clear view of the scope, quality and timing of a project and to address them effectively and humanely by being flexible in reacting to changes and having greater control than other methods.

However, these principles and the non-reflective application of the methods alone do not guarantee the success of an agile approach. This is the biggest misunderstanding when using tools for agile product development. Only discipline, communication and a high level of motivation can remove obstacles, avoid waste and lead a project to success. It is the individual project members who fill the framework and design the processes. Agile methods are easy to understand but difficult to master because they are based on a system of components that work together, especially the people who work together on a project.

Scrum and Kanban - similarities:

  • Both methods work according to the pull principle: in the Scrum Framework it is used for sprint planning, in Kanban for the entire board.

  • Scrum and Kanban are both lean and agile.

  • The teams organize themselves.

  • The release plan is optimized in Scrum and Kanban: Scrum uses team velocity for this, Kanban uses lead time.

  • "Limit your WIP" is what it says in Kanban for status transitions. WIP stands for Work In Progress and the request essentially says: Not too much at once. In Scrum, the sprint limits the number of tasks to be done.

  • Both process models rely on releasing deliverable software increments quickly and often.

  • Through transparency, optimization potentials are to be shown and thereby increases in efficiency are to be brought about. In Scrum, this topic is essentially pushed by the Scrum Master; in Kanban, it is driven by the stakeholders and management, provided the bottlenecks are indicated by WIP limits.

Scrum and Kanban - the decisive difference:

No dedicated role is defined in Kanban, but experience shows that the implementation of an agile method without the use of an agile trainer often leads to a dilution and does not lead to the desired success.

The product owner is responsible for the product in Scrum. Kanban does not stipulate who is responsible for defining and prioritizing requirements.

Scrum vs. Kanban - agile methods in comparison

The main difference between the two methods is that Scrum focuses on iterative product development and Kanban on continuous process improvement. With Scrum it is therefore possible to develop the product desired by the customer. With Kanban, the focus in the project is on short lead times and the avoidance of waste. Kanban focuses on uncovering the weak points and bottlenecks in the process. While Scrum works towards a self-contained product increment per sprint and the product is expanded and improved iteration by iteration, Kanban strives to optimize the process flow.

Framework specification

Scrum

Kanban

Servant leadership

Scrum Master

Required roles, initially no roles prescribed

Product responsibility

Product owner

Existing roles are taken over

Teams

3-9 people ("2-pizza rule"), cross-functional, collaborative

no requirements for team size, cross-functional or specialized, pull mechanism

Framework specification

Scrum

Kanban

Timebox

Daily in the "daily standup meeting"

No specifications

exchange

Team retro perspective after every sprint

No specifications (not too long intervals)

Steering (customer & stakeholder)

Review meeting after each sprint

No specifications

Team forecast

Before every sprint in the team's sprint planning

No requirements (replenishment meetings must take place regularly)

Framework specification

Scrum

Kanban

Requirements list

Product backlog

Backlog (kept on board)

Delivery cycle

sprint

Determined by the processing time of the ticket

board

Sprint backlog; a scrum board is optional and is re-equipped with work packages for each sprint

Kanban board (permanent: will only be deleted when the product / project is terminated)

delivery

Potentially Shippable Product Increment

Processed tickets (work packages)

Metrics

Velocity

Lead time, cycle time, WIP

Kanban or Scrum?

Due to the core principle of continuous improvement, Kanban is suitable as a method in a controllable software process. Kanban is often used in support or maintenance teams, where the tasks to be solved are complicated but usually not complex (such as software rollouts or maintenance work). Kanban focuses on process efficiency and productivity gains.

Scrum, on the other hand, focuses on complex software development. Scrum can develop its strengths to the full when it is used in an environment in which a new complex software product or service is to be developed. Scrum is often used in research and development, where an empirical approach is on the agenda. By using Scrum in interdisciplinary teams with short feedback cycles, the right product can be developed with manageable effort. (pg / fm)