Scrumban
(→What is Scrum?) |
|||
| Line 36: | Line 36: | ||
'''''Teams''''' | '''''Teams''''' | ||
</span> | </span> | ||
| − | In most of the cases, from 3 to 9 people. <ref name=four>Alexander, M.(2020) [https://monday.com/blog/rnd/the-beginners-guide-to-scrumban/ "The beginner's guide to Scrumban"], Software Project Management</ref> | + | In most of the cases, from 3 to 9 people. <ref name=four>Alexander, M.(2020) [https://monday.com/blog/rnd/the-beginners-guide-to-scrumban/ "The beginner's guide to Scrumban"], Software Project Management</ref> The digit can vary depending on the organization, but in general the number of team members is small, which is appropiate for carrying out small-medium sized projects. |
| Line 42: | Line 42: | ||
'''''Roles''''' | '''''Roles''''' | ||
</span> | </span> | ||
| − | Individuals at teams have different roles, which are the Scrum Master, Product Owner and Development Team. <ref name=three/> | + | Individuals at teams have different roles, which are the Scrum Master, Product Owner and Development Team. <ref name=three/> There is a hierarchy at the organizations in terms of management and decision making. |
| Line 54: | Line 54: | ||
'''''Work cycles''''' | '''''Work cycles''''' | ||
</span> | </span> | ||
| − | Teams using Scrum work in 1-to-4-week periods or cycles, called sprints. These periods last for 2 weeks in most of the cases. | + | Teams using Scrum work in 1-to-4-week periods or cycles, called sprints. These periods last for 2 weeks in most of the cases. |
| + | |||
| + | |||
===What is Kanban?=== | ===What is Kanban?=== | ||
Revision as of 18:37, 22 February 2021
Scrumban is a project management framework, developed for project and task tracking, mainly used by software development teams[1]. It is a relatively new tool, which can be implemented at any level of an organisation, and 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 what its name could suggest, Scrumban is not exactly a mix between Scrum and Kanban, but a pathway starting at Scrum and ending at a more evolved development framework. [2] Due to the acquisition of Kanban features, Scrumban has proven to be more appropiate than Scrum in time saving, quality improvement and waste minimization.
Contents |
Main Idea
Introduction
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. Scrumban arises from some limitations detected at Scrum throughout the years and feedback from practical experience, which will be commented later. As an overview, some of the benefits of Scrumban in comparison to Scrum are the following
Delivered quality: No time estimations are made for specific work, the result must be as good as possible and is not subject to a time frame.
Just-In-Time: The decisions are taken and the work is done when is needed.
Short delivery terms: The work is delivered within the minimum time.
Kaizen phylosophy: All work and processes are subject to a continuous improvement.
Waste reduction: Exclusion of whatever is not adding value to the client or customer.
To sum up, Scrumban arose with the goal of overcoming weaknesess of Scrum, in order to transform it to a more profitable framework, combining the best of Agile and Lean methods. Therefore, in order to understand Scrumban it is helpful to have some basic knowledge of both Scrum and Kanban concepts. A brief introduction of Scrum and Kanban is exposed next, prior to explaining Scrumban into detail.
What is Scrum?
Teams
In most of the cases, from 3 to 9 people. [4] The digit can vary depending on the organization, but in general the number of team members is small, which is appropiate for carrying out small-medium sized projects.
Roles
Individuals at teams have different roles, which are the Scrum Master, Product Owner and Development Team. [3] There is a hierarchy at the organizations in terms of management and decision making.
Meetings
Each sprint begins with a Sprint Planning Meeting arranged by the Scrum Master, to which all members of the team are called. Other stakeholders may also be part of the Sprint Planning Meetings. Daily Scrums or short meetings are also held every day, where all team members reunite.
Work cycles
Teams using Scrum work in 1-to-4-week periods or cycles, called sprints. These periods last for 2 weeks in most of the cases.
What is Kanban?
Teams
No limitations. [4]
Roles
No specifications about roles of team members. [4] (p.1631)
Meetings
Daily Standup meetings where all team members are present.
Work cycles
A continuous workflow.
Limitations of Scrum and contribution from Kanban
In Corey Ladas' words, Scrumban is a more evolved framework than Scrum, overcoming its limitations. These limitations, set out in the following sections, have been the subject of speech by some of the experts in the methodology.
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.”[5].
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. [5]
Although Scrumban also has some limitations which will be exposed later, the application of Kanban features really make Scrumban an efficient project management framework, especially in terms of complexity management. The following chart exposes some of the limitations of Scrum, how Kanban principles tackle them and the resulting features at a Scrumban framework.
| Limitations of Scrum | Inputs from Kanban | Result (Scrumban) |
| No lead time management |
Just-In-Time |
Decisions are taken and work is done when is needed |
| No indicators of work items in process at a time |
Work In Process (WIP) limits |
Work overload is avoided |
| Restricted team size |
No limitations in team member quantity |
Variety of roles in a team is not limited |
| No workflow management within sprints |
Work Flow Management (WFM) |
Internal workflow managed by assigning state to each work item (In Progress, Done) |
| No vision about internal state of work |
Work In Process (WIP) |
Visualization of work items that are active and in process |
| Limited iterative approach |
Continuous integration/Continuous Delivery (CI/CD) |
All work and processes are subject to a continuous improvement |
Applications
As mentioned previously, Scrumban -just like its core methodology Scrum- is a software management framework, which is especially directed to software development teams, although it could also be used for the management of other types of projects. Esentially, there are 2 potential situations in which Scrumban could be implemented. On the one hand, at organizations or teams currently working with Scrum which are trying to overcome its limitations or upgrade the method. This is the most likely situation. On the other hands, organizations which have never worked with Scrum or Scrumban. Although these teams might not be able to recognize the differences between Scrum and Scrumban, and probably will require more time to dominate the new framework, they are perfectly up to start to use Scrumban without previous Scrum experience.
Scrumban framework is especially useful at maintenance applications or projects, new product development teams, situations where Scrum teams have workflow, resources and processes issues, hardening and packaging stages or for improving management after having worked with Scrum. [2]
Implementation of Scrumban in teams working with Scrum
As mentioned before, Scrumban was conceived as a pathway from Scrum to a more evolved working environment. At an organisation, teams which have experience working with Scrum are more likely to understand Scrumban framework from the very beginning. In order to get the most out of Scrumban, there is a set of activities available for Team Managers to introduce the new working environment and organise their teams before starting to work. [1] Although these activities are especially conceived as a transition Scrum-Scrumban, they can also be helpful for Team Managers of teams without previous Scrum experience, in order to establish a solid base and optimize the resources.
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. The specification of this point is important in order to avoid possible 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. 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. Identifying 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 or SwiftKanban REF.
- Step 1. 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.
- Step 2. The following step is to define Work In Progress (WIP) limits. Consists in defining a maximum number of positions for each column, or said in other words, a maximum amount of work in a same phase. This restriction enables the pull system from Kanban. This means tasks will be automatically pulled through columns -to the right- whenever a position is left empty. Thanks to it, a constant and well organised workflow is ensured.
- Step 3. Afterwards, the 3 columns of the in-progress phases are divided into 2 subcolumns, defined as In Progress and Done.
- Step 4. The following step is to define a minimum amount of work in the To Do phase. This limit will be a meeting activator. Instead of arranging meeting every certain period, the team will reunite whenever the work To Do is above the line. In other words, team meetings are triggered by the work itself. This rule allows to close the workflow circle, and guarantees the team is always on the look for new tasks and activities to improve the quality of the work under development. At the same time, it maintains all team members active and busy.
- Step 5. The next step is to reorder continuously tasks in columns. The most relevant or urgent tasks will be reordered to the top of the columns, in order to prioritize them and make them flow throughout the board within the minimum time.
- Step 6. A couple of important aspects to understand Scrumban are the following. On the one hand, work is not assigned sistematiacally to team members. Unlike in Scrum, teams must not early bind work. The goal of the method is to ensure a good workflow and always maintain all members active, that is why an individual will not be in charge of a task from beginning to end. On the other hand, time estimations must not be made. The quality of the delivered work is more important than the timeslot in which it is done.
Limitations
Weaknesses of Scrumban
Like any other management method, tool or framwork; Scrumban also has some limitations. In this case, mainly because the fundamentals of Scrumban are those of Scrum, there are some weaknesses that Scrumban has inherited from Scrum [5]. These are basically limitation from Scrum which Kanban principles have not solved. On the other hand, there are also some potential weaknesses in Scrumban caused by an inappropiate understanding of the framework when switching from Scrum.
- Although Scrum teams size are suitable for small-medium sized projects, they limit progress at big scale projects. Kanban principles do not solve this inconvenient because as they do not especify an standard team size.
- At Scrum Sprints, external stakeholders do not participate and this fact often implies progress issues and completion of tasks. Kanban does not especify stakeholders' contribution at tasks.
- Roles at teams working with Scrum are limited. Role specification is essential for development teams and Kanban does not especify team roles either.
- In an Scrumban framework, Team Managers have fewer control than in Scrum. Individuals choose tasks for themselves. There is higher equality among all individuals and it is harder to track the effort of contribution of each person.
[5] (p. 1631.)
Annotated bibliography
The references provided next may be consulted for further reading on the topic of software project management framework Scrumban.
- Ladas, C. (2009) Scrumban: Essays on Kanban Systems for Lean Software Development. Lean Series. Seattle WA: Modus Cooperandi Press.
- -First book explaining the fundamentals of Scrumban, written by the methodologist who first conceived the method. Ladas explains how agile methodologies such as Scrum have helped software developers to be more efficient, while at the same time there is still room for more benefits. Lean methods such as Kanban can make these processes even more powerful and profitable. The author provides essays for real-world cases to give teams the background to create more robust practices.
- Bhavsar, K. et al. (2020) Scrumban: An Agile Integration of Scrum and Kanban in Software Engineering, International Journal of Innovative Technology and Exploring Engineering (IJITEE), vol. 9, issue 4. ISSN: 2278-3075.
- -This recently published paper exposes how emerging software engineering technologies seek an Agile process and framework for their management at an organisational level. The authors explain the limitations of Scrum, and how the formation of hybrid framework Scrumban can be a solution to the challenges of Scrum, considering as well the limitations of Scrumban.
- Reddy, A. (2015) The Scrumban [r] evolution: getting the most out of Agile, Scrum, and lean Kanban. Addison-Wesley Professional.
- -The author explains the role of Kanban as a catalyst to increase the value of existing software development processes, augmenting the benefits of Scrum. It is a comprehensive, coherent and practical book in order to help teams to implement Scrumban and get the most out of it.
- Straughan, G. (2017) "Development That Pays: Scrumban", Software Project Management
- -I would like to make a special mention to Gary, whose content regarding Scrumban, both in his YouTube channel and his website (Development That Pays) was very useful for me to understand the concept at the very beginning. I highly recommend his contribution to everyone who has never heard about Scrum and Scrumban before.
References
- ↑ 1.0 1.1 1.2 1.3 A. Reddy.(2015) "The Scrumban (R)evolution", Software Project Management
- ↑ 2.0 2.1 https://content.intland.com/blog/agile/scrum-kanban-scrumban
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 Gary Straughan.(2017) "Development That Pays: Scrumban", Software Project Management
- ↑ 4.0 4.1 4.2 Alexander, M.(2020) "The beginner's guide to Scrumban", Software Project Management
- ↑ 5.0 5.1 5.2 5.3 K. Bhavsar, V. Shah and S. Gopalan.(2020) "Scrumban: An Agile Integration of Scrum and Kanban in Software Engineering", Software Project Management
- ↑ Corey Ladas.(2009) "Scrumban - Essays on Kanban Systems for Lean Software Development", Software Project Management
Made by Xabi Martínez de Zabarte (s210323)
