• Ei tuloksia

Scrum is derived from complex adaptive systems theory. Creation was influenced by lean development principles which derive from Japanese industry, along with knowledge management strategies. (Sutherland & Schwaber, 2011;

ScrumAlliance, 2018)

Scrum is an iterative and incremental framework for product development in any domain. Development cycles are structured into sprints. Individual sprint iterations length is no more than one month. Sprints take place one after the other without pause, and they are time boxed. Time boxing means that sprint ends on a specific date whether the work has been completed or not. (Sutherland &

Schwaber, 2011; Cohn, 2010)

FIGURE 34 Scrum process cycle (Schlauderer et al., 2015)

At the beginning of a sprint, a cross-functional team selects items (desired functionalities) from a prioritized product backlog. Team decides on a sprint planning meeting how much work can be completed during a sprint; this forms a sprint backlog. During the sprint there are no changes to duration or goal. Team conducts daily scrum meeting to inspect progress and adjust work which is needed to complete the sprint backlog. At the end of each sprint is a review, in which the team reviews the results with stakeholders and demonstrates what has been developed. Sprint review provides feedback that can be incorporated into next sprint goals. Sprint retrospective is team’s internal feedback meeting. Scrum emphasizes achieving “definition of done” (DoD) in each sprint. In the case of software development this means code that is integrated, tested and potentially shippable – it has some value and encourages feedback. (Sutherland & Schwaber, 2011; Cohn, 2010)

There are three roles in scrum: scrum master, product owner and the team.

These three entities form the scrum team. Scrum master coaches the team on applying scrum, she is not a manager. This means that scrum master does not tell the team what to do or assign tasks. She facilitates the work by supporting team’s self-organization and management. Her responsibility is to do whatever in range of realistic possibilities to help the team and product owner on achieving goals.

This includes for example guidance on the use of scrum, protecting the team from outside interference and removing impediments. (Sutherland & Schwaber, 2011;

Cohn, 2010)

Product Owner is responsible for maximizing return on investment (ROI).

She identifies product features and translates these into a prioritized product backlog. Product owner interacts with the team actively offering priorities and reviewing the results of sprints, she makes sure that team is advancing to the right goal. (Sutherland & Schwaber, 2011; Cohn, 2010)

Small crossfunctional team develops the actual product, or its increment.

Crossfunctionality means that the team has all required capabilities to deliver the

potentially shippable increment in each sprint. If team size is more than ten individuals, it usually creates unnecessary communication and coordination overhead. Teams are also self-organizing which entails both autonomy and accountability. Autonomy means that the team has best insight to what can be accomplished. Product development includes providing ideas for product owner on how to make the product even better. Teams are most productive and effective when all members are dedicated to the given product versus avoiding multitasking in several products or projects. (Sutherland & Schwaber, 2011; Cohn, 2010)

To highlight, there is no project manager in scrum. Responsibilities of a project manager are divided and assigned for the three scrum roles. The word scrum master was invented in 1997 by Ken Schwaber, partly as a reminder that this role is not a traditional command and control project manager. Managers outside the scrum team may also be called upon to change their management style. For example, tactful questioning may help the team to discover best possible solution to a problem, rather than simply deciding on a solution and issuing it for the team. (Sutherland & Schwaber, 2011; Cohn, 2010)

Another agile development practice that is sometimes assimilated to scrum is Kanban. Its roots are in the Toyota’s just in time production system. The management tool used to operate this system is Kanban, which translates to visual card. Main function is to limit anything excessive, especially work-in-progress. Like Scrum, Kanban is agile, transparent, adaptive and empirical, but it is even more configurable than Scrum. This means that fixed backlogs and time boxing are optional. In place of product and sprint backlogs is one or several Kanban boards, which present for example variable backlog, ongoing work, completed items and in production items. Board’s content can be changed depending on capacity and/or demand, and it has no prescribed layout. Other key differences are that in Kanban specialist teams are allowed, and roles are not fixed. Scrum is more prescriptive and has more constraints, it focuses on iterative project work. Kanban on the other hand focuses more on the management of continuous workflow. (Kniberg & Skarin, 2010; Sugimori et al., 1977)

Benefits of agile implementation are recognized by Laanti (2012) in her dissertation. Figure below depicts a model from real world experiences in adapting agile practices (enablers) from Scrum and extreme programming. Goals represent the benefit for conducting agile transformation. Means are mechanisms for gaining value from the agile practices. (Laanti, 2012)

FIGURE 35 Agile goals, means and enablers (Laanti, 2012).

Agile practices often create productivity, quality and better morale within the teams as well as other benefits (VersionOne Inc., 2018). Agile practices can also be combined like any other practices. There is no value in following one practice and disregarding others due to dogmatism. (Kniberg & Skarin, 2010) The following question is how to manage the agile teams in an enterprise environment. Because teams cannot be agile if the organization is stiff, or can they? Next chapters try to cover this question.