Scrumban

Revision as of 12:06, 20 February 2021

draft

Abstract

Scrumban is a project management framework, mainly used by software development teams. It is a relatively new tool which is still in a development stage. It is essentially an improved version of Scrum, which maintains its fundamental characteristics and adds Kanban principles. Some of these principles are pull system, workflow, standard work, performance metrics and continuous improvement. Contrary to popular belief, Scrumban is not exactly a mix between Scrum and Kanban, but a pathway starting at Scrum and ending at a more evolved development framework.

The idea was first introduced by Corey Ladas, a pioneer methodologist in the area of software development, who published in 2009 the book “[[Scrumban: Essays on Kanban Systems for Lean Software Development]]”. Corey Ladas defined Scrumban as a transition method for teams using Scrum. One of its most important features is that it can be implemented at any level of an organisation. Scrumban arises from some limitations detected at Scrum throughout the years and feedback from practical experience.

Ken Schwaber, co-founder of Scrum, publicly made the following statement: “I estimate that 3 out of 4 organisations using Scrum will not obtain the expected benefits out of the framework. (…) Scrum exposes the inefficiencies or dysfunctions within the product development practices at an organisation. The intention of Scrum is to make them visible in order to solve them, but unfortunately many organisations change Scrum to adapt to those inefficiencies instead of solving them.”

Mike Cohn, an Agile/Scrum community leader, also criticized Scrum teams for not being focused on finding innovative solutions to the challenges they face. Cohn was not critical at the Scrum framework itself, but at the increasing mentality among practitioners, which he considers prioritizes a safe approach for completing the tasks rather than promoting innovation.

Scrumban arose with the goal of overcoming weaknesess of Scrum, in order to transform it to a more profitable framework, combining thebest of Agile and Lean methods.

Main idea

Brief introduction to Scrum

Scrum is the most well-known among all software development frameworks. Teams using Scrum work in 1-to-4-week periods or cycles, called sprints [1]. These periods last for 2 weeks in most of the cases. Individuals at teams have different roles, which are the Scrum Master, Product Owner and Development Team [2]. Each sprint begins with a Sprint Planning Meeting arranged by the Scrum Master, to which all members of the team are called [3]. Other stakeholders may also be part of the meetings. All participants select items of high priority from the Product Backlog, a list with tasks or pieces of work assigned to the team. The Development Team oversees completing those assessments within the duration of the sprint. The selected item is called Sprint Backlog. All team members reunite at Daily Scrums or short meetings [5]. One of the main goals of Scrum is to make each sprint more effective and effective than the previous one [6, 7]. Once a sprint ends, completed items are delivered and non-completed items are returned to the Product Backlog.

Brief introduction to Kanban

Kanban is a continuous process, unlike sprints in Scrum. It is a set of principles applicable to a broad diversity of situations. Roles at a Kanban process in a project management context could be an Agile Coach, a Product Owner and the Development Team. In this case, items are pulled directly from Product Backlog. Each of the columns from the board has a strict limit of Work In Progress (WIP). This is to ensure items are pulled throughout columns within the minimum time. A column with empty spots is an indicator to pull items from the previous column. Like in Scrum, daily meetings are held, called Daily Standups, where all project members are present. In a Kanban context, products are delivered as soon as they are done. Continuous revisions are made to guarantee the process gets more efficient and effective in order to improve the quality of the results. The results of the work delivered by the team are always subject to improvement, no matter how good they still are.

Implementation of Scrumban in teams working with Scrum

Kickstar process activities

1. Introductory remarks. Two important factors all team members should know before beginning:

-The transition to Scrumban does not mean a significant change in team roles or current responsibilities. It is important to specify this point in order to avoid barriers caused by fear to change.

-Every team member must understand and agree with his or her purpose at the team.

2. Stakeholder evaluation. Service orientation is a relevant factor in Scrumban framework. One of the first activities is to identify stakeholders and any pain they could have. In order to achieve a continuous improvement, it is highly important to get stakeholders to work with the team, together in the same direction. According to Klaus Leopold, the following activities could be helpful for this stage:

