UK Parliament Exploring Digital on Thu 22 January 2015. How is agile changing public sector? What is becoming agile like as a learning journey?

1. Karoliina Luoto, Codento · UK Parliament · 22 January 2015
Agile Learning Journey
Agile In Public Sector

2. Karoliina Luoto + Codento
Consultant for
Agile coaching and co-work
Digital services, collaboration
Before: product owner, collaboration
strategist, information society specialist
Specializes in client/supplier
methodology facilitation
And works in actual software development
too

3. What defines
a good project?
Suggestions?
Photo: karla_k., FlickrPhoto: Karoliina Luoto
Some of mine:
1. Clear vision
2. Transparency
3. Predictability
4. Learning

4. Procedure changes
Can hugely enhance efficiency
Photo: Julius Reque, Flickr
Looking from Finland,
UK is a digital procedures
champion

6. Classic problems
In public sector IT projects
1. Projects blow out of proportion
2. Functionality misses the target due to lack of vision and
absence of user contact
3. Missing transparency leads to poor quality and increasing
problems

7. Agile turns
Big goals into small steps
Photo: Karoliina Luoto

8. But what else
Does it bring in?
Photo: ronnykolau, Flickr

9. Culture of testing
Helps optimizing value
1. Focus on solutions that fill 80 % of user need with 20 % effort
2. New processes are the hard part – why not practice with
minimum viable product or with no tools at all?
3. Micro piloting as proof-of-concept

10. Versatile expertise involved
Increases quality
2. Make your project alluring for best of breed
3. Once you get them, empower them to make the daily decisions
Key success factors:
4. Open up protos and betas for user comments
5. Get stakeholders and outside experts to attend reviews
1. Even before starting the project, open the RFPs / plans for
comments

11. Transparency
Minimizes risks
1. Bad news always exists – make sure you hear it soon
2. So, lower the threshold for telling bad news
4. Get concrete hold of results at end of every sprint – code to
Github, documenting to wikis
Key success factors:
3. Make sure required information is available for everyone –
also budgetary

12. The mindset of trust
Helps focusing on success
2. Move from preparing for disasters towards enabling success
3. People over-accomplish when trusted – so why not trust them
1. Trust helps people tell bad news

13. What does it take
From managers and leaders?
Photo: W10002, Flickr

14. Visionship
”What is this service for?”
1. Willingness to prioritize requirements
2. Learning from feedback and yet keeping the unity of the
product
3. Balancing between stakeholders

15. Letting go
The old risk management mindset
1. Purchasing focuses on getting the best possible talent
2. Typically buying time allocation, not outcomes
3. Time and material contract model requires positive incentives

16. Bureaucracy + Agile = Mission Impossible?
Sugggestion: NO.
Predictability on project and release level can be combined
with agility.
Projecting and budgeting sets the
limits, and learning on the way helps
optimizing the value
Decision-makers can be brought in
to vision and release planning. What
are the main objectives? What
should the development focus on
next X months?

17. Daily
plan
Sprint
goal
Product
roadmap
Product strategy
Service strategy
Vision for initiative
Product vision,
plan for 1-5 years
Release plan,
plan for 1-12 months
Strategy, vision, backlog

18. Possible tool: Value
Burnup Chart
Requires:
• Steering group playing value poker
on epics/ features
• Product Owner monitoring
progress in relation to value points
Photo., FlickrKuva: Alan, Flickr
Picture credits: James Shore

19. It takes 2-4 years to learn agile
Agile Fluency Model
© 2012 James Shore and Diana Larsen, Agilefluency.com
Start:
Building
code
1 Focus
on
business
value
culture
shift
Team
2 Deliver
business
valueSkills shift
Team
3 Optimize
business
value
4 Optimize
for systemsculture shift
Organization
0

20. How to gain from agile ideas
No matter the project model
Focus on vision and needs
Reduce vision risk by piloting and testing
Reduce project risks by chopping elephant projects into
smaller projects or product purchases
Whether you manage risk by contract optimization or
openness – don’t skip communication
Measure value and incentivize wanted results
Be open to hearing bad news – you’d rather hear it
Learn

21. However, success
Is not a methodology choice
Photo: massdistraction, Flickr

22. Thank you!
www.codento.com
karoliina.luoto@codento.com · @totoroki · +358 40 765 8504