INF5890: IT and management · 3/14/13 1 INF5890: IT and management Managing Systems Development Processes – including Scrum and Kanban Professor Dag Sjøberg email: [email protected]

3/14/13

1

INF5890: IT and management Managing Systems Development Processes – including Scrum and Kanban

Professor Dag Sjøberg email: [email protected]

INF5890 / © Dag Sjøberg 13.3.2013, Slide 2

Plan –  Fundamental process concepts –  A study of concrete development processes –  Agile software development –  Flow-based agile development (Kanban) –  A study of Scrum versus Kanban in a software

company

3/14/13

2


Management tasks

•  Management tasks –  Budget and costs –  Time schedules and progress –  Quality and risks –  Development team

•  Development methods and process will affect these management tasks


Overall responsibility of project manager •  Contribute to developing, extending and

maintaining IT systems within agreed –  quality –  time and –  cost limits

•  This requires good processes

3/14/13

3


What is a process? •  – a set of activities carried out to fullfil a job

•  Usually wish to run a process that is carefully planned

•  Everything we do involves processes, for example

n  Plan a project n  Prepare a meeting n  Write a requirements

specification

n  Design a web-site n  Program a function n  Run a test


3/14/13

4


System Development Process

•  System development process (= software process): the activities that are performed to develop a software system and the way they are performed

•  The activities vary, but will always includes the elements: –  Specification of requirements, that is, what the system

should do –  Design of the system –  Coding (programming) –  Validation that the system satisfies the needs of the

customer or user –  Evolution of the system, that is, changes according to new

or changed requirements


Process affects both project and system •  The development process, and the context in which it is performed,

affect the quality of both the project itself and the resulting system being developed

•  The process, the way one works, also affects the work environment (work satisfaction, motivation, competence development, etc.), which in turn will affect project and product quality in general

3/14/13

5


Aspects of process