-To visualize the power and influence of each stakeholder, using cards of different sizes.

-To visualize the degree in which each stakeholder involved supports the initiative. Draw a center point, and place the cards used before around, at different distances from the point. The closer to it, the bigger support from each stakeholder.

-To visualize the frequency of relationships among stakeholders. Draw different line types linking stakeholders’ cards. The thicker the line, the stronger the relation. Discontinuous lines mean sporadic relations.

-To visualize the quality of relationships among stakeholders with special symbols. As an example, a circle could mean a friendly/healthy relationship, a triangle a neutral/weak relationship, a cross an adversarial relationship.

These tasks create a clear vision of what parts are more powerful and the current status of relationships; enabling a better understanding of the work to be carried out in order to find a common solution. It is a helpful activity to prioritize a pain solving approach.

3. Defining purpose and success criteria. High levels of performance are most likely to be achieved by teams who have a common and well-defined purpose. Previously to beginning to work, the Team Leader should ask the following question: “Why does our Team exist?”. After that, the team will discuss about the answer. When everyone agrees with the answer, it is time to begin the following activity.

4. Identify how work is done. The objective is to understand in a realistic way the situation of the team. What work is requested, who makes the demands (internal or external clients), how demands are communicated, which is the frequency and quantity of orders, etc. This activity is also helpful to categorize the types of work of the following activity.

5. Understanding Work types. The Team Leader should ask the following questions to the team and let them some time to think and answer them. What types of work have more value for our clients and/or partners? What types of work have a higher and lower demand in quantity? What types of work are more urgent? What types of work are more aligned with the team’s purpose? What types of work are less aligned with the team’s purpose?

After considering these questions, work types could be classified according to the following categories.

-By source. For instance, a specific product, maintenance items or retail banking.

-By size. In terms of effort.

-By results. For instance, product launch or analysis reports.

-By type of flow. For instance, development, maintenance or analysis.

-By risk profile. For instance, standard work, urgent work, compliance with regulations.

-By relevance.

6. Basic management. If the team to which Scrumban is being introduced has been using Scrum before, GetScrumban game is an interesting tool to better understand those new features. The game simulates how a software development team using Scrum can broaden its current capabilities, overcome common challenges or create new ways to improve agility. The game experiments with principles such as pulling system vs. work assignment, evolving adjustments vs. radical change, delay costs vs. subjective prioritization, different service classes vs. a single workflow, or a continuous workflow vs. iterations (sprints).

Creation of the work board

Once the kickstart activities are completed it is time to create the working tool. As mentioned before, Scrumban framework is a pathway starting from Scrum and ending at a more evolved working tool. For this reason, the board used in Scrumban looks similar to the one used in Scrum. This board can be both physical -using a cardboard and post-its- and digital -using applications such as Trello-.

The board in a Scrumban framework has several columns, where developers will put notes. Each note refers to a task or work to be done. Each column refers to the phase in which the work is. The notes will advance throughout columns, from left to right. The objective is they can reach the final column within the minimum time, but without establishing time limits. Columns can be defined, from left to right, as To do, Ready, Designing, Developing, Testing, and Done.

First step. Creation of the board.^[1]

Second step. Creation of the board.^[2]

Third step. Creation of the board.^[3]

Fourth step. Creation of the board.^[4]

Fifth step. Creation of the board.^[5]

Sixth step. Creation of the board.^[6]

(to be continued)

Advantages

^[8]

^[9]

^[10]

^[11]

^[12]

Limitations

References

1. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
2. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
3. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
4. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
5. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
6. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
7. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
8. ↑ A. Reddy.(2015) "The Scrumban (R)evolution", Software Project Management
9. ↑ K. Bhavsar, V. Shah and S. Gopalan.(2020) "Scrumban: An Agile Integration of Scrum and Kanban in Software Engineering", Software Project Management
10. ↑ Corey Ladas.(2009) "Scrumban - Essays on Kanban Systems for Lean Software Development", Software Project Management
11. ↑ Alexander, M.(2020) "The beginner's guide to Scrumban", Software Project Management
12. ↑ Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management