Kanrum²

Kanrum² – a scalable agile software development concept based on Kanban with Scrum elements

Have you ever experienced this situation? You have meticulously planned a sprint and just started it, when suddenly the sales team or key account manager demands that a certain feature be implemented in this sprint, otherwise the customer will not sign or refuse to pay. Unfortunately, startups in particular often cannot afford to say no. This can become a bad habit.

If the (Scrum) rules are constantly and regularly broken, it can be said that they no longer exist.

Therefore, a set of rules should be defined that retains useful elements of Scrum but also allows the product owner to prioritize requirements and have them implemented quickly, as is possible with Kanban.

However, it is common for multiple teams to be involved, and they may even have to work on the same code base. Coordination and harmonization among these teams are necessary. These also need to be coordinated and harmonized.

Therefore, a new set of rules is required.

Requirements for a New Regulatory Framework

The regulatory framework must meet the following requirements:

• The development process should allow for the introduction of new, urgent requirements in a timely manner and in compliance with established rules.
• It should also enable quick and rule-compliant responses to changing priorities.
• Additionally, the process should include regular presentations.
• The regulatory framework should also address collaboration among multiple teams working on the same code base.

The Idea

The first idea is Scrumban (for several teams):
supplementing Scrum with Kanban elements (see also here https://www.developmentthatpays.com)

1. Visualization in a Kanban board
   – Most Scrum teams that use Jira already follow this practice. ✅
2. No assignment of tickets to developers already in planning
   – To the best of my knowledge, only a small number of Scrum teams implement this practice. ✅
3. Introduction of explicit WIP limits (work-in-progress limits)
   – This is a Kanban construct => NEW!!
4. Stringent, visualized pull principle
   – Most Scrum teams apply this principle implicitly, but usually do not visualize it. However, visualization is necessary for the application of work in progress (WIP) limits. However, visualization is necessary for the application of WIP limits!
5. Explicit prioritization (set order)
   – The development team is solely responsible for prioritization within a Scrum sprint, as the only goal is to achieve completion by the end of the sprint. => Explicit prioritization NEW!!
6. Supplement estimation with explicit refinement, or eventually replace it
   – In Scrum, refinement is the necessary basis for estimation required for capacity planning of the next sprint. The importance is now reversed: refinement is crucial, while estimation is merely a possible indication that the requirement has been detailed enough.
7. Continuous development instead of periodical
   – This is the biggest change compared to Scrum – but it also means that planning does not have to be done strictly periodically any more, but on demand (pull principle).

However, the inclusion of points 5, 6, and 7 may deviate from the Scrum methodology, resulting in a hybrid approach that incorporates Scrum elements into a Kanban framework. This approach could be referred to as > ‘Kanrum‘.

Another challenge is that Scrumban is only ever described for one team, so methods for multi-team Scrum have to be borrowed as well, resulting in what I call > “Kanrum²”.

Kanrum² Team structures

The team composition is as follows:

Per team

• 1 Product Owner
• 4-5 developers
• 1-2 UI/UX experts
• 1-2 QA experts

This is a typical composition that varies depending on the project’s frontend-heavy nature and whether the UI/UX experts also serve as frontend developers.

Cross-team roles in Kanrum²

• One Chief Product Owner (CPO)
• At least one agile coach is necessary to support the processes and moderate cross-team meetings. It is possible that an Agile Coach will oversee multiple teams or even all teams.
• UI/UX experts may work across teams instead of within a single team, depending on the situation. However, this approach may present additional challenges in the processes and is not further explored here.
• This may also apply to the QA experts.

Visualization in a (Jira) Kanban board

The columns

• There is one column for both the ready backlog and the priority list (Next).
• The Kanban board contains a column for each step of the work step and an additional column indicating its completion status.

The swimlanes

• Each team is assigned its own swim lane.
  • With own WIPs (Work in Progress Limits) per column
    • Depending on the team capacity
      • Initial value e.g. 2x number of (active) developers (rounded up)
  • Depending on team capacity, tickets that are longer than the estimated story points* in a column should preferably be processed in pair programming. In some cases, it may even be necessary to move the ticket to the Expedite Swimlane.
  • If tickets that have been flagged are hindering the workflow, they should be moved to the team-ready backlog and reprioritized.
• A cross-team Expedite Swimlane is also available for blocker issues.
  • These issues must be addressed immediately by a developer, regardless of team affiliation. The specific developer or pair of developers responsible for addressing the issue should be agreed upon by the teams at short notice.
  • Other issues should be able to remain in place, as the blocker issues do not count towards the WIP limit in the respective team column.
  • No WIP limits are required for the Blocker Swimlane!

* assuming that one storypoint roughly corresponds to half a person-day

The Kanrum² components

The requirements

1. The Initial Backlog
   All new requirements are created in the initial backlog.
   In the assignment meetings, the requirements are distributed to the teams (and moved to the respective team backlog).
2. The team backlogs
   The team PO selects the next requirements to be refined/sliced from the respective team backlog. Once a requirement has been fully sliced, refined (and possibly estimated), it is considered “ready” and is moved to the team’s ready backlog.
3. The ready backlogs of the individual teams
   The team PO selects the requirements to be prioritized from the requirements of the respective team’s ready backlog and prioritizes them in the priority list.
4. The priority lists (Next column) of the individual teams
   The ticket with the highest priority is always processed next in the priority list.

Design in Progress

The “stations” of the Design In Progress of each team
As part of the refinement, the design requirements are outsourced to a separate ticket and the implementation part is created as one or more separate tickets and marked as “blocked” by the design ticket.

1. Design
   Requirements in the priority list (Next) that require a UI/UX design are processed first by the team’s designer (or the cross-team design team). When the design is complete, the ticket is moved to the “Design done” column.
2. Acceptance testing
   The POs (possibly with stakeholders) take the tickets from the “Design done” column and reprioritize them in the priority list (Next) if there is a need for improvement. Otherwise, close the ticket and prioritize the implementation tickets blocked by this design ticket in the priority list (Next).

A separate swimlane for design is not (absolutely) necessary, as on the one hand only the columns “Ready backlog”, “Next” and “Technical acceptance” can contain both “UIX tickets” and “Non-UIX tickets” and on the other hand can be filtered according to “UIX tickets” or “Everything except UIX tickets”.

In progress

The in-progress “stations” of the individual teams

1. Development
   The developers of the individual teams – if necessary in consultation with the PO – draw the next ticket from the priority list. Once development is complete, the ticket is moved to the “Development done” column.
2. Code Review (includes developer testing)
   For the code review, the tickets are removed from the “Development done” column and moved to the “Code review done” column after a successful review or, if corrections are required, moved back to the “Development” column.
3. Quality assurance (testing)
   The testers pull the tickets from the “Code review done” column and move them, after a successful test, to the “Testing done” column or, if improvements are required, to the priority list (Next) and reprioritize them there with the PO – these tickets are usually prioritized as high as possible and also assigned directly to the original developer.
4. Acceptance testing
   The POs (or stakeholders) take the tickets from the “Testing done” column and move them, after successful acceptance, to the “Technical acceptance done” column or, if improvements are required, to the priority list (Next), where they are reprioritized together with the PO – these tickets are usually prioritized as high as possible and also assigned directly to the original developer.

Deployment

The exact deployment process depends on many factors and is not described further here. In principle, everything that has passed the acceptance tests and landed in ACCEPTANCE-TEST-DONE should be able to be deployed at any time.

The Kanrum² Meetings

The Dailys

In the Dailys, the teams – or the functions across teams – exchange information about the current state of affairs in “stand-up meetings” lasting a maximum of 15 minutes.

• Team-Dailys
  Participants: Developer + UI/UX + QA + Product Owner + Agile Coach/Chief Product Owner
• Funktions-“Dailys”
  (idealerweise jeweils begleitet/moderiert vom Agile Coach) – ggf. nur 1x-2x/Woche
  • UI/UX Dailys
    Participants: UI/UX experts from all teams
  • Developer Dailys
    Participants: at least 1 developer from each team
  • PO Dailys
    Participants: Product Owners incl. CPO
  • possibly Agile-Coaches Daily
    Participants: if there are several Agile Coaches, it is also advisable to hold a “Daily” – possibly only 1x-2x/week

The Process Meetings

1. Backlog Assignment
   Participants: all POs, incl. CPO, one (senior) developer from each team, Agile Coach
   Frequency: On demand (at least weekly)
   Content of the meeting: In the backlog assignment meetings, the issues from the initial backlog are distributed to the team backlogs.
2. Refinement-Meetings (per team)
   Participants: Developer + UI/UX + QA + Product Owner + Agile Coach/Chief Product Owner
   Frequency: On demand – usually triggered by falling below the minimum number of issues in the team-ready backlog or by prioritizing a ticket to high to highest urgency.
   In the refinement meetings, the requirements/stories are checked for feasibility (are the AC requirements fully and completely understood?), and it is also checked whether the stories can still be cut (especially cutting out UI/UX) without violating the “INVEST” rule – and finally estimated.

INVEST: (see also https://www.agilealliance.org/glossary/invest/)
“I” ndependent (of all others) – No dependencies from other stories
“N” egotiable (not a specific contract for features) – Negotiable, meaning that no rigid solution should be prescribed
“V” aluable (or vertical) – The implementation of each user story should in itself represent an increase in the value of the product
“E” stimable (to a good approximation) – The requirements must be so clear that the developers can estimate the effort required for implementation.
“S” mall (so as to fit within an iteration) – Nevertheless, the stories should be completed within a sprint (in Scrum projects) – or in Kanrum² between two presentations if possible.
“T” estable (in principle, even if there isn’t a test for it yet) – Even if it should still be negotiable, sufficiently precise acceptance criteria should still be defined for it, which can be used to check whether the requirements have been implemented or not.

The “Sprint Meetings”

Even if, strictly speaking, there are no longer any sprints, it still makes sense to retain certain periodic meetings from the Scrum process:

1. Presentation
   Participants per team: Developer + Product Owner + Agile Coach/Chief Product Owner + Stakeholders + possibly representatives of the other teams
   Frequency: e.g. 2-weekly – but should not take place less frequently than 4-weekly
   Content: Presentation of all issues / features that have been completed since the last presentation.
   Note: The presentation roughly corresponds to the sprint review in Scrum

Retros

1. Team Retro
   Participants per team: Developer + Product Owner + Agile Coach/Chief Product Owner
   Frequency: 2-weekly – but should not be less than 4-weekly
   Content: Priority should be given to topics that affect cooperation within the team, as well as any external influences that affect or facilitate the work. In the team retro, topics are also to be collected that are to be discussed in the cross-team retro.
   In terms of content, this corresponds to the Scrum retro.
2. PO Retro
   Participants: all POs, incl. CPO + Agile Coach
   Frequency: 2-weekly – but should not be less than 4-weekly
   Content: Similar to the team retrospective, only with regard to the cooperation between the POs.
3. Cross-team retro
   Participants: all POs, incl. CPO, at least one dev team member from each team, agile coach
   Frequency: 2-weekly, if required
   Content: Collection/exchange on team collaboration – especially on cross-team topics from the team and PO retrospectives

Dieser Beitrag ist auch verfügbar auf: German