Challenges of

Implementing SCRUM in a

Large Scale Public Sector

Project

Alar Huul Nortal

EMPIS and Alfresco

Project Manager

Purpose

• The purpose of the presentation is to share my

story and exchange experience

• The format is a hybrid of presentation and

discussion. I hope you’ll have many questions

My story

• Graduated Estonian IT College in ‘08

• Worked in IT Group for 4

• No SWD background before Nortal,

August 2010

e-Government

Energy & Resources

Manufacturing & Logistics

Telecom Public Finance Management

Healthcare Financial Services

Our Expertise Specialist Consulting User Experience & Design Software Development System Integration

Application Management Enterprice Content Management Open Source Technologies 24/7 Support

Nortal

1. Finland

2. Estonia (Tallinn & Tartu)

3. Lithuania

4. Russia

5. Serbia

6. Romania

7. Oman

First Chapter

The background of the team

Becoming agile

What is EMPIS?

The client: Eesti Töötukassa

Estonian Employment Information System

(EMPIS) is one of Nortal’s largest

development projects and the biggest in

Public Sector Business Unit. EMPIS is a web-based proceeding information system, enabling

quick and convenient registration of unemployed persons,

assigning unemployment benefits for them, offering various

services, intermediation of employment offers, signing contracts

with institutions, processing of procurements, etc.

EMPIS team

• EMPIS Nortal development team size in

total 19 FTE

– People: 22 +1

– 3,75 Analysts

– 11 Programmers

– 3,5 QA (testers)

– 0,75 Project Manager

EMPIS Contractual history

Contract Hours Sum EUR

Solution analysis 232,00 11 372,69 EUR

1. Phase (13.04.09-1.09.09) 8 180,00 292 766,48 EUR

2. Phase (19.05.10-1.03.11) 21 400,00 889 011,03 EUR

2. Phase +20% (12.09.11-31.10.11) 3 900,00 175 500,00 EUR

3. Phase (13.12.2011-01.04.2013) 40 000,00 2 000 000,00 EUR

3. Phase 20% (13.03.2013-04.09.2013) 8 000,00 440 000,00 EUR

4. Phase (25.07.2013-31.12.2015) 80 000,00 4 320 000,00 EUR

Total: 161 712,00 8 128 650,21 EUR

82 000 hours work has been done before the begining of „4. Phase“

10

What Paradigms Are We

Breaking?

Culture

Measure

of Success

Waterfall Development

Iterative Development Iterative and Incremental

Development

Parallel Development

Acceptance Test Driven

Development

Command-and-Control Leadership /Collaborative

Conformance to Plan Response to Change

Design

QA

Process

Big Design Up Front Continuous

Big Test on Backend Continuous

Agile Development

Scrum Framework

3 Roles 4 Ceremonies 4 Artifacts

Product Owner

The Team

ScrumMaster

Daily Scrum

Sprint Planning

Sprint Review

Retrospective

Project

Retrospective

Product Backlog

Sprint Backlog

Burndown charts

Impediment List

Challenges in 2010 • The development team was too big (19+1)

• Difficulties with managing the scope:

– Massive development sprints (up to 5000 hours work)

– Hard to fix delivery dates due to large scope • The Fund adds critically relevent tasks to the on-going sprint

• Due to the enormous scope size the testers could not estimate quickly the

precise completion of the sprint (when the work is done).

• Old project management tools. We didn’t have Atlassian’s JIRA for project

management

What did I knew?

Challenges in 2010

• Work distribution could have been more effective:

– Tasks that only one person could have done efficiently had

to be split between several developers

– Shared responsibility for closing big development tasks

– Insufficient overview of the scope and the due dates

• Daily Stand-up meetings took too much time

– Too much info to grasp (19+1)

– Difficult to track results

• A release after every 2.5 months, we aimed for 1 month but

some new functionalities took a lot of time to develop.

• After the release the QA engineers workload drop drastically

(picture)

17

Testers Race in the End of Sprint

• Development work often continues throughout the cycle, while the testing starts at the end of the cycle. As a result, not enough time can be allocated for the testing.

What did I knew?

How to become more mature?

How to lead change?

1. Build the leading team

2. Set goals with the team

3. The team development tasks are

part of the iteration (plan the time)

4. If change / improvement is not

fun…

Solutions (1/5)

Atlassian JIRA and Confluence in 2011 January

Split the team 2 * (5 developers + 2 testers)

Both mini teams have a work cycle of 2 months. It means the team can

deliver every month.

The model is scalable

Solutions (2/5)

Programmes in 2 mini-teams:

– Every miniteam has its lead developer

– Effective work distribution and precise personal

responsibility (one out of 6 vs. one out of 12)

– Good overview of everybody’s work and performance

(transparency)

– Problems rise faster in smaller teams!

• Miniprints in sprints (iterations)

– One iteration (sprint) is 2 months

– 3 mini-sprint after every 2 weeks, during one 2

months iteration to measure teams velocity (effort) in

the ongoing iteration

Minisprints in iterations

Solutions (3/5)

