Kanban and Government

Once upon a time...

Jean - François

IT Dev backgroundTeam lead Agile virusCSM + CSPOContinuous

improvementPragmatic

ContextBusiness Process Re-engineeringArchitectural RenewalUnstable legacy apps

Government Stereotypes

Slow decision making


Fire fighting

http://www.flickr.com/photos/roberto_ferrari/139349655/


Election Fever

http://www.flickr.com/photos/andresrueda/3407340937

http://www.flickr.com/photos/code_martial/4145914957/


Low personal motivation

Context

Agile coaching efforts• Planning• Communication• Process visualization• Continuous improvement• Stakeholder management• Self-organization

ContextWhy me? A man without government for 327 days!

One month ago in Poland

A man without government for 291 days!

the ResultsAgile made problems visibleFight for resources / priorityDisruptions made planning hard >

expectations not metBig variety of workSpecialistsNot giving good customer service

Need for ChangeFocus was too narrow

WE

THEM THEM

input output

suboptimizing

Kanban adoption1 pilot product

How do we start?“Draw the workflow!”

Kanban adoption1 st attempt

Kanban adoption2 nd attempt

Kanban adoptionInitial workflow

Improving1st Retrospective• WIP limits well respected –+ visualization of issues• Missing visualization of detailed tasks• Missing a planning meeting

Improving1st Retrospective (cont’d)

• Needed different level of feature detail

Business request:“Customers have to be able to fill in a reservation,

send it to the planning department and get a confirmation email with pdf attachment”

Agile team would split this into:

1. As a user I want to fill in a new reservation...2. As a user I want to send my reservation...3. As a user I want to receive an e-mail

confirmation with my reservation in pdf attachment so that I ...

Suppose we used user stories in the flow:

READY Analysis DESIGN VALI PROD2 1

As a user I want to fill in a new reservation

As a user I want to send my reservation...

As a user I want to receive ane-mail confirmation ...

2TEST

21

TOO Low Level for

Stakeholders

TOO Low Level too

early

Not all applicable

DEV2

OKOKTOO Low Level

Improving1st Retrospective (cont’d)

• Walking the board took longer than daily standup

• Big difference in size of work items • Need for progress visualization

ImprovingResult

Improving

Improving

Discoveries2nd Retrospective• Easier prioritization • Easier validation

“A politician needs the ability to foretell what is going to happentomorrow, next week, next month, and next year.

And to have the ability afterwards to explain why it didn't happen.”

W. Churchill

Discoveries2nd Retrospective (cont’d)

• Limitations of the physical task board• Bigger teams ~ distributed• More administration ~ measuring• Progress visualization


• Lost focus


• WIP limits + pull made things happen• People idle causes action!

WIP limits enable more cross-functional collaboration


• Still fight for resources / priorities

Why? Step out, watch from customer viewpoint

1 project asks to put stuff in queue & prioritize

What about non-project related work?

Confusing for stakeholders

KA

NB

AN

SC

RU

MHybrid

1 st Release

Product Maintenance & ExtensionNew Product Development

Service Levels1. % of total capacity / project

Service Levels2. Classes of service / project

Service LevelsNo percentiles yetNo cost of delay yet

The FutureFull Kanban flow? With cadance?

Product Development + Product Maintenance & Extension

Faster & smaller deployment

The Future1st step to DevOps?

In many organizations today

READY ... ... ... PROD2 1

...21

...3

...2

dev dev dev sys sys sys

READY ... ... ... PROD2 1

...21

...3

...2

In some organizations tomorrow?dev devdev syssys sys

Afterthoughts

Is Kanban less team focused?

Afterthoughts

Do you need thisin a highly mature,

stable business setting?

Afterthoughts

What added valuewould Kanban bring

in Government?

ConclusionWe owe it to ourselves!Government must keep trying to

improve

We’re paying for it!