How to become more Agile !than Google

A sketch for Online Patrik Svensson, Head of Online Practise

1"

Outline •  A typical Online Project today – slow and

standalone •  A Online Line Organisation – faster and

integrated to the business unit – Sits close to Product Development – Could be located in Local IT or in central IT in

some cases •  Applying Google Agile ideas could help us

become even more agile

Project Lifecycles today – Yearly! Waterfall. Takes a Year. Expensive. Very few releases.

We Learn very little. Standalone Organisation.

June

Q3’13

Jul Aug Sep

Q4’13

Oct Nov Dec

Q1’14

Jan Feb Mar

Q2’14

Apr May

Capex Pre-funding

Board Approval

Steering Group

Main Project

Handover

Closure

Phase 3

Phase 4

Phase 5

Phase 6

Phase 7

Agile Phase

Steering Group

Phase 2 Idea Work

Phase 1

Assessment Most Business Cases have a payback between 6-24 month.

So evaluation sometimes comes after 3 years.

Project Inception

Agile Online Line Organisation - Highly integrated in the Business Unit�

Lots of benefits to this!

Product"Manager(s)"

Engineering"Manager(s)"

Product"Director"

Tech"Lead"

Support:""UX,"Design,"

Infrastructure"

Desktop" Mobile""Web"

App"(iOS,"Android)" API" Backend"

Business""Unit"Director"

MarkeGng" Sales"" Support"

Each Project should get a Board and do releases continuously

Scheduled Working On In Review Checked In Done

ex ”App” has a team board open for everyone, You could use Greenhopper for this …"

The Agile Lifecycle is Weekly!

6

Faster iterations and Releases, not necessarily continuous but faster often, not always means better.

W28

July Q3’13

W29 W30 W31

Board 1 / Project 1 - App project

Board 2 / Project 2 - New Product B

Board 3 / Project 3 - Backend Transformation

Weekly releases

Skipped a week…

Slightly slower pace

The Weekly Schedule "•  Spend as little time as possible in meetings!!! –  Daily standup (optional) –  One weekly team planning meeting (1hr) –  A weekly (or monthly) retrospective (15 min) –  Nothing else in calendar!

Agile Roles and Responsibilities Abbrev Name Description HoP Product Director

(Technical) Understands business needs, develops, organized and launches new products and systems to meet business needs. Has commercial counterpart.

PM Product Manager (Technical)

Product Requirements and tracks features in progress. Has commercial counterpart.

EM Engineering Manager Owns projects, allocates resources, removes non-technical roadblocks

TL Tech Lead Technical direction, prioritize features with PM, set expectations with PM/Mgr, removes technical roadblock, interfaces with other teams

SD (Software )Developers Develops production software, writes unit/load/performance tests

TE Test Engineers N/A Support Team

Design, UX, Infrastructure Various resources to improve experience, designs and technical infrastructure required

Product Managers and Developer dynamics

User Stories (Product Mgr) •  Defined by a customer (or

PM) •  A part of something bigger •  A feature •  It must be clear when a

user story is done •  Has to be possible to

acceptance test it –  ”As a Customer I want to be

able to view my balance”

Task breakdown (Developer) •  Developers breaks down

US •  Task description has to be

clear to any team member •  Doable in hours or days,

i.e. small •  Clear when a task is

completely done •  Task – description, size,

owner, status

User Story Example User Story •  ”As a App-using

Customer I want to be able to view my balance”

Possible Tasks 1.  Define API for backend 2.  Implement backend part

of API and load balance from data store

3.  Add display balance functionality to the client-side. Use new API.

Thank You!