Joachim Grotenfelt
Agile Software Development and Im- plementation of Scrumban
Metropolia University of Applied Sciences Bachelor of Engineering
Mobile Solutions Bachelor’s Thesis 30 May 2021
Abstrakt
Författare Titel Antal Sidor Datum
Joachim Grotenfelt
Agile software utveckling och Implementation av Scrumban 31 sidor
30.05.2021
Grad Igenjör YH
Utbildningsprogram Mobile Solutions
Huvudämne Informations- och kommunikationsteknologi Instruktörer Mikael Lindblad, Projektledare
Peter Hjort, Lektor
Målet med avhandlingen var att studera agila metoder, hur de används i mjukvaruföretag och hur de påverkar arbetet i ett programvaruutvecklingsteam. Ett annat mål med avhandlingen var att studera bakgrunden till den agila metoden, hur den togs i bruk och hur den påverkar kundnöjdhet.
I denna avhandling förklaras några existerande agila metoder, verktygen för hur agila metoder används, samt hur de påverkar programvaruutvecklingsteamet.
Avhandlingen fokuserar sig på två agila metoder, Scrum och Kanban, eftersom de ofta används i olika företag.
Ett av syftena med denna avhandling var att skapa förståelse för hur Scrumban metoden tas i bruk. Detta projekt granskar fördelarna med att ha ett mjukvaruutvecklingsteam som arbetar med agila processer.
Projektet lyckades bra och en arbetsmiljö som använder agila metoder skapades. Fördelen blev att utvecklarteamet kunde göra förändringar när sådana behövdes.
Nyckelord Agile, Scrum, Kanban, Scrumban
Abstract
Author Title
Number of Pages Date
Joachim Grotenfelt
Basics of Agile Software Development and Implementation of Scrumban
31 pages 30.05.2021
Degree Bachelor of Engineering
Degree Program Mobile Solutions
Professional Major Information- and Communications Technology Instructors Mikael Lindblad, Project Manager
Peter Hjort, Senior Lecturer
The goal of the thesis is to study the Agile methods and how they affect the work of a soft- ware development team. This study also explores the background of Agile, how it is currently used in companies and how it can be taken into use in a project.
This study focuses on how Agile methods are used and offers guidelines how to use the methods more effectively. Furthermore, the study explains the benefits that the use of Agile methodology can bring to companies.
The thesis focuses mainly on two Agile methods, namely Kanban and Scrum, because they are widely used in different companies.
One of the purposes for this work was to create a basic understanding of how the Scrumban method, a combination of Kanban and Scrum, is used while working on an ongoing project.
As a result of this project, the benefits and tools of the Scrumban method were implemented in a company.
The results were positive, creating an Agile work environment for a software team, and providing it the chance to make any changes when necessary.
Keywords Agile, Scrum, Kanban, Scrumban
Contents
Contents
1 Introduction 1
2 History 2
3 Agile Methodology 3
3.1 Twelve Principles of Agile 3
3.1.1 The First Principle, Customer satisfaction 4
3.1.2 The Second Principle, changes 5
3.1.3 The Third Principle, planning 5
3.1.4 The Fourth Principle, working together as a company. 5
3.1.5 The Fifth Principle, employees 6
3.1.6 The Sixth Principle, face-to-face conversation 6 3.1.7 The Seventh Principle, project progression 6 3.1.8 The Eight Principle, key players during development 6 3.1.9 The Ninth Principle, improve the level of agility. 7
3.1.10 The Tenth Principle, simplicity 7
3.1.11 The Eleventh Principle, self-organizing teams 8 3.1.12 The Twelfth Principle, reflecting on the team’s performance. 8
3.2 DSDM the original Agile method 8
3.3 Extreme Programming (XP) 10
3.4 Lean Software Development 12
3.5 Crystal 12
3.6 SCRUM 13
3.6.1 The Scrum Team 13
3.6.2 Scrum Board, sprint task board 14
3.6.3 Daily Scrum and Scrum of Scrums 15
3.6.4 Sprint 16
3.6.5 Burn Charts 16
3.6.6 Sprint Review 18
3.6.7 Retrospective 18
3.7 Kanban for self-sufficient teams 18
3.8 Scrumban, a combined Agile Method 21
4 Using Scrumban in an Ongoing project 22
Contents
4.1 Planning and Implementing Scrumban 22
4.2 Interviewing Agile qualified engineers on Kanban and Scrum 25
4.3 Updating, Upkeeping, and Improving Scrumban 26
5 Discussion and Conclusion 29
References 32
List of Abbreviations
PO Product owner, the person in charge of the project.
SM Scrum master, scrum team facilitator.
SP Story Point, a measurement for tasks in product backlog.
SoS Scrum of Scrums, meeting between SMs CP/M Control Program/Monitor, operating system.
1
1 Introduction
Agile methods are a growing trend in the software development industry because they bring a product the customers’ need. Many times, products that software developers created in the past were not relevant anymore at the time of release.
The idea for this thesis came from students who started working for Nokia. The students created thesis studies of an ongoing project and while thinking of the topics, it became obvious that no one working on the project had any idea of how to use Agile methods.
This thesis focuses on Scrum, Kanban and Scrumban as Agile methods, other methods discussed are Crystal, Dynamic Systems Development Method (DSDM), Lean Software Development and Extreme Programming. The reason for choosing the three main meth- ods is the flexibility of Kanban and how Scrum as an Agile method brings predictability.
Together these two methods can be combined into a method called Scrumban. There are no set practices yet for Scrumban and the thesis tries it out and shows how it can be executed. The data for the agile methods comes mainly for public available sources.
Nokia was founded in 1865 as a single paper mill operation, the company began to find and nurture new industrial sectors over the years. These sectors included cable, paper product, rubber boots, tires, televisions and mobile phones. Nokia changed their primary focus to telecommunications in the 1990s and in 1991 the first call ever made with GSM (The Global System of Mobile Communications) was made by using Nokia equipment.
In 1998 Nokia had the best-selling mobile phone brand in the world and in 2003 they introduced the first camera phone. In 2014, Nokia sold their mobile and devices division to Microsoft. [1.]
Followed-up by creation of Nokia Networks, and buying out the joint-venture partner Sie- mens laying the foundations for new focus, today Nokia is known primarily as a network hardware and software provider. [1.]
2
2 History
In the early 1990s, software development faced a crisis because the use of personal computers (PC) began to rapidly increase in enterprises. This crisis was referred to as
“the application development crisis,” or “application delivery lag” [2]. The reason behind the crisis was that businesses developed much faster than anticipated and the software needed was outdated and did not meet the needs of companies [2] [3, 132].
Between 1991 and 1997 many methods that would fit the Agile repertoire were created.
Some of these methods are rapid application development, Dynamic Systems Develop- ment Method (DSDM), Scrum, Crystal, and Extreme Programming. Today these meth- ods are known as Agile development frameworks. Even though these methods were created before the Agile Manifesto, it was clear that the fundamental practices, methods, and tools used were all associated with Agile methodology.
The Agile Manifesto was signed in 2001 by the founders in Utah, USA. The seventeen founders and the signatories of the Agile Manifesto, were: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas [4].
The goal for their meeting was to find a different way to go about the software develop- ment process. Each person in the group was known as a rebel of sorts by bending the rules, working in unorthodox manners, and otherwise exploring the uncertain areas of software development. The problem was that their small group tried to break the ice when working with the mindset of manufacturing. Companies they worked for often wanted to run software development the same way a manufacturing process is ran. This group understood that the software development resembled more new-product develop- ment with an engineering approach. A quote from NASA’s Robert Frost helps to explain the difference between development and manufacturing. “… Why does it take six years to develop a new airplane when it shares 90% of its ‘DNA’ with the previous model? The answer is that they are complex devices… there is a little tolerance for imprecision and error.” [3, 160].
3
All the software developers gathered for the meeting understood this mindset because they had worked with the obstacle for decades. They had experienced success and fail- ure with many different frameworks and tools. These frameworks and tools did not guar- antee success in any given project. Companies did not understand this, and they had implemented various methodologies other than Agile into their operations. Because of this, the software design processes were not short and brief enough.
The group named themselves “The Agile Alliance” and created a manifesto of twelve principles and four values. Their goals were to create deep-set themes that would fuel development, rather than a strictly outlining of tools. After the publication of the Agile values and principles, the Agile movement took off [3, 175]. For example, documentation and the use of right methodologies became easier.
3 Agile Methodology
Agile methodology was first mentioned in 2001 [3, 636], when light-weight or light soft- ware development tools were introduced as Agile frameworks.
Agile methods bring the ability to react to the needs of the customer. Agile methods are used in many software development companies for the software developing teams to be more efficient and require them to be self-sufficient. There are cases where companies claim to use Agile methods, but they only use a few of them or very old methods that might not be considered Agile these days [3, 651].
There are quite a lot of agile software development methods. Each method has their own strengths. However, deciding what framework and tools to use is up to the software de- velopment team or by the management.
3.1 Twelve Principles of Agile
To understand the mindset of The Agile Alliance it is necessary to know the twelve prin- ciples of Agile software development. First, there are four values core values [5]. The first value being “Individuals and interactions over processes and tools” [4], which implies on having the right group of individuals on your software development team for the
4
project to be successful. It is also vital for the group to be able to communicate with each other and the interaction between team members helps them to collaborate and solve problems as they rise.
The second value “Working software over comprehensive documentation” [4] refers to technical specifications, technical requirements, technical prospectus, interface design documents, test plans and documentation plans that were previously all documented and each required an approval [6]. While documentation is not bad, too much time was put into it.
The third value “Customer collaboration over contract negotiation” [4] refers to a practice where the project manager and the customer would draw up a contract and work out the details of delivery. This meant the customer would only be involved at the start and end of the project. There would often be a contrast between what the contract said, what the product did, and what the customer needed. According to the Agile Manifesto, the focus should be on continuous development [4]. Having the customer engaging and collabo- rating in the development phase makes it easier for software developers to deliver a product the customer needs.
The final value “Responding to change over following a plan” [4], refers to earlier software development where having a roadmap for the software would never change and if there were changes, they were seen as expenses [5] [4]. However, because needs, require- ments and priorities are constantly changing, a roadmap will fast grow outdated. The Agile Manifesto suggests that a software team should be flexible when it comes to changes and the team should be able to react to changes even every month [6].
3.1.1 The First Principle, Customer satisfaction
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. [7]
The customer should always be held as the highest priority when delivering software.
The goal of an Agile team is to strive for releasing the software as early and often as possible for customer feedback. By having the customer try the product as often as pos- sible, it will help the team to understand what the customer’s true needs are and create
5
a product that has the best business value [8]. Getting end-user feedback can sometimes be quite challenging but it is crucial to the development teams [8].
3.1.2 The Second Principle, changes
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” [7]
All software development teams are supposed to follow this principle, accepting changes throughout the project. However, there are some restrictions for this principle; develop- ment teams will not accept changes just for the sake of it. If the customer has a need for something new, then the change is welcome.
3.1.3 The Third Principle, planning
“Deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter timescale.” [7]
There are some clear challenges when doing the software planning at the very beginning of the project. The Agile Manifesto address these concerns by placing a focus on indi- viduals and interactions, working software, customer collaboration and responding to change [9].
Rather than releasing software once every six months up to a year, the development teams should release much more frequently, even weekly.
3.1.4 The Fourth Principle, working together as a company.
“Businesspeople and developers must work together daily throughout the project.” [7]
The idea behind this principle is that the businesspeople and software developers, even within the software development team, do not fully understand the task of the other. It is critical for both parties to work together daily to be effective.
6
3.1.5 The Fifth Principle, employees
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” [7]
When organizing a project, the PO (Product Owner) needs to consider carefully what kind of people to hire. Everyone must understand their responsibilities. A developer team should be less controlled, and managers should not micromanage.
3.1.6 The Sixth Principle, face-to-face conversation
“The most efficient and effective method of conveying information to and within a devel- opment team is face-to-face conversation.” [7]
Most of the time when we talk, we rely on body language and it can make a difference.
This study was made during the COVID-19 pandemic and communication and meetings were held over VoIP (Voice over Internet Protocol) software such as Teams or Zoom.
Having a webcam on, enables the use of body language and the understanding of others was almost the same compared to being face-to-face.
3.1.7 The Seventh Principle, project progression
“Working software is the primary measure of progress.” [7]
“This principle stands to show that teams must know whether they’re going in the right direction or not just based on how well the software works.” [3, 436]. This quote gives the base idea behind the principle. However, there is no real measurement, for example,
“80% of the code works”. Instead, once the software has been created, thoroughly tested and accepted by the end-user, a part of the project, if not the whole project, will be com- pleted.
3.1.8 The Eight Principle, key players during development
“Agile processes promote sustainable development. The sponsors, developers, and us- ers should be able to maintain a constant pace indefinitely.” [7]
7
The principle mentions a few key players for every project, the sponsors, also known as Product Sponsors, the developers, and users. This short list of roles and the POs (Prod- uct Owners) are the only ones that need to be worried about during the development stage. Sponsors are the bridge between the company and the developers, while the us- ers must be on everyone’s mind. The developers and sponsors should listen to the user on every occasion.
3.1.9 The Ninth Principle, improve the level of agility.
“Continuous attention to technical excellence and good design enhances agility.” [7]
If employees focus on good design and technical excellence, they will be able to build up the level of agility. First, the principle combines the concept of continuous attention on the technical and design aspects of software development. Second, Agile methods such as Scrum might be used and there would still be room to enhance agility to fit the development team.
Finally, continuous attention, technical excellence, and good design are the three things that eventually lead to enhanced agility. Without them, a software developer team would not be using Agile principles, but just the Agile tools given. [3, 478]
3.1.10 The Tenth Principle, simplicity
“Simplicity – the art of maximizing the amount of work not done – is essential.” [7]
This principle has similarities between a manufacturing team and software development.
Simplicity, however, may have other meanings for software developers. There are a few aspects during software development processes that are nearly impossible to work on together. It requires trust between coworkers that they do their part of the project, and they do it well. By simplifying each process to its lowest factor, it is possible to ensure that everyone works towards a joint collective goal. [3, 502]
8
3.1.11 The Eleventh Principle, self-organizing teams
“The best architectures, requirements, and designs emerge from self-organizing teams.”
[7]
Agile attempts to modify the command-and-control method which is a top-down ap- proach. This principle promotes self-organizing software development teams, where the teams organize from the bottom up. This does not imply that there are no rules, a lot of Agile methods have, in fact, very strict rules. However, it will give the team the freedom to create their own rules or choose the method they feel most confident with [10].
3.1.12 The Twelfth Principle, reflecting on the team’s performance.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” [7]
Improvement is what every organization strives for, and this applies to software devel- opment teams as well. In frequent Scrum sprints each member of an Agile team is in- cluded and heard from, and new ideas that could help improve the productivity of the team are discussed. Scrum meetings focus on the project at hand, and what needs to be considered next.
3.2 DSDM the original Agile method
DSDM can be considered the original Agile method and is still used by software devel- opment teams to this day. DSDM formal abbreviation is “Dynamic Systems Development Method”. DSDM (Dynamic Systems Development Method) is the original Agile method.
DSDM was created in 1994 and introduced to Agile in 2003 [11].
The reason for DSDM’s success was due to its philosophy “that any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.” [11]. There are eight principles supporting this philosophy and they are aligned with the twelve principles of Agile.
The eight principles of DSDM include [11]:
9
• Focus on the business need
• Deliver on time
• Collaborate
• Never compromise quality
• Build incrementally from firm foundations
• Develop iteratively
• Communicate continuously and clearly
• Demonstrate control
As DSDM became more popular, it started to spread outside of software development teams into system development and the term changed [3, 684]. Nowadays DSDM does not specifically stand for Dynamic Systems Development Method, but instead it is known as “Driving strategy, deliver more”. Teams often choose DSDM because it deals with the entirety of the project rather than only the communication or only the planning. DSDM is also praised for its scalability and it works effectively for both small and large teams. [11]
There are five core techniques that are used in DSDM and they are Timeboxing, MoS- CoW, Modeling and prototyping, Testing, and Workshops. Timeboxing is the approach for completing the project by splitting it into smaller portions, each portion having its own fixed budget and delivery date.
MoSCoW the acronym stands for “Must have, Should have, Could have, Won’t have”. It is a technique for prioritizing work items or requirements and helps the team make pro- gress including hitting deadlines. Models and prototypes help the team understand and confirm the expectations of the stakeholders for the project.
Testing means having DSDM development team members creating tests for the product and have the users test, give feedback, and involve them throughout the whole process to ensure good quality [12]. The purpose of Workshop’s is to bring the stakeholders to- gether to discuss requirements, functionalities, and mutual understanding [13] [14].
Projects using DSDM start by creating the business requirements and making the user stories. It is necessary to understand how different aspects within the business impact
10
the customer or user to help guide decision making. DSDM will constantly refer to the user stories and business requirements for decision-making purposes. When changes arise, the question comes back to what the business requirements are. The method heavily relies on not doing unnecessary work and reacting to changes as quickly as pos- sible.
Once the business requirements have been established, the priorities for the project will be set by the team. For example, the demands for the software to have a certain level of security, user security and regulations require that security to take higher priority over design of the software. The team will work on the project a piece at a time while regularly interacting with the PO. This will enable the team to deliver, test and provide the software for acceptance within a short amount of time. When each milestone has been reached, the team will collaborate with the end-users or customers to identify any necessary changes. DSDM will loop these steps until the user is satisfied, the project is complete and ready for launch. The method focuses exclusively on the project, while not looking at the lifelong needs of the software. [3, 681]
3.3 Extreme Programming (XP)
This agile method was created by the Agile Alliance member Kent Beck in 1998. The reason this method was named XP, was because it recognized good practices, such as iterative development, and pushed them to extreme [15, 77]. It relies on simplicity, team communication and feedback, its main priority being focusing on customer satisfaction [3, 694].
The method has a development lifecycle and steps that must be followed as illustrated in Image 1. In the first step “Select user stories for this release” developers choose a user story, also called scenarios, which are series of tasks. Once the story has been selected the next step is to “Break down stories to tasks”. Stories are then split into smaller tasks, for example, “As a user, I can save employee data by writing the data in a form”. This story can be broken down to tasks such as “saving data to a database” and
“A form on the front page” [15, 77].
11 On the “Plan Release” step there is a release planning meeting held where the overall project is laid out. The essence of the meeting is for the development team to estimate each user story of ideal programming weeks, meaning how long it would take to imple- ment a story if the team has absolutely nothing else to do [28]. Following up with “De- velop/integrate/test software”, which is the phase where pair programming comes in, the programmers pair up for each task to develop tests before writing the code, this is also known as Test Driven Development (TDD). The pair programming partners keep rotating to ensure more consistent coding and promote communication. The tests must be suc- cessfully executed before integrating the new code to the system. Then there is a short gap before the software is released.
Finally, the “Evaluate system” takes place when the team evaluates their whole system they released and receive feedback from the PO [3, 694] [15, 77]. It then loops back to the first step and repeats until the project is complete.
Image 1. Lifecycle of extreme programming [15, 77].
XP (Extreme Programming) is known as a continuous process method where the team handles an entire project on a small and large scale daily. Because XP schedules small releases, the code is easily refactorable [3, 694].
12
3.4 Lean Software Development
Lean Software development is an agile framework for optimizing development time and resources, eliminating waste, and ultimately delivering only what the product needs. This framework is usually referred as the Minimum Viable Product (MVP), meaning teams using this method will release a bare-minimum version of the product to the market [16].
Lean software development is a hybrid framework with both Lean and Agile, adapting the Lean philosophy into software development. In short, LEAN philosophy helps to con- tinuously reduce all costs, both fixed and variable, direct and indirect. [17].
There are four steps in Lean Software Development. The first step is to analyze and identify the needs and wants of the customer. During the second step the team will follow up on the needs and wants, filtering through the ideas to create a concrete base for the project. This step relies on the question “Where can we focus our efforts to create a functioning and valuable software?” [3, 725]. Then the team creates a workflow that min- imizes waste, by having the team members working separately on the tasks created.
This step is followed up by the customer and Pos (Project Owner’s) feedback. The cus- tomer and PO will alert the development team if there are any issues with the functionality of the product, until a solid foundation for the software has been made and released.
Lean Software Development method ensures the product is getting feedback on neces- sary functionalities from the users [18].
3.5 Crystal
Crystal is a model that was created by Agile Alliance member Alistair Cockburn years before the Agile Alliance meeting. It is not just one method, but a family of methodologies.
The first one, Crystal Clear, is made for smaller teams of no more than eight people. The second one, Crystal Yellow, suits better for teams between ten and twenty. The third one, Crystal Orange, suits for teams between twenty to fifty people.
Crystal method focuses on the people involved in the project, the primary focus being the team members, the community, skills, communication methods, talents, and interac- tions.
13
One of the highest priorities in Crystal is the frequent delivery: Crystal developers must release the iterations frequently and on schedule. The schedule varies between the teams, the typical time frame is one week between iterations [3, 753].
The Crystal method also works around a reflective workshop. The workshop’s focus is to help the team modify their actions rather than their behaviors. These workshops are held every few weeks and during the workshop the team identifies what is not working and how to fix the problem. The next step after the workshop is osmotic communication.
Osmotic is a science term whose definition is “a process of absorption or diffusion sug- gestive of the flow of osmotic action especially: a usually effortless often unconscious assimilation” [19]. In short, osmotic communication is the accidental overhearing of back- ground information that may later end up being important.
During the osmotic communication meeting, the goal is to get accurate information to flow quickly throughout the group with rapid-fire questions and updates on every aspect of the project.
3.6 SCRUM
Scrum is an Agile method with a lot of different tools and frameworks that makes it the most frequently used method in software developing. Scrum was created by Schwaber and Beedle in 2001 [15, 73] and its values are: courage, focus commitment, respect, and openness. The quote “The method relies on the Product Owner, Scrum Master, and team members to all work cohesively at every step.” [3, 793] is a good explanation of what the Scrum Team does and of what the method stands for.
3.6.1 The Scrum Team
In Scrum there are roles that need to be filled in each Scrum Team. The purpose is to create a work environment where everyone is equal, but every role has their unique task.
These tasks are the key to how the team works.
Stakeholder is not a role only for Scrum, but they are people or organizations that fre- quently interface with the product owner, scrum master and the scrum team. They
14 provide feedback on the product throughout the project’s development. Typically, stake- holders are known as customers, users, and sponsors [20].
Product Owner (PO) is the person in charge of the project who makes the final decision on all changes that the team might recommend and is the link between the development teams and the stakeholders. The PO is responsible for is the product backlogs and task prioritization [21].
Scrum Master’s (SM) tasks are to serve the Scrum Team by coaching the development team in self-management and cross-functionality, ensuring all scrum related events take place, are positive, productive, and held on time. SM assists the development team to understand the items on the product backlog. Being part of the empirical product plan- ning for complex environments. SM also assists the PO in creating each sprint and the product backlog and strives to find techniques for effective Product Goal definition [22].
Software developers are the development team, the ones that create code and test the software. Their main objective is to create software on the needs and wants of the stake- holders [21].
3.6.2 Scrum Board, sprint task board
The Scrum Board is a tool to help teams build their Backlog items for each Sprint. The board itself can take different forms, either physically or virtually. The board presents all the information on the project openly so that the team can easily answer question such as where the team is in development as can be seen in Image 2 below.
15
Image 2. Scrum Board [22].
Stories are the user stories; they are separate stories of a project that are identified and described. To Do column is for tasks that are made for that sprint and are meant to be done. Once a team member has decided what they are working on they can move the task to In Progress, where the jobs that the team is working on are. Once the” In Pro- gress” task has been completed it can be moved forwards to “To Verify” where the task will be tested. Finally, once the task has been tested, it will be moved to “Done” column and the task is completed. This process should be done with every task made. Once the Sprint is done, this cycle continues until the project is complete.
3.6.3 Daily Scrum and Scrum of Scrums
Daily scrum is a daily team session, held for 15-minutes at most [23], where the SM (Scrum Master) and development team members sit down and go through what has been done since last time. The team answers the questions “What have I done”, “What will I continue to work on” and “What problems I have”. By answering these questions, after
16
the session the team members can hold a meeting on the problems they have stumbled on.
Scrum of Scrums is the higher level of daily scrum where Scrum Masters have their own scrum and tell what their team has been able to accomplish, what they will continue working on and what the problems have occurred. If one of the teams has problems they have been working on, another scrum master can jump in and inform that they might have an answer and arrange a meeting between their teams [20].
3.6.4 Sprint
Sprints are short intervals where the development team accomplishes a small section of the whole project. The length of sprints is decided by the Scrum team (developer team + PO + SM), usually the sprint period is from two to four weeks [20]. The PO and SM are responsible for adding tasks to the sprint, these tasks are known as a sprint goal. During the sprint there are no changes allowed that could endanger the sprint goal, but the product backlog can be refined, the quality of the product should not decrease, and the sprint can be renegotiated with the PO when the team learns more about the project and necessary technologies [24].
3.6.5 Burn Charts
There are two types of burn charts, the Burn-Up and Burn-Down, both are tools to track work completed over time. The Burn-Up chart shows the work effort, y-axis, and time planned, x-axis, and the required work to complete the project is a straight line on top of the chart. In Image 2 there is a good example of Burn-Up chart, the effort being Story Points (SPs) and time being the number of sprints. As sprints go on, and tasks are com- pleted, it is easy to see how the team is progressing through the project and how far from the end goal they are.
17
Image 3. Burn-Up chart [25].
The Burn-Down chart takes a different approach compared to the Burn-Up chart. Image 3 shows it well, instead of the required work being on top of the chart, it is a vertical line throughout the project to see how the team is fairing with the amount of work needed.
Image 4. Burn-Down chart [26].
18
3.6.6 Sprint Review
Sprint Review is the end of sprint review where the Scrum Team presents the results of the sprint to the stakeholders and inspect the outcome of the sprint and decide the next adaptions.
During the event, both the Scrum Team and stakeholders review what has been accom- plished during the sprint and what has changed in the environment. With the attained information, attendees collaborate on the next steps. Sprint Review is a working session which is why the Scrum Team should avoid limiting it to a presentation.
3.6.7 Retrospective
At the end of each Sprint, the team holds a meeting where they talk about what went well, what could be improved and what will be committed to improve before the next Sprint; this is called Retrospective.
“The Scrum Master encourages the rest of the Scrum Team to improve its process and practices to make it more effective and enjoyable for the next Sprint” [27]. The main goal for retrospective is to give all the team members a safe space to talk freely on what could be improved, how something could be improved, and share facts. The team members need to feel they are heard. If not, the team’s chemistry, moral and workflow might suffer.
3.7 Kanban for self-sufficient teams
Kanban is one of the most known agile methods aside from SCRUM. It originates from Japan and was developed by Taiichi Ohno in 1940s. It was designed to be a simple planning system for controlling and managing work and inventory at every stage of pro- duction optimally. The word Kanban means sign or signboard in Japanese. While Kan- ban was created in the manufacturing industry, David J. Anderson first applied the con- cept to IT, Software development and knowledge work in general in the year 2004 [28].
The Kanban method follows a set of principles and practices to manage the workflow.
By following these practices and principles, the Kanban method will successfully
19
maximize the benefits to business processes, reduce cycle time, and increase value to the customer with greater predictability.
There are four core principles first one being “Start with what you are doing now” [30].
Kanban emphasizes to not make changes to existing processes right away. The versa- tility in Kanban allows the team to slowly implement new methods and practices depend- ing on the project’s requirements, without creating a cultural shock to new technologies or other processes.
“Agree to pursue incremental evolutionary change” [29]. This principle encourages to make smaller incremental changes, if radical changes were made instead, it would be met with resistance within the team and organization due to fear or uncertainty. [28][29]
“Initially, respect current roles, responsibilities, and job-titles” [29]. Kanban respects the existing hierarchy at organization. So, if there are roles or functions which are performing well it is not necessary to make changes to them. The team will have to discuss the necessity for new changes and slowly increment them if needed. These three first prin- ciples were designed to promote and encourage incremental, logical changes, to avoid triggering fear of change within organizations.
“Encourage acts of leadership at all levels” [29]. The principle encourages every em- ployee at all levels to provide ideas and show leadership to implement changes to con- tinually improve the way products and services are delivered.
Kanban has six core processes or methods, first is “Visualization of the Workflow”, which can be seen in image 4, the Kanban board. Some teams use Trello as their Kanban board. The board only has three columns, which are: To Do, Doing or In Progress, and Done. Tasks are written on Kanban cards, each card representing one task. The task should be kept simple, not creating a multiple task for one card. Meaning that the cards should have either design or documentation, not “design and documentation”. When starting a task, it is moved from requested to in progress, this makes it easier to follow the workflow and spot bottlenecks and slow-progressing tasks. The second process is
“Limit Work in Progress”, it takes into consideration how many tasks there can be ‘in progress’ at one time, usually the limit would be six to seven tasks [3, 965]. The idea
20
behind this is if any of the tasks is hindering progress, and which task needs immediate attention.
Image 5. A Kanban board with its three columns, To Do, Doing and Done [29].
“Manage Flow” is the third process, once the two other practices have been implemented it is necessary to manage and improve the flow of work. The manage part is the man- agement of the work but not the people and the flow being movement of work items throughout the process. One of the reasons for implementing Kanban is to create a smooth, heathy workflow. Instead of micro-managing people, the focus should be set on the work processes and understanding how to get work done faster. This way Kanban would create value more quickly.
The fourth process “Make Process Policies Explicit” strives to create work guidelines, creating a common basis for all participants to understand how to work in the Kanban system. It is impossible to improve something that is not understood. Therefore, the guidelines are essential, and it also opens a door where the participants can improve these guidelines or methods of work, once everyone is familiarized with the common goal in the project.
For teams and organizations to be more agile the fifth process “Implement Feedback Loops” is mandatory. Getting feedback from stakeholders, customers, and users in the
21
early stages of the project, enables teams to react to potential changes before they start developing the software in the wrong direction. This will ultimately deliver the right prod- uct or service to the customer in the shortest possible time.
The last and sixth process is “Improve Collaboratively, Evolve Experimentally (using the scientific method)”. It refers to improving the Kanban methods to fit the need of the team.
Teams that have a shared understanding of the goals, workflow, processes, and risks will likely work together towards improvement.
The easiest way to understand Kanban is to read and understand the four core principles and apply them to the daily work of the team. By applying them to daily work of the team and working with the six practices for a while, the team will notice how much Kanban impacts their work.
3.8 Scrumban, a combined Agile Method
Scrumban or Scrum plus Kanban is a combined agile method, it combines the predicta- bility of Scrum with Kanban’s flexibility and continuous workflow. The teams who use this method choose practices from both Scrum and Kanban to fill the necessary requirements for the projects to be agile [30].
This method is mainly used for ongoing projects, for teams that see Scrum as a too strict method and need the flexibility of Kanban [31]. The teams will have some of the rules from Scrum that can be applied and help the team with milestones in the project. An example of management would be scrum team (roles) and Scrum meetings, such as daily scrum and scrum of scrums. The Kanban part in Scrumban is to improve processes, visualization of the workflow, limiting how many items are in progress on the Scrum or Kanban board, depending on which one the team decides to use or if they want to com- bine the boards.
The method is very new and still does not have any set of practices within it. The team decides on processes that they see necessary to keep the team agile [28].
22
4 Using Scrumban in an Ongoing project
The purpose of this project was to help a group of students to start using the Scrumban method. This chapter covers each step of the first implementation of Scrumban method to an ongoing project by students.
4.1 Planning and Implementing Scrumban
The development team started working on an internal project with a deadline and re- searching existing Agile methods and choose one of them to implement. Kanban was first implemented, a more flexible style of working to get a faster start to the project. It is necessary to have some guidelines for the team and Kanban’s methods bring them.
The next step was to create the product backlog, tasks, and task labels (for example,
“Frontend” or “Backend”) for what had to be done to get the project going and giving each member a task to start working on. if any task were too time consuming it would be divided into smaller tasks. No issues came up while creating tasks because planning for the continuation of the project was done. The planning included new possible features, improving existing features and requirements for releasing the product.
The team created a Trello board for the product backlog, an easy-to-use digitalized board, where all newly created tasks were put on a column called ‘Product Backlog’.
Other columns were added soon after tasks were added and those were ‘To Do’, ‘Work- ing’, ‘Testing’, and ‘Done’.
The ‘To Do’ column had all the tasks that were priorities for a while forwards, reason for this was because the team was not able to predict how much each task would take time.
The ‘Working’ column had only the task each member was working on, it was agreed that only one task per person, except if the tasks were connected to each other or there were some tasks that had to take priority. Product features and accomplished according to the member working on it would be moved to the ‘Testing’ column. These features needed to be tested before adding to the production version of the project. Tasks that were tested or which were not product features could be moved to the ‘Done’ column, which meant the task was done and next task could be moved to working phase.
23
Once the product backlog was implemented one of the team members heard of the method Scrumban and collected basic information about it. The team decided to use this method and take scrum tools that add more predictability to the project. These Scrum tools were team roles, sprints, daily scrums, sprint review and retrospective.
Scrumban method was decided to be the agile method used by the team. Next steps were to select who would fill the roles of Scrum Master and Product Owner for the project.
The roles were quickly decided, PO would be the product manager and SM was decided to be someone who would help others when needed.
It was necessary to clarify the tasks for each role. SM was responsible for establishing the Scrumban method into the working environment, upholding the agile tools used, find- ing new ones to make the team more efficient, and working on project tasks. The PO had the final say on the tasks and giving them priorities, and rest of the team became the development team members mainly responsible for improving the application.
SM and the development team started working on the old product backlog and changing it to match the tools they were using. This included changing all the columns except the product backlog one. Starting by adding the sprint element to each column, the product backlog would have to do, working, testing, and done columns for each sprint. Also, adding a missed column for tasks that were not done during the sprints was necessary, because there were tasks that did not get completed during the sprints. These columns would leave a trail on how the team has managed during each sprint. Image 6 shows the result of the product backlog.
24
Image 6. Trello product backlog of the Scrum Team, the columns are from right to left Product Backlog, Sprint 9 (week 17 & 18) To Do, Sprint 9 (week 17 & 18) Working, Sprint 9 (week 17
& 18) Testing, and Sprint 9 (week 17 & 18) Done, and Sprint 9 (week 17 & 18) Missed.
The next step was to organize the daily scrums; each daily scrum was held every morn- ing at 8:30 and lasted the maximum of fifteen minutes. During daily scrums, each team member told others what he or she had done since the previous scrum meeting, what to do next and finally, if there had been problems with the tasks.
If for any reason a team member would start talking during someone else’s turn about the subject at hand or anything unrelated to the subject, the SM was responsible to jump in and get the daily scrum back on track. First by defusing the situation by telling the members who were having a conversation “This seems like an important subject and you both have knowledge about it, could you take a moment and continue after the daily scrum” or something along those lines. Then the SM asked the person whose turn it was to continue. SM recommended that people take notes during daily scrums and once the daily scrum is over, talk about the problem or even hold another meeting on the subject.
Facing new technologies, the team saw it necessary to create new tasks whenever it was needed during a sprint.
These four tools of Scrum, namely the daily scrum, product backlog, daily scrums, and sprints, made it easy to follow the progression of the project. Anyone could look at the product backlog, which was up-to-date, and see what the team was working on.
25
4.2 Interviewing Agile qualified engineers on Kanban and Scrum
Since the project team was using the Scrumban Method, three qualified Agile profes- sionals were interviewed by the SM, each one separately. Two of them were certified scrum masters, while the third was a certified SAFe DevOps Practitioner.
First part of the interview was about Scrum methodology: whether they had used Scrum, what the roles in it are and what the responsibility of each role are. Also, whether they were familiar with the tools used and how they had used them, and what are story points, were discussed during the interviews. The three had used Scrum and the tools used were daily scrums, scrum of scrums, sprints, retrospective, and sprint review.
The roles were PO, SM and Development team. PO being the bridge between the de- velopment team and stakeholders. When planning the product backlog, the stakeholders might be too active in the project leading to every stakeholder wanting different priorities and the POs task will be to decide the priorities [20]. SM could be a person with no technical expertise, but some thought they had to have technical expertise. The tasks for SM were basically planning the product backlog with the PO and afterwards with the Development team. Tasks for the development team would be reworked according to the vision of PO into smaller tasks in the product backlog, by the development team and SM. The development team would also be responsible for developing the product. An optimal development team would be full stack developers, but because it would be very expensive, as a team they would cover all the areas needed to complete a project. [20]
[32] [33]
Daily scrums were held for fifteen-minutes every morning with the questions, what the team had accomplished, what they will continue working on and do they have any prob- lems. Scrum of scrums was a higher level of daily scrum where scrum masters gathered and answered the same questions, another difference is if another team had a problem, other SMs could elaborate if they have had same kind of problem before and arrange a meeting on the topic between the teams [20]. If for some reason a team member could not make it, the team could post on Teams or Slack, these are tools used by software development companies, what they have accomplished [20] [32].
26
Story points are a measurement decided by the team, it can be a day, the team could decide that one SP is the easiest task and scale SPs for other tasks accordingly [32], or individual work for each person working on a task [20]. There is a tool that can be used for the team to measure together the worth of a task called Planning Poker, it is a way for each team member to vote the number of SPs each task is worth [33].
Sprints were two weeks, where each sprint focused only on one functionality. Each task needed to be completed and thoroughly tested [20] [32] [33]. Planning was the first and last thing each sprint, where the sprint backlog was completely planned [20]. If any new tasks were necessary to add would mean the sprint would ‘overflow’ and have too many tasks, which could lead to the halt of the sprint and require to plan a new sprint [20].
These would happen only in extreme exceptions [32].
Retrospective, planning and sprint reviews or sprint demo were a combined event that could take up to a whole workday [20] [33]. These tools included reviewing of the product with the stakeholders and having the team go through the last sprint if anything needed improving and the planning of the sprint.
Second part of the interview was about Kanban, how it works and how it differs from Scrum. Kanban is a method that is more flexibility with no other strict deadlines than the product release date. It is a method that requires a lot of communication between the team and not many tasks are worked at once and PO is responsible, like in Scrum, to priorities tasks. But instead of sprints there are weekly meeting with the PO and possibly with the stakeholders, where the team demonstrates the completed work [33].
The accomplishment of these interviews was the expansion of agile knowledge for the team and increasing the understanding of methods and tools that were commonly used by other software development teams and companies.
4.3 Updating, Upkeeping, and Improving Scrumban
At the beginning there were some issues on the upkeep of the product backlog, forgetting to add tasks, moving the tasks from one phase to another or forgetting its existence were the typical once. Daily Scrums were always held normally and afterwards a short meeting
27
if anyone had anything to add to the project, new ideas, next priorities that had to take place, and problems with tasks.
Scrum’s retrospective and sprint review tools were then implemented to improve each sprint. Holding the first session with both the tools where all team members and SM had to attend and speak about the project, essentially making the team strive for the same goal together. Retrospective gave the team a way to freely communicate on the ups, downs, and improvement ideas on the sprints, it also became the sprint planning where everyone planned the number of tasks that they thought could be managed, what the priorities were for this sprint and was any of the missed sprint tasks still high priority, could the members start working on the tasks next or should they be moved back to the product backlog column.
Having too many tasks on the product backlog during sprint was common, the team needed a way to make it more predictable. An estimation was created and marked as Story Points (SP) being a weeks’ worth of work, or story marks being a days’ worth of work.
Story Points were mentioned by all three interviewed engineers in chapter 4.2. SM cre- ated a system which would include SPs and planning poker, removing the story marks completely. On the next Retrospective, the team decided together to test these methods.
Once story points were decided on the next step was to plan what each tasks value would be. The scrum team (PO, SM, and development team) decided to test planning poker to vote for story points required for each task on the next sprint. In Image 7, only SM and the rest of the development team voted. It was done this way because the PO was unsure how to evaluate the tasks. This made it easier for the team to discuss about each task and each member would be heard.
28
Image 7. First try for the teams Planning Poker.
After one try planning poker became a part of every sprint review, the more it was used by the development team, the less tasks were missed. It became a lot easier to plan each sprint knowing the approximate amount of work that could be done.
Another finding concerning the tasks was the size of them, if there were bigger tasks, for example something closer to a user story, it had to be split into smaller tasks. Having encountered this during a Retrospective session a recommendation to keep the large tasks but creating small tasks that were then linked to a task, an example in image 8.
This would continue to leave a trail when each task was completed.
29
Image 8. Larger task with phases given SPs for the work for each smaller task and what the smaller task number is.
Scrumban made it possible to build a method in an image that supports the development team to stay on track during the project and bring value to the stakeholders.
5 Discussion and Conclusion
Agile methods provide all the tools for a software development team to work in an envi- ronment that challenges them and gives the team the flexibility to satisfy customers.
However, agile frameworks require the teams to be self-sufficient and able to manage the project. The agile methods give the guidelines when implementing the methods, not a guide on how it is done, which is the reason why companies and other teams use the methods slightly differently. There are many ways agile methods are used and it all de- pends on how the development teams learn to use them. Because there are many ways to use the tools of the methods, the only way to truly know if a tool is useful is to try it.
Scrumban was a method where the best features of Kanban and Scrum are gathered for the team. The implementation of the Scrumban gave the group of students the
30
opportunity to try out both Kanban and Scrum. The idea behind so many Scrum methods was to give the perspective of how these methods could be used in the working environ- ment and what everyone could be expecting when they start working for different com- panies.
However, there were quite a lot of mixed thoughts during the implementation and im- provements of the Scrumban method. The tools that made sense from the get-go were daily scrums and the product backlog. These tools once put into motion, became a part of the project management without issues.
Adding the sprints to the method felt like the right thing to do and it gave clarity on how much work could be done during a short period of time. But it felt like the team lost a sometime on them as well. Each sprint would require one day where the team would plan each sprint. Those were days when both retrospective and sprint reviews were held.
The scrum retrospective part was very important for each sprint because it gave a voice to the concerns inside the team. Every member could talk about problems they had with the sprints, which then could be solved together and only if every member agreed to it, would the solution be put in place or at least tried out. When the tool was implemented, it was quite plainly used, the Scrum Master not really knowing what questions to ask and what the issues could be with each sprint. It took a few weeks to get it going in the direction of improving sprints.
Sprint reviews gave the team guidelines how to present their work they had managed to accumulate during the sprint. This tool also implemented quite simply, just by having a simple presentation on the current product and adding images for comparison. The rea- son the product was not shown but pictures was because the project was mainly refac- tored.
Another problem with the sprints was that each member had one day a week to write their thesis, which gave the sprints a distorted picture of the whole process. In the end it felt like the team could have worked without the sprints and focus on having weekly meetings with the customer where all work done was presented.
31
The Scrumban method gave a chance for the team to try out new ways of working. Only through trial and error and experimenting with different Agile tools could the team find the right tools to work with.
32
References
1 Nokia. 2020. Our History. <https://www.nokia.com/about-us/company/our-his- tory/>. Internet material. Accessed 1.5.2021.
2 Varhol, Peter. To agile and beyond: The history and legacy of agile development.
<https://techbeacon.com/app-dev-testing/agility-beyond-history-legacy-agile-de- velopment >. Internet material. Accessed 15.4.2021.
3 Agile Methodology: A Beginners Guide to Agile Method and Principle. E-Book.
Accessed 4.5.2021.
4 Highsmith, Jim. 2001. Manifesto for Agile Software Development. <https://ag- ilemanifesto.org/>. Internet material. Accessed 15.2.2021.
5 Eby, Kate. 2016. Comprehensive Guide to the Agile Manifesto.
<https://www.smartsheet.com/comprehensive-guide-values-principles-agile-mani- festo>. Internet material. Accessed 15.2.2021.
6 Productboard Inc. 2021. Agile Values. <https://www.productboard.com/glos- sary/agile-values/>. Internet material. Accessed 20.2.2021.
7 Highsmith, Jim. 2001. Principles behind the Agile Manifesto. <https://agileman- ifesto.org/principles.html>. Internet material. Accessed 10.4.2021.
8 Stiehm, Tom. 2019. The Agile Manifesto Principles: Satisfy the Customer.
<https://www.coveros.com/the-agile-manifesto-principles-satisfy-the-customer>.
Internet material. Accessed 5.4.2021.
9 Coveros, Staff. 2019. The Agile Manifesto Principles: Deliver Frequently.
<https://www.coveros.com/the-agile-manifesto-principles-deliver-frequently/>. In- ternet material. Accessed 4.5.2021.
10 Coveros, Staff. 2019. The Agile Manifesto Principles: Self-Organizing Teams.
<https://www.coveros.com/the-agile-manifesto-principles-self-organizing-teams/>
Internet material. Accessed 10.4.2021.
11 Agile Business Consortium. 2014. What is DSDM? <https://www.agilebusi- ness.org/page/whatisdsdm> Internet material. Accessed 1.4.2021.
33 12 Boog, Jason. 2020. What Is DSDM (Dynamic Systems Development Method)?
<https://theqalead.com/topics/dsdm-dynamic-systems-development-method/> In- ternet material. Accessed 8.4.2021.
13 Agility, im. What is DSDM Atern? <https://agility.im/frequent-agile-question/what- is-dsdm-atern/>. Internet material. Accessed 9.4.2021.
14 Sharma, Lakshay. 2019. DSDM: A step-by-step-Guide [2019].
<https://www.toolsqa.com/agile/dsdm-guide/>. Internet material. Accessed 12.4.2021.
15 Sommerville, Ian. 2016. Software Engineering: Tenth Edition. Book.
16 ProductPlan. 2021. Lean Software Development. <https://www.product- plan.com/glossary/lean-software-development/>. Internet material. Accessed 4.5.2021.
17 Smart, Nigel J. 2013. An introduction to Lean biomanufacturing. <https://www.sci- encedirect.com/topics/engineering/lean-philosophy> Internet material. Accessed 22.4.2021.
18 Render, Joshua. 2019. What is Osmotic Communication? <https://agile-mercu- rial.com/2019/01/26/what-is-osmotic-communication/>. Internet material. Ac- cessed 24.4.2021.
19 <https://www.visual-paradigm.com/tutorials/agile-tutorial/how-to-identify-scrum- project-stakeholders>. Internet material. Accessed 24.3.2021.
20 Kröger, Pyry. Active Scrum Master. Interviewed 18.3.2021.
21 Scrumorg. 2021. What is a Scrum Master? <https://www.scrum.org/re- sources/what-is-a-scrum-master>. Internet material. Accessed 28.3.2021.
22 Techno-PM. 2017. Scrum Board: 4 Templates and Examples.
<https://www.techno-pm.com/2017/05/scrum-board-example.html>. Internet ma- terial. Accessed 4.5.2021.
23 Scrumorg. 2021. What is a Daily Scrum? <https://www.scrum.org/re- sources/what-is-a-daily-scrum>. Internet material. Accessed 30.3.2021.
24 Scrumorg. 2021. What is a Sprint in Scrum. <https://www.scrum.org/re- sources/what-is-a-sprint-in-scrum>. Internet material. Accessed 1.4.2021.
25 Chick, Timothy A. 2014. Figure 6. <https://www.researchgate.net/figure/Sample- Release-Burn-Up-Chart_fig7_266049888>. Internet material. Accessed 4.5.2021
34 26 Wikipedia. 2021. Burn down chart. <https://en.wikipe-
dia.org/wiki/Burn_down_chart>. Internet material. Accessed 4.5.2021.
27 Scrumorg. 2021. What is a Sprint Retrospective? <https://www.scrum.org/re- sources/what-is-a-sprint-retrospective>. Internet material. Accessed 2.4.2021.
28 digité. 2021. What is Kanban? <https://www.digite.com/kanban/what-is-kanban/>.
Internet material. Accessed 17.4.2021.
29 kanbanize. 2021. Kanban Explained for Beginners | The Complete Guide.
<https://kanbanize.com/kanban-resources/getting-started/what-is-kanban>. Inter- net material. Accessed 18.4.2021.
30 ProductPlan. 2021. Scrumban. <https://www.productplan.com/glos- sary/scrumban/>. Internet material. Accessed 26.4.2021.
31 Keup, Megan. 2020. What Is Scrumban? How It Differs from Scrum & Kanban.
<https://www.projectmanager.com/blog/what-is-scrumban>. Internet material. Ac- cessed 26.4.2021.
32 Anonymous Software Engineer. Certified Scrum Master. Interviewed 16.3.2021.
33 Anonymous Software Engineer. certified SAFe DevOps Practisioner, Interviewed 24.3.2021.
