egov projects for fun profit

Post on 28-May-2015

853 Views

Category:

Economy & Finance

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Scrum gov

TRANSCRIPT

E-GOV PROJECTS FOR “FUN” (AND “PROFIT”)

Govcamp 2007 Antwerp

Personal Introduction

Patrick Debois Independant Consultant

Government Side (RFP, Design) IT Supplier Side (Portals, CMS, Identity &

Access) Also a Belgian Tax Payer

Why this presentation?

How did I survive (10 years of E-gov) Old Tactics

Don’t care on the functionality, focussed on technical “We sometimes work for nothing but not for free!” “As a tax payer I’m glad to get (some) tax money back!”

Concentrated on the right toolset (Hardware, Software) Resulted in PROFIT (I got paid)

New Tactics Improve the process : Promote Agile Process

Management (e.g. Scrum) Change thinking

Results in FUN & PROFIT (I hope so!)

•Late•Over budget•A lot of Frustration

Your ‘average’ E-gov Project

E-gov Projects Schedule

Reality

PlannedDEADLINE

Does not meet the deadline

E-gov Projects Scope

Planned

DEADLINE

Scope

RemovedScope

Additional Scope

Has a change scope, unfinished

Iron Triangle (Restistance if Futile)

Quality

Scope(Features,

Functionality)

Schedule (Time)

Resources(Cost,

Budget)

Breaking the Triangle results in:•Cancel Project (15%)•Deliver Later and/or Over Budget (51%)•Deliver poor quality•Underdeliver

Source Chaos Report

Common E-gov Project Tactics Fix the Scope:

bring in another company for RFP proces (avoid responsability) handover part of scope from project to operations (quality) change requests

Fix the Time: we’ll be ready when you are (Bluffpoker) provide temporary solution blame the previous in the chain (Design, Test, Integration, Prod

by diffent teams) we are 96% ready

Fix the Price: predefine as much as possible (Big Up Front Design) penalties are another budget borrow from other hidden budget promise additional projects to supplier

Focus on reduction of changes (the hard way)! = NO FUN!

Abondon Waterfall ModelBecoming Agile (Embrace change!)

example using Scrum

Changing Tactics

Agile Tactic : Prioritize Functionality

High Priority

Low PriorityRequirementsFunctionality

Each new Requirement is prioritized and addedto the stack

Requirements may be removed at any time

Requirements may be repriorized at any time

Modeled in greater detail

Modeled inlesser detail

Product BacklogProduct Backlog

Focus on functionality not on componentsBetter view of what is finished

Agile Tactic : Release Often

High Priority

Low PriorityRequirements

Modeled in greater detail

Modeled inlesser detail

Set of Functionality

Set of Functionality Sprint X

Sprint X + 1 Fixed LengthBecomes a rythm

Set of Functionality

Set of Functionality

Planning becomes predictable if requirements become clear.Most important first.

Timeboxed Periods = SprintTimeboxed Periods = Sprint

Agile Tactic : Planning as a TEAM

Set of Functionality

Set of Functionality Fuctionality X1 =

Fuctionality X2=

Fuctionality X3 =

Fits Sprint capacity

For next Sprint

11 22 33 55 88 1313 2121 BIGBIG

Team thinks it can handle 12 points in a Sprint

3

5

8

5050

Team does estimations in group.Relative in Size (StoryPoints) , not in Days

Planning Poker

Fuctionality X4 = Needs to be split21

Agile Tactic: Realistic Progress

Initial

DEADLINE

0

50

100

1 2 3 4

130

5 6 7 8

Product Backlog Burndown Chart

9 10 11

Estimate 1

Estimate 2

Sprint

Convergence to an predictable “team” velocityRemember Iron Triangle!

Agile Tactic : Focus

High Priority

Low PriorityRequirements

Modeled in greater detail

Modeled inlesser detail

Set of Functionality

Set of Functionality Sprint X

No need for all design upfrontFocus helps getting things done

Sprint BacklogSprint Backlog

Product Owner (PO)Focus = Functionality

Scrum Master (SM)Focus = Blockers

TeamFocus = Build

Set Tasks

Agile Tactic : Have things “Done”

Planning

Analysis

Design

Coding

Testing

ArchitectureInfrastructure

Performance

User Acceptance

Pilot

Live

TIP: automate as much as possible:•Automated Deployment•Automated Testing•Virtual Machine•Scripted installations

Result of sprint = Real functionality

Copyright Jef Sutherland

Agile Tactic : Better Communication Product Backlog meeting (PO & SM) (2 – 4

weeks) Focusses on Functionality = what PO understands

Sprint planning meeting (SM & Team) Focusses on Technical = what Team understands

Daily Scrum Meetings (Team & SM) What did I do yesterday What will I do today What is blocking me

Sprint Retrospective After Sprint (Team & SM) Sprint closing (Team & ScrumMaster & Product

Owner) (2 – 4 weeks)

Agile Tactic : Improve Feedback User Feedback

After every sprint : we build things that are“Done”

Status Feedback Product Backlog

Financial Feedback Timebox +/- Fix Budget (Man Power)

Deadline Product Backlog burndown chart

Summary : Scrum Process

Copyright SoftHouseBelieve me! It’s more FUN!

Are you up for it?

Do you want transparancy? Can you take the shared responsability? Are you only committed or also

involved? Will you change your ‘old” tactics?

Demand Agility in your projects!

References Books

Agile Project Management with SCRUM (Microsoft Professional) (Ken Schwaber)

Agile Estimating and Planning (Robert C. Martin) User Stories Applied: For Agile Software Development (Mike Cohn) Agile Retrospectives, Derby and Larson

Videos (Google) Scrum et Al- Ken Schwaber Bay XP Meeting Part 1: Agile Estimation, Mike Cohn Competing On The Basis Of Speed – Mary Poppendieck Scrum Tuning: Lessons learned from Scrum implementation at Google,

Jeff Sutherland Mailing Lists

agile-testing@yahoogroups.com scrumdevelopment@yahoogroups.com leanagilescrum@yahoogroups.com retrospectives@yahoogroups.com SellingAgile@yahoogroups.com

Websites http://www.scrumalliance.org

Thanks for Listening

Questions?

Patrick.Debois@sos.be

top related