Testing (QA) in mini-teams

– Effective work distribution

– Stable workflow and less stress before the release

– At the end of the release the other mini-team’s testers can

help with Regression Testing

– 40% less bugs after live despite of quick performance!!!

Solutions (4/5)

• Daily Stand-up Meetings

– Faster - scrum max 7 min per mini team (before 20 min plus)

– More efficient – only the info that concerns the mini team, not

what’s going on with the whole development team (20 persons)

– The analysts do not take part in Daily Stand-up’s any more

(team Skype chat)

• The System Analysts

– One sprint ahead of both mini-teams development sprint

(specifications done)

– If the specifications are finished one sprint beforehand then the

upcoming sprints work forecast estimates are more accurate

Solutions (5/5)

Benefits for The Employment Fund (Töötukassa)

– Release every month – The Fund is happy

– Unexpected critical work will be done by the

mini-team that is closest to go the next release.

– The funds Acceptance Testing workload

smaller, quality is better and work is

manageable (on both sides)

Retrospectives as the

bases of becoming mature

• Homework before the meeting!

• Play retrospective games, to spice it up

• Let the individuals praise each others

work

• Involve the client

• Goals to JIRA’s impediment list

Visualize

Example

• Nortal Confluence – https://confluence.nortal.com/pages/viewpage.actio

n?pageId=69959753

• Retrospective games – http://www.infoq.com/resource/minibooks/agile-

retrospectives-

value/en/pdf/gettingvalueoutofagileretrospectives-V10.pdf

35

Result: 2 self-organized

independent teams in EMPIS

• In a self-organized team, individuals take responsibility for managing their own workload, shift work among themselves based on needs and best fit, and participate in the team decision making.

• Team members have considerable leeway in how they deliver results, but they are accountable for those results and for working within the established flexible framework.

• Nortal team is in a same room for better communication within the team

36

Nortal + Fund = Team

• The Fund + Nortal = One Team

• The Team must have the same principles,

values, work quality and understanding of

what needs to be done and how.

• The team speaks in the „same language“

• Participate in a Scrum training

• Scrum helps to keep better communication

with its rutine Ceremonies.

The Second Chapter

Self Service Portal and cowork with Helmes

38

Nortal + Helmes + Fund ≠ Team

• Challenges with Helmes

– Different terminology of work Done

– Different working culture and processes

– Smaller team (lots of churn)

– No full time QA engineers

– Dedicated developers!

• All 3 had lack of knowledge developing

large integrated IS

Scrum of Scrums

with Helmes (ITP)

Scrum, team 2

1) What have you done since last week?

2) What are you planning to do this week?

3) Any impediments/stumbling blocks?

Scrum, team 1

1) What have you done since last week?

2) What are you planning to do this week?

3) Any impediments/stumbling blocks?

Scrum of Scrums

The agenda will be the same as the Daily Scrum, plus the following four questions:

1) What have you done since last week?

2) What are you planning to do this week?

3) Any impediments/stumbling blocks?

4) Plans for upcoming sprints

Agile cowork

• Sprit planning meetings (Portfellid)

• Weekly Scrum of Scrums

• Integration testing

• Retrospectives

• Written Nortal & Helmes „House

rules“ aka rules of procedure

Better cowork?

• Written Nortal & Helmes „House rules“ aka rules of

procedure

• Atlassian stack in Töötukassa

– January 2014 (for The Fund & Helmes)

– Agile Portfolio Management board

• Sprit planning meetings (Portfellid)

• Weekly Scrum of Scrums with Helmes, ask the

questions!

• Joint developers integration testing

• Joint retrospectives after release (Nortal, Fund,

Helmes)

http://vijoy4.wordpress.com/

Third Chapter: the Future

• Enterprise Agility Maturity Matrix

• http://blogs.atlassian.com/2013/11/agile-maturity-how-agile-is-your-organization/

• Videoconference between Tallinn

Fund headquarter and Tartu Nortal

Office

• Retrospective games • http://www.infoq.com/resource/minibooks/agile-retrospectives-

value/en/pdf/gettingvalueoutofagileretrospectives-V10.pdf

© 2013 Eliassen Group. All Rights Reserved -44-

Enterprise Agility Model

AGILE OFFICE

I3 I2 I1

LOB CUSTOMERS

ESCALATION

ARCHITECTURE RELEASE TEAM / OPS

EPICS LOB BUSINESSLEADERS

DELIVERY BASED

METRICS

PO

RTF

OLI

O O

F P

RO

GR

AM

S

CA

PAC

ITY

BA

SED

INV

ESTM

ENT

1-CLICK DEPLOY

AGILE PROJECT MGMT

AGILE SCM

CYCLE TIME

DELIVERY BASED MANAGEMENT

FUNDING DECISIONS

© 2013 Eliassen Group. All Rights Reserved -45-

CYCLE TIME 1-CLICK DEPLOY

Enterprise Agility Model

AGILE OFFICE

I3 I2 I1

LOB CUSTOMERS

ESCALATION

ARCHITECTURE

EPICS LOB BUSINESSLEADERS

