Research and Refine Research Topic

Agile_SAP_Introducing_Flexibility_Transparency_and..._----_Chapter_1_Introduction_to_Scrum_and_Kanban.pdf

Home >Business & Finance homework help >Operations Management homework help >Research and Refine Research Topic

CHAPTER 1: INTRODUCTION TO SCRUM AND KANBAN

This section provides an overview of Scrum and Kanban. These two approaches are considerably different, and each has their place, depending on a number of criteria. Following an overview of the two approaches, I provide you with the information you need in order to select the correct approach.

Scrum Scrum was developed by Jeff Sutherland and Ken Schwaber in the early 1990s. It is an approach that most readers will be familiar with, because it uses time boxed iterations. When most people think of Agile, they think of dividing the project functionality into iterations of a couple of weeks, to one month. Scrum calls its iterations, “sprints,” and the goal of each sprint is to build a tested, workable piece of the system, that is ready to be released to production.

Scrum uses what is called a “product backlog,” to collect requirements and manage the scope. Each sprint builds a selected set of items from the backlog. A “product owner” is assigned to the project, and it is their responsibility to prioritize the backlog, to ensure that high value items are built first. Each sprint begins with a sprint planning meeting, where the product owner tells the team his preferred list of work for the sprint. The team then negotiates the sprint scope, based on their estimates. A conversation then ensues where the team gains a high level

Robson, Sean. Agile SAP : Introducing Flexibility, Transparency and Speed to SAP Implementations, IT Governance Ltd, 2013. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=1186297. Created from harrisburg-ebooks on 2020-11-11 04:38:06.

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

1: Introduction to Scrum and Kanban

understanding of the selected backlog items, and creates an initial draft of the tasks required to complete each selected item.

A unique aspect of Scrum is its approach to teams. There are no “unique” roles in Scrum, other than developer, ScrumMaster and product owner. The ScrumMaster is responsible for helping everyone understand the rules of Scrum, and is primarily involved in removing blocks that prevent the team from getting their work completed. The product owner is responsible for defining the project vision, deliverables and priorities. Other than the ScrumMaster and product owner, all other team members are referred to as “developers.” The reason behind this is to maximize collaboration within the team. The objective is for every team member to be able to perform every task on the project. This means that any one person should be able to perform requirements and design analysis, code, configure, test and write documentation. This generalization causes issues in the specialized world of SAP configuration (more on this later).

Although their recommended team sizes vary slightly, most Scrum experts agree that smaller teams perform better. Cohn cites a study of 491 projects that looked at the performance of teams varying from 1 team member up to 20 (Succeeding with Agile: Software Development Using Scrum). The study found that a “five to seven person team will complete an equivalently sized project in the shortest amount of time.” Jeff Sutherland writes that the “team in Scrum is seven, plus or minus two people” (Scrum Handbook). Due to the smaller team size, Scrum has a method of coordinating projects of larger sizes and refers to this as a “Scrum of Scrums.” A Scrum of Scrums involves ScrumMasters from each team meeting to coordinate work

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

1: Introduction to Scrum and Kanban

between the teams. In the Scrum of Scrum approach, planning must include careful consideration of dependencies between the teams, to help ensure that each team can proceed independently on their work as much as possible.

Another key item of Scrum concerns the notion of velocity. Scrum believes that only historical performance, or velocity, is a valid predictor of future performance. It uses the number of completed stories (features) per sprint, to estimate the team’s ability to complete deliverables.

A good overview of Scrum can be found at www.scrum.org/Portals/0/Documents/Scrum%20Guides/Sc rum_Guide.pdf.

Kanban Kanban has its origins in lean, and just in time, manufacturing processes. In Japanese, the term Kanban refers to a “signal card.” In manufacturing, the signal card is used to inform an upstream process that more of the product is needed by the downstream process doing the signaling. A person doesn’t begin any new work unless they have received a signal that more of the product is needed from their work step. Kanban was developed as a mechanism to help control scheduling of the work needed to produce a product. It serves a number of key purposes which center around visualizing work, so that producers know what needs to be produced, when it needs to be produced, and how much to produce.

David Anderson took Kanban principles and applied them to software production (Kanban: Successful Evolutionary Change for Your Technology Business). He found that the

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf

1: Introduction to Scrum and Kanban

core principles of Kanban served well to help address issues of waterfall software production. Specifically, Anderson was able to define a Kanban approach to software that allows its users to improve throughput and reduce leadtime.

Increasing throughput is an important goal for every project manager. In software, throughput is the number of work items completed in a given time period. Another goal of software project managers is to reduce leadtime. Leadtime is very similar to duration. According to Anderson, leadtime measures the duration “from starting a feature to completing it” (Kanban: Successful Evolutionary Change for Your Technology Business). By increasing throughput, the project is able to get more work done in a given time period. By decreasing leadtime, the project is able to more quickly deliver value to the customer. Anderson recommends a number of lean techniques to improve throughput and leadtime. These include, for example, reducing multitasking, addressing bottlenecks and roadblocks, and reducing waste.

