PAM Summit Cracow, The ABB.com goes Agile Story

Workshop The OneABB Team Goes Agile

The Tricks Used for Crea8ng Awareness and Desire for Change and Actually Doing the Change

Ma?hew Caine

AGILE

Some people call it a method or an approach

above all

It is about PEOPLE and RESULTS

Assump8ons

•  You are looking for real challenges of “Agile” •  Expect some quick-‐win “take-‐aways” •  You are not here to fine-‐tune your Standups

Who am I? •  English •  Come from near Liverpool / Manchester •  I.T. background •  Lived in Zurich since 1994 •  Worked in London, NY, Berlin, Geneva and ZH •  Discovered “Agile” in 2009

August 2011 Setup M.C. Partners & Associates

September 2012 Launched the Agile Academy

Community

OneABB’s Purpose: “An Awesome Website”

www.abb.com

www.abb.com

80 country sites

2000 content editors

over 1 million urls

10 million views / month

ABB’s website is a key customer connection

Facebook and LinkedIn are the top sources of traffic after direct visits, search, and visits from the intranet

The Real Story •  No transparency on status, people or ac8vi8es •  50 people in four countries •  40 people in Krakow organized by skill •  Culture of maintenance •  “Hero culture” with Prima Donnas •  Agile, but not really •  Constant “firefigh8ng” •  Stuff was late, not as expected, poor quality

This Workshop is about the changes above and beyond Agile skills.

It is about some of the things we

had to do con8nue to do

and s8ll need to do

to give Agile a chance!

How the Workshop will Work

•  9 topics… The first 5-‐6: – Examine the Scenario / Theory – You get 5 minutes at your table to discuss –  I then chose 2 groups for feedback – We then look at what was actually done

•  At the end we’ll scan the remaining topics.

Crea8ng Awareness & Desire

Performance Reviews

Managing Prima Donnas Be?er Transparency on Work

Gold Pla8ng = Quality /

Remote Team

Percep8

on

The Gan? Lie Chart vs “Agile Planning” Looking for & Building Trust

Remote Teamwork

Crea8ng Awareness & Desire The Scenario

It is May 2012. You are in a room with the key people from Krakow and Zurich. They know things have to improve. But don’t know where to start.

Your Task

Discuss how you would get them to: 1.  Share & agree on their pains 2.  Want to address the pains 3.  Agree on the most important changes?

Crea8ng Awareness & Desire Step 1: Brainstorm to Visualise “Tensions”

Crea8ng Awareness & Desire Step 2: Run a Normal Retrospec8ves Session

Categories

What went well?

What do we need to start?

What do we need to stop?

What do we need to improve?

Out-‐of-‐the-‐box innova8ve ideas

3a) Place “tensions” on top

3b) Re-‐examine any lem-‐overs

Crea8ng Awareness & Desire Step 3: Which Tensions could be Resolved and Examine Lem-‐overs

A

B

C

D

E

F

Crea8ng Awareness & Desire Step 4: Group & Name

A

B

C

D

E

F

1.  Each Team-‐member has 3 votes. 2.  Take 5 minutes to vote. 3.  Facilitator checks and summarizes the vo8ng. 4.  Debate results.

Crea8ng Awareness & Desire Step 5: Priori8se

Priority

B

E

C

F

D

A

Priority Owner

B John

E Mary

C Mark

F Paul

D

A

A

B

C

D

E

F

Crea8ng Awareness & Desire Step 6: Assign Owner

Don’t do low prio stuff!

As a peer-‐group they have iden8fied their tensions, priori8zed and assigned owners. By default they are aware and have the focus and desire to change.

Project Methodology

Well Structuring the

Work (Basecamp)

Start Regular

structured standups

Improve Priori8za8on and deadline serng

Improve PM ISDC GWH

Stop Having every task a top priority

Improve Planning and Priori8za8on

Well Doing the scope planning together

Improve Be persistant with things we have started. Do not abandon things.

Start Have a board

with projects and priori8es visible to everyone.

Stop Classic BA process

Stop Making promises

without consul8ng

execu8ng party

Well Projects where we have a clear deliverables schedule

Everything is a priority to everyone in

GWM

Improve Set up common rules for running

a project

Maintenance burden of “old” vs developing

new

Improve Intera8ve: Get feedback more omen, earlier

Start Get the UX – BA –

DEV process working

Well Projects with

weekly mee8ngs to followup on overall status

Improve Working on deadlines together


Managing Prima Donnas


Your Task

Discuss and list your thoughts on : •  The risks of prima-‐donnas to the teams, department & company. •  How you could get the knowledge of the individual prima-‐donnas shared.

The Scenario

Krakow has a number of Individuals that are “prima-‐donnas”…


Ø  Bo?leneck for the teams Ø  Difficult to plan Ø  Create dependencies in a sprint Ø  Burn out Ø  Cause resentment Ø  “Under a bus” syndrome Ø  Like to keep know-‐how Ø  Poor team members


Typical Solu8on

Two or more teams share:

But s8ll: •  Bo?leneck •  Difficult to plan •  Create dependencies in a sprint •  Burn out •  Cause resentment •  “Under a bus” syndrome •  Insecure – like to keep know-‐how •  Poor team members

50%

Alterna8vely

•  Make them free-‐agents •  No longer responsible for deliverables •  Now responsible for coaching &

suppor8ng team members who deliver

Thus •  Know-‐how transfer happens •  Can support many people •  Ego is not damaged ;-‐)

Be?er Transparency on Work

Be?er Transparency on Work The Scenario

•  Zurich has no idea who is working on what or why people are working on things. •  Krakow does not understand the priori8es, as they constantly change. •  Krakow do not know what to work on or why it is suddenly “important”.

Your Task

List your thoughts on how to gain transparency on: 1.  Why work is important (Purpose)? 2.  What is coming (Future stuff)? 3.  Who is working now on what? It is important that both Krakow and Zurich see the same informa8on.

Be?er Transparency on Work

Idea OpAons High Level Plan Features Maintenance

Based on DSDM: Pre-‐Project, Feasibility, Founda8ons, Explora8on & Engineering

Step 1: Define Phases that Projects are “in”

A long 10m Wall will help!

Be?er Transparency on Work Step 2: Map Projects to the Phases and the Projects to Teams

Teams can start to PULL work…

Be?er Transparency on Work Step 3: Assign People to Teams & Iterate (Ac8on Gaps!)

Be?er Transparency on Work Step 4: Make it All Accessible to All (Zurich & Krakow) All the Time e.g. Google Drive Docs

The Scenario

Krakow development speed is slowed due to: •  Developers gold-‐pla8ng •  Poor quality Yet developers want to work on the next latest sexiest work.

Your Task

What do developers need to understand to: •  reduce gold-‐pla8ng •  deliver quality •  get developer working on the next sexy project?



ü  Build the absolute minimum.

ü  Don’t be tempted to do what is interes8ng.

ü  Build it well.

ü  Make it from simple stuff.

Ø  Frees developers from future maintenance.

Ø  Gives 8me to start the next sexiest job.

Remote Team

Percep8

on

Remote Team

Percep8

on The Scenario

•  There is miscommunica8on in the team split across Zurich & Krakow. •  People are by-‐passed and feel unappreciated •  Others have to much to do.

Your Task

Two groups will: 1.  Read their team descrip8ons 2.  Put names to the Roles

(based on DSDM) – Flipchart Provided

3.  Reveal the results “Spot the Difference”.

Business Sponsor

Business Visionary

Business Analysts

Business Ambassadors

Business Advisors

Technical Coordinator

Solu8on Testers

Solu8on Developers

Project Manager

Team Leader

“End user”

“Expert user”

Remote Team

Percep8

on

SPOT TH

E DIFFER

ENCE

Remote Team

Percep8

on Zurich’s Percep8on Krakow’s Percep8on

Business Sponsor

Business Visionary

Business Analysts


Business Advisors


Solu8on Testers

Solu8on Developers

Project Manager

Team Leader

????

Business Sponsor

Business Visionary

Business Analysts


Business Advisors


Solu8on Testers

Solu8on Developers

Project Manager

Team Leader

????

????

Mike Mike

????

Nolan Piotr

Lukas Casper Pawel

Eloise

Casper

Claire

Nolan

Casper

Lukas Piotr Pawel

Casper

Anna

Eloise

????

SPOT THE DIFFERENCE

The Gan? Lie Chart vs “Agile Planning”

The Gan? Lie Chart vs “Agile Planning” The Scenario

•  Scrum & sprints are perfect for systems that are already live. •  Zurich however, occasionally want to launch new products. •  Some8mes for things that we don’t even know if they are possible. DSDM is great for star8ng a new product… •  Take an idea •  Test op8ons and feasibility •  Set up a high-‐level plan and context (JEDUF) •  Finally to launch into regular sprints / Timeboxes.

Your Task

What could the context be? What makes sense to agree before development starts, especially in large corporate IT environments?

Assess Benefits

Increment E J, A G

Increment H C B

Increment I D F

High Level Planning

Op8ons

Deploy Deploy Deploy •  Maintenance strategy •  Tes8ng strategy •  Non-‐func8onal needs •  Audit requirements •  Regulatory needs •  Hardware, somware, middleware

•  Priori8sed Highlevel Requirements •  Timebox Plans with MoSCoW’d requirements •  Financial cost for en8re plan. •  Repor8ng •  Resources •  Delivery plan (training etc)

•  ROI, Business Case •  Risks, assump8ons

•  Business case, vision, assump8ons •  Op8ons considered •  Recommended op8on •  Highlevel plan (ext deadlines) •  Indictor of poten8al cost •  Plan + cost to deliver “High level planning” •  Key resources

Idea!

•  1-‐Pager •  Business driver •  V. Highlevel Objec8ves •  Request to invest $x in

“Op8ons” Decision Point (Go on, Stop)

Timebox