DELIVERY BASED

METRICS

PO

RTF

OLI

O O

F P

RO

GR

AM

S

CA

PAC

ITY

BA

SED

INV

ESTM

ENT

AGILE PROJECT MGMT

AGILE SCM

RELEASE TEAM / OPS

DELIVERY BASED MANAGEMENT

FUNDING DECISIONS

Current

Level

Target

LevelImpeded (0) In transition (1) Sustainable (2) Agile (3)

Organizational structure

1 4

Function and project based There is understanding that structuring

the organization around products,

teams, and delivery is better. Some

changes have already been made and

more are underway.

There is consistent effort applied to

moving to a product, team, and

delivery based organization

50%+ of the organizational changes

required to move to a product, team,

and delivery based organization have

been made and the rest is actively in

progress.

Funding

3 4

Big ticket, whole project. Full

requirements document with

corresponding estimates required prior

to funding. Bake-off between projects

to determine which projects get

funded. Project success dependent on

fully implementing all requirements.

Some portions of previous state only

partially required. For instance, project

is broken up into multiple releases and

changes to requirements are

encouraged or only 50% of

requirements need to be fully

estimated

Projects are funded on a quarterly

basis, only a quarter's worth of scope is

needed at a time, and a significant

criteria for success is the amount of

shippable product produced

Projects are funded on a quarterly basis

or less. Only a short business

justification is necessary to start a

project. Good controls are in place to

monitor effective ROI.

Projects in Progress

3 4

Unknown and/or all projects that are

approved are immediately considered

started.

The number of projects in progress is

known, there is some upper limit on

how many can be in progress at a time,

and that limit is usually enforced.

There is a projects in progress limit that

insures there is no more than a 2-1

ratio between number of people

needed to fully staff all projects in

progress and the actual number of

There is no more than a 3-2 ratio of

people needed to people available.

Metrics1 4

Function based Delivery based metrics are being tried,

planned, or discussed

50%+ of metrics are delivery based.

Some of the overlapping metrics are

still being tracked and used

50%+ of metrics are delivery based and

none of the overlapping metrics are

being tracked or used

Compensation /

Preemiad 0 4

Individual based. Taking time away

from typical goals to support Agile

adoption is discouraged.

People are encouraged to put effort

into adoption. Putting effort into Agile

adoption is encouraged and does not

negatively effect compensation.

A meaningful portion of any goal or

bonus structure is team or delivery

based.

Performance based compensation is

mostly delivery based.

Impediments4 4

Rarely raised out of ambivalence,

belief that they will be ignored or

other reasons

Sometimes raised and sometimes

addressed

Usually raised and often addressed Actively pursued and aggressively

addressed

Tools and technology

1 4

Traditional tools configured for

traditional development

Organization is starting to look at

switching to more appropriate tools

where needed and/or reconfiguring

existing tools to work in an Agile

environment

Tools are not seen as an impediment New projects are using Agile-

appropriate tools

Agile Adoption Tracking2 4

Not implemented Adoption metrics have been chosen

and an initial assessment has been

done

Adoption goals have been set, progress

is tracked and frequently influences

the behavior of the organization

Progress information usually

influences the behavior of the

organization

Agile Adoption Guiding

Coalition1 4

Agile adoption is entirely grass roots. The organization has officially

appointed a person to lead the Agile

Adoption.

There is a cross-functional team

officially appointed to lead the Agile

Adoption.

The Agile adoption is being run as an

Agile project (Scrum or Kanban)

Management of Agile

teams 2 4

Function based. Managers or team

leads make all or most of the decisions

that a mature Agile team would usually

make on their own

Self organization is being discussed and

encouraged.

50%+ of teams are operating at at least

stage 3 of self-organization, most

teams are being encouraged to get to

stage 3

70%+ of all teams are operating at stage

3 of self organization, 50%+ of all teams

are operating at stage 4 of self

organization, all teams are being

encouraged to get to stage 4

Business/Development

relationship 3 4Handoff based Desire to move to Agile Working through product owners Product owners are fully available to

teams, empowered, and well trained in

their role

Executive support

4 4

Unaware of Agile effort and/or

unsupportive

Supportive Supportive and trained Actively involved in removing

obstacles. Actively involved in

improving organizational agility.

Dedicating appropriate budget.

Middle Management

support 1 4

Unaware of Agile effort and/or

unsupportive

Supportive Supportive and trained Actively involved in removing

obstacles. Actively involved in

improving organizational agility.

Dedicating appropriate budget.

Team member

management support 0 4

Unaware of Agile effort and/or

unsupportive

Supportive Supportive and trained Actively involved in removing

obstacles. Actively involved in

improving organizational agility.

Dedicating appropriate budget.

http://blogs.atlassian.com/2013/11/agile-maturity-how-agile-is-your-

organization/

Story Summary

• EMPIS development team

• Agility and our way of Scrum

• The challenges we faced

• The future agile challenges

• Questions?

The End!

Alar Huul

EMPIS and Alfresco CMS

Project Manager at Nortal

alar.huul@nortal.com