•  Which activities are included in the process? •  How much effort is spent on the various activities (in absolute

and relative terms? •  What is the emphasis on the various activities during the

development? •  The process also includes

–  Which and the way methods, practices, tools and technique are used –  Parts of the products/results of an activity –  Roles of those involved in the process –  Pre- and post-conditions that are true before and after a phase or a

sub-product is produced


Examples of roles •  Developer •  Maintainer •  Architect/System designer •  Graphical designer •  Tester •  Project manager •  User/customer representative

Employing a project with the appropriate competence is far from trivial!

3/14/13

6


Examples of tools

Tools for: •  Development (IDE) •  Configuration/change management •  Testing •  Diagram construction •  Project management •  Bug & issue tracking

Choice of tools is also not trivial


Process model •  System development process (=actual, real process)

–  Those activities that are carried out in a development project

•  Process model (= formal process) –  An abstract representation of a process. The model describe the

process from a certain perspective

•  A process model may be –  Descriptive: describes an actual process the way it is –  Prescriptive: describes a process the way it should be (the most

common meaning)

3/14/13

7


Model versus reality


Formal versus real process

What we tell we do or should do

What we do

3/14/13

8


Levels of process models

General process models (waterfall, spiral, RUP, Scrum, etc.)

Company-specific process models

Project/group-specific process models

System development process

Process conformance

Defined process- models

Real process


Models for development processes

Model

Waterfall (plan-driven)

Incremental (plan-driven

or agile)

Evolutionary (plan-driven

or agile)

Define all

requirements first

Yes

Yes

No

More

cycles?

No

Yes

Yes

Distributed

increments?

No

May be

Yes

req. design

code test

deliver

deliver

req. design

code test

deliver

design code

test

req.

design code

test deliver

test

code

req.

design

deliver

req.

3/14/13

9


Choosing processes

Suppose you are an IT manager (project leader, head of department, etc.), which processes would I prefer in my project or department?


Suitability of processes (and methods and practices) depends on:

•  Systems to be developed •  Culture, competence and resources by

–  Customer –  Development organization –  Project

3/14/13

10


How to adapt processes?

•  Processes must be adapted – no projects are qual •  What can be adapted?

–  Number and type of phases and activities, roles, documents, formality and frequency of reports and meetings

•  How to adapt? –  Identify the project environment: development strategy, risks,

requirements, etc. –  Elicit opinions of developers, users, customers –  Define process model, activities and roles –  Document the adaptations and their justifications



company

3/14/13

11


A study of concrete processes

•  What kind of process is useful in which situations? •  Little exact knowledge in the area, very much hype

and subjective opinions •  A study the effect of various aspects of context and

process


Bid from 35 companies Four companies built the same system

0

100000

200000

300000

400000

500000

600000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Bid (Norwegian Kroner)

Firm A D B C

3/14/13

12

Variation in bids between IT and road projects

0

1,000,000

2,000,000

3,000,000

4,000,000

5,000,000

6,000,000

7,000,000

8,000,000

9,000,000

1 2 3 4 5 6 7 8 9 10

3 X

0

100000

200000

300000

400000

500000

600000

*H. Pedersen, “Tender Prices: Bridge, Tunnel, Electro and Road Building and Maintenance 1998-2006”, Technology Report 2468, Norwegian Public Roads Administration, 2006

*


0 100 200 300 400 500 600 700 800 900

1000

A B C D

Project quality System quality Poor

0

20

40

60

80

100

120

140

160

180

Kundeinnsats (timer)

Tid til ferdig (dager) Overskridelse tid (%)

A

B

C

D

Customer effort Lead-time Lead-time overrun (hours) (days) %

Reliability Usability Maintainability (defects)

Goo

d

Goo

d

Poor

0

1

2

3

Pålitelighet (feil) Brukervennlighet Vedlikeholdbarhet

A

B

C

D

Result

Hours

3/14/13

13

Project(Management( Unspecified( 163(Project(Management( Project(Management( 59(

Project(Management(Communication/Internal(Management( 48(

Project(Management( Project(initiation(and(planning( 21(

Project(Management(Communication/External(Management( 14(

Project(Management( Project(meetings( 9(Project(Management( Initial(meeting( 6(Project(Management( Preparations( 4(Requirements( Unspecified( 16(Requirements( Use(case(diagrams( 4(Research(Contribution( Unspecified( 111(Research(Contribution( Logging(of(activities( 31(Research(Contribution( Interviews( 14(Research(Contribution( Copy(documents(and(code( 10(Research(Contribution( Wrap(up(activities( 1(Technical(Documentation( Unspecified( 73(Technical(Environment(Unspecified( 74(

Technical(Environment(Establish(development(environment( 41(

Technical(Environment(Establish(web(environment( 17(Technical(Environment(Establishment( 9(Technical(Environment(Establish(test(environment( 3(Technical(Environment(Establish(database( 2(Test( Unspecified( 47(Test( Accomplishment(of(test( 19(Test( Functional(test( 17(Test( Documentation( 6(Test( Planning(test( 4(Test( Testdata( 1(Training( Unspecified( 6(User(Documentation( Unspecified( 19((

Activity Sub-activity Hours Activity Sub-activity Hours


Process activities in the four companies Hours

0

50

100

150

200

250

300

350

400

450

500

A

B

C

D

3/14/13

14


Relative emphasis of the activities Percent time

0

10

20

30

40

50

60

A

B

C

D


Time spent by the companies along the way

Sum(Hours)

Week

Company=A

Company=B

Company=C

Company=D

0

25

50

75

100

125

150

Sum(Hours)

0 2 4 6 8 10 12 14Week

3/14/13

15


A B

DC

Emphasis along the way


Examples of context variables

3/14/13

16


Examples of process variables Company


Context and process matter

•  Many context and process parameters will influence project and system quality

•  The choice of parameters will depend on which quality aspects one would like to emphasize

•  The systems described above are small, but there are many such systems! (and smaller additions to larger systems may have similar project size)

3/14/13

17



company


The waterfall model

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

3/14/13

18


Need for agility

•  The classical engineering approach is often unsuitable in software projects

•  Alternative: “agile software development” –  Focus on code instead of (comprehensive) design and

documentation –  Collaboration with customer instead of contract negotiation

–  Faster delivery of code and faster adaptations to changed user requirements


Plan-driven (heavy) processes

•  The activities are planned in advance and progress is measured according to this plan

•  A heavy process includes many activities and roles, and requires formal, detailed and consistent project documents

•  Heavy processes are often “front heavy”, that is, emphasise activities that are usually carried out early in the process (planning, analysis & design)

Agile (light) processes

•  Incremental planning •  Easier to adapt the process to

changing requirements •  Light processes focus more on

fundamental process (e.g., continuous testing), have fewer formal documents and are often more iterative

3/14/13

19


Scrum

Outline planningand architectural

designProject closure

Assess Select

Review Develop

Sprint cycle

The results are evaluated against the goals and presented for the customer

In the sprint planning meeting, the product backlog (list of work items) is evaluated. Goals for the sprint defined, including priorities and risks. The customer may define new requirements or give new tasks.

The development team and customer decide features and functionality to be developed during the sprint

Design, coding, testing. The development team isolated from the customer and rest of organization, that is, all communication by Product Owner/Scrum master to avoid distractions

2-4 weeks

Develop documentation (help functions, user manuals) and summarize what was learned

Input: Product backlog – list of work Items


Timeboxing versus “task-boxing”

•  Scrum has sprints (iterations) of 2-4 weeks. But not always easy to divide the tasks or features of the systems to fit into such time intervals

•  What about instead define a set of tasks or features and deliver when finished?

3/14/13

20



company


Flow-based Development

3/14/13

21


Lean production •  “The Japanese school”, primarily Toyota

–  If failure discovered, stop the assembly line and find the reason for the failure instead of collecting and fix the failures in bulks

–  Continuous learning and improvement (Kaizen) –  “Just-in-time” (JIT) principle: don’t produce anything before somebody

demands it –  Tempo in production determined by pull from customer or next

element in the production chain rather than push internally to produce as much as possible

–  Removal of temporary storage –  Component-based production (same chassis, bumper, etc. on

different car models). This way production can be geared towards the customer and components can be outsourced to third-party vendors

•  Result: Toyota fewest failures and fastest production •  The most productive factories spent least resources on management and

administration (”lean management”)

From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009

Kanban board �  A Work Item represents a unit of work to be carried out by the development team

�  Describe a Work item on a post-it sheet and put it on a board in one of the categories : ”To do”, ”In progress” or more detailed states. ”Done” shows the Work Items that are finished

3/14/13

22


Scrum board versus Kanban board

From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009

Max WIP


Kanban principles

•  Limit Work In Progress (WIP). The more work items in parallel, the slower they flow through the work processes

–  WIP limit may be put on the total number of active work items or on the number of work items in a given state (to reduce bottlenecks)

•  When a work item is finished, one can request to work on a new one (pull)

•  To optimize flow, slack in the time schedule is OK. That is, a developer may have some waiting time now and then to optimize the overall flow

•  Little focus on estimation

3/14/13

23



company


Questions •  Kanban claim: A fixed WIP (Work In Progress) will improve the

process quality. Will it help to reduce the number of active WIs in total or by state?

•  What’s the mutual relationship between lead-time, productivity and quality?

•  How does Kanban vs. Scrum perform with respect to lead-time, productivity and quality?

•  To get more insight, we ran a study at Software Innovation:

Dag I.K. Sjøberg, Anders Johnsen and Jørgen Solberg: Quantifying the Effect of Using Kanban versus Scrum: A Case Study. IEEE Software, Vol. 29, Nr. 5, side 47–53, Sep./Oct. 2012

3/14/13

24


From Scrum to Kanban in Software Innovation (SI)

•  Scrum from 2007 •  Kanban from 2010 -> •  Why change to Kanban?

–  Increase production –  Improve project and product quality

•  Were the expectations met? •  Analysis of 12 000 work items over 3 years recorded in

Team Foundation Server (TFS)


Said about measurement

Lord Kelvin

In God we trust, all others bring data – W. Edwards Deming

To measure is to know. If you cannot measure it, you cannot improve it. Lord Kelvin

Not everything that counts can be measured. Not everything that can be measured counts. Albert Einstein

3/14/13

25

Measuring the effect of processes Example from [Sjøberg et al., IEEE SW 2012]


Lead-time

•  Normal definition: –  the time from a customer issues a request for a new or

changed feature until it is implemented and deployed in the customer’s environment

•  In the context of SI, which is an in-house development company:

–  The time from the team receives the request (state “Next”) until it’s ready for release (state ”Ready for release)

3/14/13

26

WI_ID Title Business Value

Tes1ng Impact Customer Lead

Time Lines Added

Lines Modified

Lines Deleted Churn Team

19363 Fix Unit tests 3 -‐ High XX 0 19363 Fix Unit tests 3 -‐ High xx 1 2 31 27 60 30921 Allow access to documents xx 0 33442 TFS Backup Plan 810 Internal 0 33442 TFS Backup Plan 810 Internal 0 33442 TFS Backup Plan 810 Internal 56 0 0 0 0 33732 Need a new Test server for 360 Arabic Internal 0 33732 Need a new Test server for 360 Arabic Internal 4 0 0 0 0 42868 Need few 150 machines to be UP 3 -‐ High Internal 0 42868 Need few 150 machines to be UP 3 -‐ High Internal 0 49723 Separate machines for Msk Internal 0 49723 Separate machines for Msk Internal 0 49723 Separate machines for Msk Internal 1 0 0 0 0 19363 Fix Unit tests 3 -‐ High 0 19363 Fix Unit tests 3 -‐ High 1 2 31 27 60

Process Product WI_ID Type State From State To Direc1on Date From Date To

Scrum ProArch 19363 Bug In Progress Done 1 16.04.201001:02:00 16.04.201009:10:25 Scrum ProArch 19363 Bug Not Done In Progress 1 15.04.201015:01:29 15.04.201015:01:37 Kanban ProArch 30921 PBI Analysis-‐In Progress Analysis-‐Done 1 26.11.2010 03:00:48 26.11.2010 06:00:26 Kanban Common 33442 PBI Development-‐Done Released-‐ 1 02.02.2011 03:13:07 02.02.2011 08:50:51

Kanban Common 33442 PBI Analysis-‐Done Development-‐In

Progress 1 17.01.2011 06:29:16 17.01.2011 06:29:31 Kanban Common 33442 PBI Next-‐ Analysis-‐In Progress 1 08.12.2010 14:27:41 08.12.2010 14:53:48 Kanban Common 33732 PBI Development-‐Done Released-‐ 1 13.12.2010 13:39:28 13.12.2010 13:40:10 Kanban Common 33732 PBI Next-‐ Analysis-‐In Progress 1 10.12.2010 10:18:11 10.12.2010 10:43:54 Kanban Common 42868 Bug Development-‐Done Released-‐ 1 03.02.2011 07:47:07 03.02.2011 07:47:41

Kanban Common 42868 Bug Analysis-‐Done Development-‐In

Progress 1 02.02.2011 13:55:29 02.02.2011 13:55:46 Kanban Common 49723 PBI Development-‐Done Released-‐ 1 10.03.2011 06:16:18 10.03.2011 06:16:31 Kanban Common 49723 PBI Released-‐ Development-‐ -‐1 10.03.2011 06:11:17 10.03.2011 06:14:32 Kanban Common 49723 PBI Next-‐ Released-‐ 1 10.03.2011 06:08:01 10.03.2011 06:11:17 Scrum ProArch 19363 Bug In Progress Done 1 16.04.201001:02:00 16.04.201009:10:25 Scrum ProArch 19363 Bug Not Done In Progress 1 15.04.201015:01:29 15.04.201015:01:37


Implementation of Scrum

•  Cross-functional teams –  the team contains all the skills needed to complete all the items in

the iteration •  Sprint planning meetings that included estimation of work

items using planning poker •  Daily standup meetings •  Sprints of three weeks

–  shippable increments of code (fully tested) at the end of each sprint –  demos in the review meetings

•  Status visible through automated reports and task boards for all of the teams

3/14/13

27


Implementation of Kanban

•  When started on an item, attempt to let it flow until it is ready for release at a satisfactory quality as soon as possible (fast delivery without timeboxes)

•  Limited number of work items in progress at the same time (WIP limit) •  If WIP limit reached, work will not start on a new item before another

one is finished (just-in-time) •  No cross-functional teams •  Abandoned start-up meetings with estimation of work items •  Still daily stand-up meetings •  Demos once or twice a week, regardless of the progress of the work

items being discussed

Lead time

3/14/13

28


Bugs


Productivity

3/14/13

29


Conclusions

•  By replacing Scrum with Kanban, SI –  Almost halved the lead time –  Reduced the number of bugs by 10% –  Improved productivity

•  SI appears to benefit from using Kanban over Scrum •  Kanban should be considered by other companies that

–  Difficulties with estimation –  Interruptions due to ad hoc-bug fixing, support and

maintenance tasks


INF5181 - Process improvement and agile methods in systems development •  Course content

–  History and concepts of software process improvement –  Process improvement frameworks –  Software development processes and methods, in particular agile methods –  Assessment and measurement in software development processes –  Research Methods –  Learning and change in individuals, groups and organizations –  Group dynamics

•  Learning outcomes –  At the end of the course you will –  have gained a good understanding of modern software development

processes, including Lean and agile methods –  know the characteristics and effects of the different development

processes –  be able to contribute to efficient organization, conduct and improvement of

software development processes

Documents

INF5890: IT and management · 3/14/13 1 INF5890: IT and management Managing Systems Development Processes – including Scrum and Kanban Professor Dag Sjøberg email: [email protected]