Deploy Into produc8on (Not necessarily switch-‐on)

PrioriAsed Requirements A m B s C s D c E m F c G m H m I s J m

“Agile Planning”

AT THIS POINT STILL NO DETAILED SPEC or DESIGN (JEDUF)

Looking for & Building Trust

The Theory: The Five Dysfunc8ons of a Team (P. Lencioni, 2002)


Ina?en8on to Results

Avoidance of Accountability

Lack of Commitment

Fear of Conflict

Absence of Trust

Invulnerable: Don’t admit mistakes and weaknesses.

ArAficial Harmony: Incapable of unfiltered and passionate debate.

Ambiguity: Rarely, if ever, buy-‐in and commit but “pretend” to agree.

Low Standards: Don’t challenge peers when their ac8ons appear counterproduc8ve.

Status & Ego: Individuals put own or department’s needs before that of the collec8ve team’s goal.

Looking for & Building Trust The Scenario

•  People in Zurich have started to distrust those in Krakow.

•  People in Krakow have started to distrust those in Zurich.

•  “Finger poin8ng” & blame has started.

•  There is an absence of trust!

Your Task

Agile teams have perfect moments to admit mistakes and weaknesses. Ø  When are they? Ø  If team-‐members do trust each other, what do you hear when they talk?


ü  Sprint Planning

ü  Standups

ü  Review

ü  Retrospec8ve

ü  Backlog Grooming

ü  “I need help”

ü  “I made a mistake”

ü  “I found an issue, can we look together”

ü  “Your work was great”

ü  “This is taking longer than I thought”

ü  “Sorry, my assump8on was wrong”

ü  “I am not familiar with this code, who can help me?”

ü  “You said you’d work on this… why have you not done so?”

Remote Teamwork

Remote Teamwork The Theory

Control from ZH

Krakow Autonomy

Freedom in a Framework

Top-‐Down

Bo?om Up

“Agile” is the framework

Them and Us!

Remote Teamwork The Scenario

Like 85% of teamwork, this team is remote (Zurich and Krakow). People think that only co-‐located teams can be Agile.

Your Task

Discuss the reality that 85% of teams are not co-‐located. Then think about: Ø  How far away do you have to be, to be “remote”? Ø  Why is being Agile actually be?er for a remote team?

Remote Teamwork

ü  In the next room

ü  When you cannot hear a conversa8on

Community Decay

50

Trust Mo8va8on

Time

Face-‐to-‐face event


Remote Teamwork

Community Decay

51

Trust Mo8va8on

Time



“Communica8on Decay”

Remote Teamwork

How Does Agile Help?

52

Trust Mo8va8on

Time



Through Frequent Planning, Standups, Reviews, Grooming and Retrospec8ves

Remote Teamwork

Performance Reviews

Performance Reviews The Scenario

You are now “Agile” your teams are working well. However, people s8ll have personal goals based on SMART deliverables.

Your Task

Discuss the reality that the teams cannot “predict” their deliverables: Ø  What could be reviewed instead? Ø  Who should review it? Ø  Do we s8ll match performance to bonus?

Performance Reviews

ü  Reward good “Agile” behavior

ü  Never 8e performance to a bonus

ü  Manager should never evaluate

h?p://www.management30.com/workout/merit-‐money/ Jurgen Apello:


Performance Reviews



Remote Team

Percep8

on


Remote Teamwork


Performance Reviews



Remote Team

Percep8

on


Remote Teamwork

Con8nuously Review

Improve Everything

We are S8ll Improving…

Next Week: ATDD, “Hardening”, Planning

An awesome Website needs PEOPLE

to deliver RESULTS

Any Ques8ons?

PlaNorm Link

Telephone +41 79 936 7060

Email [email protected]

Homepage www.mcpa.biz

Library www.mcpa.biz/blog

Xing h?ps://www.xing.com/profile/Ma?hew_Caine

LinkedIn h?p://ch.linkedin.com/in/ma?hewcaine

Twi?er mc_mcpa

Skype mc_mcpa

YouTube h?p://www.youtube.com/MCPartnersAssociates

Stay in Contact

Support Material

Remote Team Perspec8ves

•  Team 1 – Zurich’s View Mike is paying for the work. We know that Nolan is responsible for the whole thing with lots of help from Claire who works with the users. Piotr helped to define the architecture together with Lukas, Casper and Pawel who are developers. Claire tests and Eloise is looking amer the backlog. Nolan organises the retrospec8ves and Casper is running the daily sprints in Krakow.

Remote Team Perspec8ves

•  Team 2 – Krakow’s View Mike is paying for the work. We know that Nolan is responsible for the whole thing and gives us our sprint backlog. Casper is our team leader with Lukas, Piotr and Pawel who are developers. We also ask Casper for help with the technology. Anna tests and Eloise is our BA. Nolan organises the retrospec8ves and Casper is running the daily sprints in Krakow.

PAM Summit Cracow, The ABB.com goes Agile Story

Technology

Transcript of PAM Summit Cracow, The ABB.com goes Agile Story