Scrum`i juurutamine Webmedia Töötukassa arendus

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
Nortal
e-Government
Healthcare
Our Expertise
Manufacturing &
Logistics
Financial Services
Specialist Consulting
User Experience & Design
Software Development
System Integration
Telecom
Public Finance
Management
Energy & Resources
Application Management
Enterprice Content Management
Open Source Technologies
24/7 Support
1.
2.
3.
4.
5.
6.
7.
Finland
Estonia (Tallinn & Tartu)
Lithuania
Russia
Serbia
Romania
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
Solution analysis
Sum EUR
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
8 000,00
440 000,00 EUR
80 000,00
4 320 000,00 EUR
161 712,00
8 128 650,21 EUR
3. Phase 20% (13.03.2013-04.09.2013)
4. Phase (25.07.2013-31.12.2015)
Total:
82 000 hours work has been done before the begining of „4. Phase“
What Paradigms Are We
Breaking?
Agile Development
Process
Waterfall
Development
Measure
of Success
Conformance to Plan
Culture
Command-and-Control
Design
Big Design Up Front
QA
Big Test on Backend
Iterative Development
Iterative and
Incremental
Development
Parallel
Development
Acceptance
Test Driven
Development
Response to Change
Leadership /Collaborative
Continuous
Continuous
10
Scrum Framework
3 Roles
 Product Owner
 The Team
 ScrumMaster
4 Ceremonies





Daily Scrum
Sprint Planning
Sprint Review
Retrospective
Project
Retrospective
4 Artifacts




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)
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.
17
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/agileretrospectivesvalue/en/pdf/gettingvalueoutofagileretrospectives-V10.pdf
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
35
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.
36
The Second Chapter
Self Service Portal and cowork with Helmes
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
38
Scrum of Scrums
with Helmes (ITP)
Scrum, team 1
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?
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-retrospectivesvalue/en/pdf/gettingvalueoutofagileretrospectives-V10.pdf
Enterprise Agility Model
DELIVERY
FUNDING BASED
DECISIONS MANAGEMENT
ESCALATION
CAPACITY BASED INVESTMENT
PORTFOLIO OF PROGRAMS
AGILE OFFICE
AGILE
PROJECT
MGMT
AGILE SCM
LOB
CUSTOMERS
DELIVERY
BASED
METRICS
© 2013 Eliassen Group. All Rights Reserved -44-
LOB
EPICS
BUSINESS
LEADERS
CYCLE TIME
I1
ARCHITECTURE
RELEASE TEAM / OPS
I2
1-CLICK
DEPLOY
I3
Enterprise Agility Model
DELIVERY
FUNDING BASED
DECISIONS MANAGEMENT
ESCALATION
CAPACITY BASED INVESTMENT
PORTFOLIO OF PROGRAMS
AGILE OFFICE
AGILE
PROJECT
MGMT
AGILE SCM
LOB
CUSTOMERS
DELIVERY
BASED
METRICS
© 2013 Eliassen Group. All Rights Reserved -45-
LOB
EPICS
BUSINESS
LEADERS
CYCLE TIME
I1
ARCHITECTURE
RELEASE TEAM / OPS
I2
1-CLICK
DEPLOY
I3
http://blogs.atlassian.com/2013/11/agile-maturity-how-agile-is-yourorganization/
Current
Level
Target
Level
1
4
3
4
Funding
Projects in Progress
Metrics
Compensation /
Preemiad
Impediments
3
4
1
4
0
4
4
4
Tools and technology
1
4
2
4
Management of Agile
teams
Business/Development
relationship
1
4
2
4
3
4
4
4
1
4
Team member
management support
0
4
Sustainable (2)
Agile (3)
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.
Projects are funded on a quarterly
Projects are funded on a quarterly basis
basis, only a quarter's worth of scope is or less. Only a short business
needed at a time, and a significant
justification is necessary to start a
criteria for success is the amount of
project. Good controls are in place to
shippable product produced
monitor effective ROI.
Unknown and/or all projects that are
The number of projects in progress is
approved are immediately considered known, there is some upper limit on
started.
how many can be in progress at a time,
and that limit is usually enforced.
There is no more than a 3-2 ratio of
people needed to people available.
Function based
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
Delivery based metrics are being tried, 50%+ of metrics are delivery based.
planned, or discussed
Some of the overlapping metrics are
still being tracked and used
People are encouraged to put effort
A meaningful portion of any goal or
into adoption. Putting effort into Agile bonus structure is team or delivery
adoption is encouraged and does not based.
negatively effect compensation.
50%+ of metrics are delivery based and
none of the overlapping metrics are
being tracked or used
Performance based compensation is
mostly delivery based.
Sometimes raised and sometimes
addressed
Usually raised and often addressed
Actively pursued and aggressively
addressed
Organization is starting to look at
switching to more appropriate tools
where needed and/or reconfiguring
existing tools to work in an Agile
environment
Adoption metrics have been chosen
and an initial assessment has been
done
Tools are not seen as an impediment
New projects are using Agileappropriate tools
Individual based. Taking time away
from typical goals to support Agile
adoption is discouraged.
Rarely raised out of ambivalence,
belief that they will be ignored or
other reasons
Traditional tools configured for
traditional development
Agile adoption is entirely grass roots.
Executive support
Middle Management
support
In transition (1)
There is understanding that structuring
the organization around products,
teams, and delivery is better. Some
changes have already been made and
more are underway.
Big ticket, whole project. Full
Some portions of previous state only
requirements document with
partially required. For instance, project
corresponding estimates required prior is broken up into multiple releases and
to funding. Bake-off between projects changes to requirements are
to determine which projects get
encouraged or only 50% of
funded. Project success dependent on requirements need to be fully
fully implementing all requirements. estimated
Not implemented
Agile Adoption Tracking
Agile Adoption Guiding
Coalition
Impeded (0)
Function and project based
Organizational structure
Adoption goals have been set, progress Progress information usually
is tracked and frequently influences
influences the behavior of the
the behavior of the organization
organization
The organization has officially
appointed a person to lead the Agile
Adoption.
Function based. Managers or team
Self organization is being discussed and
leads make all or most of the decisions encouraged.
that a mature Agile team would usually
make on their own
There is a cross-functional team
officially appointed to lead the Agile
Adoption.
50%+ of teams are operating at at least
stage 3 of self-organization, most
teams are being encouraged to get to
stage 3
Handoff based
Desire to move to Agile
Working through product owners
Unaware of Agile effort and/or
unsupportive
Supportive
Supportive and trained
Unaware of Agile effort and/or
unsupportive
Supportive
Supportive and trained
Unaware of Agile effort and/or
unsupportive
Supportive
Supportive and trained
The Agile adoption is being run as an
Agile project (Scrum or Kanban)
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
Product owners are fully available to
teams, empowered, and well trained in
their role
Actively involved in removing
obstacles. Actively involved in
improving organizational agility.
Dedicating appropriate budget.
Actively involved in removing
obstacles. Actively involved in
improving organizational agility.
Dedicating appropriate budget.
Actively involved in removing
obstacles. Actively involved in
improving organizational agility.
Dedicating appropriate budget.
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