We all know the perils of multitasking. Multitasking is a good way to do many things poorly. Yet on almost all projects we, as project managers, find ourselves overloading our team and asking them to get more done in less time. We try to pretend that the team has more capacity than it truly has. Once we start that method of working, it spirals, and we find that we can never catch up, because the team ends up with a stack of items in process that never seem to move to “done.” It is known that people become progressively less effective and less efficient with more concurrent tasks. On a software project this is revealed in lower quality work, and an increase in unfinished work. Kanban addresses this issue by recommending we define

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

1: Introduction to Scrum and Kanban

Work In Progress (WIP) limits for each of our work item types. A Kanban board visually shows how much work is in progress, and gives us a simple checking mechanism to ensure that the WIP limits are respected.

Kanban also provides us with a mechanism to address bottlenecks. Bottlenecks reveal themselves on a board when we see that a stack of work items has piled up at a given resource. The project’s job at that point is to identify methods to relieve the bottleneck. Methods can include, for example, improving our upstream processes to ensure that work arrives in a “ready to work on” state at the bottleneck point. If our bottleneck is a programmer, then we will want to ensure, for example, that test specifications are in a good finished state, so that the programmer does not require as much back and forth communication with the analyst. Another method is to redesign the work, so that the bottleneck does not have as much work on their plate. We can, for example, have non bottleneck configurators take on some of the bottleneck configuration, so that the bottleneck resource is not as overloaded. On one project I had a bottleneck in one module, and we took careful attention to review each work item assigned to the bottleneck to determine whether another team member had the necessary knowledge to take ownership of an item.

Blocks occur when a work item is unable to move forward, typically due to a late dependent item. In SAP this often occurs between modules, or between the development and configuration team when tasks run late. Avoiding and managing blocks requires careful planning of work dependencies in the backlog. If configuration work items run late, and the development team is started too early, then the development team will spend a lot of time “blocked” by the lack of configuration. The Kanban board can be used to

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

1: Introduction to Scrum and Kanban

quickly highlight these blocks and focus the team’s efforts on working to resolve the block. In many cases the development team can help with testing of configuration, in order to speed up closure of the dependent configuration work. This requires an investment in cross training, but can pay dividends later (more on this later). The development team may also have analysts who can work with the business to clarify requirements for the configurator, so that the configurator can complete work items faster.

The structure of a Kanban board helps us communicate priorities to the team. The Kanban board begins with an input queue. The input queue should be loaded with just enough work from the product backlog to keep the team busy for a week, and it should receive only the next priority items from the backlog. This ensures that the team pulls priority work into their work in progress.

Kanban uses five core properties to improve software development:

Visualize workflow Limit work in progress Measure and manage flow Make process policies explicit Use models to recognize improvement opportunities

(Kanban: Successful Evolutionary Change for Your Technology Business).

Later, I’ll show how each of these core properties can be used to improve an SAP project.

As in Scrum, Kanban believes that historical performance is your best predictor of future performance. In Kanban, one can use throughput, a measure of completed work items per time period, and leadtime, a measure of the duration it takes

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

1: Introduction to Scrum and Kanban

to complete a work item, to predict the time it will take to complete future work items.

If applying Kanban to your project, your team can benefit through a hands on, Kanban learning experience. There are numerous games that can be used to teach teams the value of using Kanban to manage project deliverables. These games typically teach participants the importance of pulling work through the system based on capacity, rather than pushing work through based on demand. One example game is the paper airplane game (www.shmula.com/paper- airplane-game-pull-systems-push-systems/8280/). By actively participating in such an exercise, the team learns that throughput and leadtime can be greatly improved by carefully managing WIP.

Scrum or Kanban? Projects can really leverage Scrum when teams are colocated. Colocation is important in Scrum, because each person is expected to be able to work on any task relevant to the sprint. Being able to work on a task with another team member, or pick up a task when it is partly finished, requires good communication amongst team members. Although Scrum has been shown to work with distributed teams, it definitely is better suited to colocation.

Scrum also works better when the tasks are more generic and require fewer specialists. At its core, Scrum aims at improving throughput, by ensuring that each team member has the skill to work on any task in the sprint. In this sense, Scrum works best in an SAP project that is more development focused. Projects that are heavy in configuration require specialists, and Scrum is not designed

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

http://www.shmula.com/paper-airplane-game-pull-systems-push-systems/8280/

1: Introduction to Scrum and Kanban

to accept a high number of specialists. A sprint that has high dependence on one or two specialists can experience stalls, as other members wait for the specialists to complete predecessor tasks. This can arise on a project where one module has significant configuration scope, and the project lacks sufficient capacity in that module. A sprint can stall if it is waiting on one or two team members to complete predecessor configuration. It may be possible to schedule around this configuration, however, the risk of delays is much higher on downstream tasks.

Kanban does not have any prescribed roles. It layers on top of existing methodologies and is used to optimize and improve the existing processes. It can work for distributed teams because it allows for specialist roles. Kanban is not time boxed, and does not prescribe regularly scheduled demos (although I do recommend you use demos in Kanban and schedule them “as needed,” according to readiness and client needs). For these reasons, Kanban is useful for projects that have significant configuration elements and distributed teams.

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .