Flash Meetings for software champions

transcript

www.thalesgroup.com

Legal E

Flash-meetings for

sw development

11/2012

Emmanuel CHENU, Thales Avionics, CC NAV

emmanuel.chenu@fr.thalesgroup.com

Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A. This document is the property of Thales Group and may not be copied or communicated without written consent of Thales S.A.

Framework

Framework: PDCA

What is the problem? the impacts? the root causes?

What is the plan to assess the root causes?

What experiments are led according to the plan?

What results are measured when running the experiments?

What have we learned? adjusted? standardized?

Context

Plan / Problem

Problem: «Unsatisfied with our project weekly meetings»

Plan / Problem

#1 Duration:

. 1h is too long ...

Plan / Problem

#1 Duration:

. Pause activities for a full hour!

Plan / Problem

#1 Duration:

. Lack of dynamism & efficiency ...

. Loss of focus on the highest priority topics (waste, no

respect)

Plan / Problem

#2 Delay:

. Problems are assessed too late (1 .. 7 days latency)

. Out-of-date data (1 .. 7 days latency)

. Impact of daily work

- is not obvious

- is visible too late to steer activities

= «Steering a project with a 1-week delay»

Plan / Impacts

Impacts:

. Participation is not systematic

. Loss of interest & of implication in the project

. Team performance below expectations

Plan / Root causes

Root cause #1: The periodicity of the meeting is too low

=> accumulation of problems (7 days)

=> out-of-date data (1 .. 7 days)

=> missed synchronization points

Frequency of meeting < Frequency of problems (Nyquist-Shannon)

1 week stockpile of

problems, data & missed

synchronizations,

processed once a week

Plan / Root causes

Root cause #2: Duration is too long

=> Focus is not maintained on the highest priorities

=> Part of the meeting is waste (no value, no respect)

Plan / Strategy

#1 Lower the duration of the meeting (<< 1h)

#2 Raise the frequency of the meeting (>> 1/week)

Initial situation

Target situation

duration

period 7d 1 .. 7d

duration

period <<7d

Practice 15-minute Daily Flash-Meetings

2 teams are practicing the

following standard

To raise periocity of project

steering (daily << weekly)

To reduce the duration of the

meeting (15 minutes << 1 hour)

#1 Kick-off

. Every day: same place, hour, & duration

. Daily-leader rotation according to displayed calendar

. All members stand facing large charts & task-board

. Only daily-leader is seated, facing charts, editing iteration backlog on a computer

#2 Nightly build

. The daily-leader

. reports the status of the nightly build

. organizes further analysis or corrective actions (if required)

The nightly build

- builds the executable files,

- runs the unit-tests,

- runs the acceptance tests,

- measures the product quality

- ships the product

- controls the andon

#3 Product quality

. The team

. reports the quality metrics

. updates the quality charts

. organizes further analysis/corrective

actions (if required)

#3 Product quality

= # lines of code not fully covered by tests

+ # warnings in the code & tests

+ # times the coding standards are not fulfilled

+ # traceability errors

+ # complex operations

+ # 'todo' & 'fixme' tags in the code & tests

+ # new tickets to estimate

+ # opened tickets

#4 Development tasks

. The daily-leader

. runs through the tasks by order of priority

. The team

. reports status (expenses, progress, estimates, problems)

. updates the work-in-progress on the task-board

. The daily-leader

. updates expenses, estimates in the iteration backlog

. Available team members

. pull new tasks from the iteration backlog

#4 Development tasks

! If the team reports complex problems or technical issues

the daily-leader invites the stakeholders to resume the topic after the daily flash-meeting

! The task-board displays the WIP in the VSM:

Task-board

#5 Team performance

. The daily-leader

. reports the team performance to the team (costs & progress; quality already

reported!)

. The team

. updates the performance charts

(costs & progress)

. analyzes the performance

. organizes corrective actions

(if required)

#1 Regular practice

. Every working day >7 years = >2500 flash-meetings

. 5 teams involved

. 7 < team members < 50 (large team / 4 teams)

#2 Frequency & duration

. 15min < duration / meeting < 20 min

. 1h15 < duration / week < 1h40

=> overall time spent in meeting has not been reduced ...

#3 Focus

. with 15min target duration, all non-value information is

removed

. reduce duration to focus on highest priorities

. focus: steering, performance & problems

#4 Visible team performance

. Progress, costs & quality are displayed & up-to-date

(daily)

. Problems are displayed, analysis & corrective actions in

progress

. Shared vision

- of tasks & priorities

- of team performance (progress, costs & quality)

. WIP is visible (with problems: dependencies &

bottlenecks)

=> sw development is now visible!

#5 WIP & product quality

. wip is reduced in 2 scales (1 day, 2 weeks)

. product quality improves at each iteration

#6 Implication

. Every day:

- Team members attend & participate

- Daily team leader rotation

. Team members concerned by costs, progress & quality

#7 Continuous improvement

. The team practices continuous improvement:

Daily flash-meeting standard displayed & often improved

#1 The war-room

. Dedicated war-room (noisy meetings, room for charts)

#2 The schedule

. Not too soon => to gather data

. Not too late => to plan the day

. 9AM < kick-off < 9:45AM

. Time-slot booked in calendars!

#3 Computers

. Only for the daily team leader!

. Large screen => failure

. Focus on the action, not on the screen!

Turned-off

#4 Daily-flash meeting = PDCA

. Plan:

- Define the conditions of success for today

- Plan today’s tasks to meet success

- Perform today’s tasks

. Check:

- Tomorrow, check performance (is success fulfilled?)

. Act:

- According to performance, adapt behavior in order to succeed

#5 Work-in-progress

Daily flash-meeting + nightly build

= daily cycle within which tasks are DONE

=> reduces WIP

#6 Visible impact & motivation

. Visualize the impact of a day of work on common goals

. The team sees it can make a difference

=> enhances autonomy & motivation

#7 Project steering

. A single iteration burndown is not enough to steer

activities of the iteration

Milestone (days)

Amount of work (%)

Focus is on

completion of

work within

the milestone

#7 Project steering

. Focus on completion of work within a miletone (progress)

. But, what about:

. costs?

. product quality?

#7 Project steering

Visualize problems: OK

But, what is the problem?

#7 Project steering

Amount of work (%)

Amount of work (%) Amount of work (%)

Milestone (days)

Allocated budget (days)

Focus on costs

Focus on progress

Add a focus on costs!

#7 Project steering

Full scope Per functionality

progress

Add progress & costs per functionality/feature!

#8 Learning

Daily flash-meetings develop skills:

. to lead meetings

. to organize self-directed work with pulls systems

(autonomy!)

. to identify & solve problems (problem solving develops

skills!)

. to steer activities

. to share knowledge > 1 / day

. and ...

#9 Continuous improvement

. Daily flash-meetings = case study to learn & practice

continuous improvement

. Everyone is involved

=> The know-how is then used for other issues

#10 Discipline

. The meeting must occur!

. Tight time-schedule

. Focus on relevent information

#11 Respect

Daily flash-meetings = environment where the team:

. shares goals, responsability & success

. develops skills & autonomy

= RESPECT for people, their work & their time

THANKS

Flash Meetings for software champions

Technology