framework

WHAT IS SCRUM?

Scrum is an agile, incremental development method. With each increment, the team delivers a potentially usable product. Requirement changes can be incorporated into the project in a controlled manner.

The focus is on the self-organization of the team. The Scrum Master supports this to enable trouble-free work.

The development team does not need a project leader. The product owner, as the person responsible for the product, assumes the technical requirements and defines, prioritizes and, if necessary, adapts these. The rules of Scrum contribute to transparency and trouble-free development cycles (sprints).

WHAT IS KANBAN?

STOP START - START FINISHING

Kanban is a procedure that reduces the number of parallel work, the work in progress (WIP), as it goes through a value chain, thus achieving faster turnaround times.

This quickly reveals problems, especially bottlenecks.

Kanban comes from lean production and was known by the use of Toyota. The procedure has since been adapted to software development and organizational processes.

Kanban is a wonderful tool for visualizing personal tasks and processing your own tasks in a structured and focused manner.

COMPARE OF SCRUM & KANBAN

SCRUM

  • Iterations of equal length are required.

  • Team arranges a certain amount of work to be done in the next sprint.

  • Velocity (team speed) = base metric.

  • Teams should be put together cross-functional.

  • Requirements have to be met within a sprint.

  • Burndown charts are used as a metric.

  • Indirect WIP limitation due to the limited amount in the sprint.

  • Optional WIP limitation within a sprint. Estimates are required.

  • No new requirements in the current sprint.

  • Three mandatory roles (Product Owner, Scrum Master, Development Team)

  • Scrum board belongs to the team and will be emptied after each sprint.

KANBAN

  • Iterations are optional.

  • Different cadence for planning, release and process improvement.

  • Commitments are optional.

  • Cycle-time = base metric for planning and process improvement.

  • Expert teams are allowed.

  • Completing the requests takes as long as it takes. There is no requirement for the size of a requirement.

  • No specific chart type is required.

  • Proven charts are CFD (cumulative flow chart) and chart control.

  • Work-in-progress (WIP) is directly limited.

  • Estimates are optional.

  • New requirements within the framework of WIP limitation possible at any time.

  • No prescribed roles

  • Board can be shared by 1-n people and is maintained continuously.

USE OF SCRUM & KANBAN

 

EXTERME PROGRAMMING

XP brings many values ​​and principles that can be found in other agile frameworks such as Scrum, Kanban, etc. The practices help teams deliver efficient and valuable software.

XP contains five values ​​that have proven themselves in the software world: simplicity, communication, feedback, respect, and courage. It focuses on test driven development (TDD), small releases and a team structure that includes the customer.

Many of the rules of this agile method are specifically designed for coding, design, and testing. The planning is e.g. done right before doing. XP pretends to schedule the release at a high level, but always at the beginning of each iteration.

12 PRINCIPLES OF XP

PLANNING

The software features requested by the customer are combined with cost estimates by the developers to determine the most important factors for the software.

SMALL RELEASES

The software is developed in small steps and delivered frequently.

METAPHOR

All team members of an XP team have a common language and descriptions as a guide to development and communication.

SIMPLE DESIGN

The software should provide only the absolutely necessary code for the results desired by the customer at each stage. The intent is not to work for future versions of the product.

TESTING

Tests take place throughout the entire development process right from the start. Developers pre-create the tests and then write the software to meet the test requirements. The customers provide acceptance test at each stage to ensure the desired result.

REFACTORING

XP developers continually improve the software and its architecture throughout the development period rather than waiting until the end to fix bugs and accommodate change requests.

PAIR PROGRAMMING

Each line is written in collaboration with another developer on the same computer.

COLLECTIVE OWNERSHIP

All code belongs to all developers who work on the project. No personally assigned responsibility should slow down the project. If necessary, code is adjusted - and then without delay

CONTINUOUS INTEGRATION

An XP team integrates and builds the software system several times a day and has the same up-to-date software for all development.

40-HOUR WEEK

An XP team does not do excessive overtime to make sure they are all rested, alert and effective.

ON-SITE CUSTOMER

An XP project is managed by the customer, who is available all the time to answer questions, prioritize, and set project requirements.

CODING STANDARD

The developers write code in the same way. This is the basic requirement to work as a pair and to be responsible for the entire code.

FEATURE DRIVEN DEVELOPMENT (FDD)

Feature Driven Development is a helpful model especially for the Product Owner to use the Kano model to determine the characteristics of the features.

However, it is important to work incrementally, i. of all the features to create the minimum and then build up step by step. This ensures that all necessary features are created at the delivery date rather than just a part of it in the best way.