Agile Introduction

53
1 ironworks.com Introduction to Agile ICF PM Group Presentation 4/2/2013

Transcript of Agile Introduction

Page 1: Agile Introduction

1ironworks.com

Introduction to AgileICF PM Group Presentation 4/2/2013

Page 2: Agile Introduction

2

Pomodoro 1: The Promise of Agile• What problems in software development does Agile address?• Where does Agile fit in the Universe of Methodologies• What is Agile – from Squishy to Solid?• What is the Promise of Agile?• What flavors does Agile come in?• The Current State of Agile

Pomodoro 2: A day/week/month in the life of …• A Scrum Team• A Kanban Team• A Scaled Team

Lean Coffee Retrospective: Agile Dunk Tank

Agenda

Page 3: Agile Introduction

3

Businesses are looking for an approach to software development approach that offers:

• Predictability and Transparency

• Right-sized, just- enough, and just-in-time

• Responsive to rapid market change

• Incremental, and iterative delivery to delivery value, early and often

• Quality built in along the way

Agile Addresses: Software Development is Complex

Page 4: Agile Introduction

4

Predictability: What has recent history told us ?

The Standish Group’s CHAOS report results from a 40,000 projects

Top reasons for success1. User involvement2. Executive support3. Clear objectives4. Optimizing scope5. Agile process

199416% Succeeded≈170% overrun

200432% Succeeded≈70% overrun

“Doing projects with iterative processes as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”Jim Johnson, Chairman of Standish Group

Page 5: Agile Introduction

5

Sometimes; 16%

Rarely; 19%

Never; 45%

Always; 7%

Often; 13%

Feature Usage in Software Projects

Has Product Development produced Just enough, Just in time?

Always or often used20%

Never or rarely used64%

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Page 6: Agile Introduction

6

Agile Accelerates Value Delivery: Incremental and Iterative

4 444 :Documents Documents Unverified Code Software

Page 7: Agile Introduction

7

Transparency: Do Agile Practitioners listen to the Business?

VersionOne: 7th Annual State of Agile Development 2013

Manage distribute teams

Increase engineering discipline

Simplify dev process

Improve team morale

Reduce risk

Enhance maintainability

Reduce cost

Project visibility

Enhance software quality

Better Align IT/business

Manage changing priorities

Accelerate time to market

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

4

7

10

7

11

8

10

15

17

3

29

30

24

35

42

38

45

39

34

45

50

41

49

43

33

42

37

40

36

39

39

20

26

25

19

22

38

16

11

15

8

14

17

10

7

11

3

5

Highest Very Somewhat Not

Page 8: Agile Introduction

8

What is Agile? – Squishy to Solid

NoDiscipline

Process ? Fad ? Methodology ?

Cult?

NoDocumentation

Framework ?

Approach ?

NoPlanning

NoPlanning

Chaos

Page 9: Agile Introduction

9

Mindset

Agile is a mindset

Learn through Discovery Collaboration Failing Early Seeking Feedback for

learning Strive for Continuous

Delivery Focus on Value

A mindset is the established set of attitudes held by

someone

Page 10: Agile Introduction

10

Values

Mindset

Agile is a mindset defined by values: Agile Manifesto

A Value is an establishedideal that the members

of a given society regard as desirable

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

Page 11: Agile Introduction

11

Principles

Values

Mindset

Agile is a mindset defined by values guided by principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Page 12: Agile Introduction

12

Practices

Principles

Values

Mindset

… and manifested through many different practices

“We surveyed the Agile Community and came up with Over 70 Different

Practices”Ahmed Sidky, Santeon Group

Practices

Page 13: Agile Introduction

13

Practices

Principles

Values

Mindset

The various Agile flavors are combinations of practices

Practices

Flavor AFlavor B Flavor C

AGILE

Page 14: Agile Introduction

14

The Universes of Methodologies and Standards

Page 15: Agile Introduction

15

We’re used to Agile Expects

Time Lines Define Done, Build Quality in

Top Down Control/ Hierarchical Servant Leadership/Self managing teams.

Fixed Budgets Fixed Burn Rate

Predictable, all at once deliverables Incremental deliverables driven by value

Multiple matrixed departments, part time commitment of resources

Co-location – one team.

Communication by Document Just enough documentation to start conversation

Customer is “managed” Customer is part of team.

Certain Knowledge Uncertainty solved by “IKIWISI”

Estimates and Actuals Empirical Results, Cone of Uncertainty

The Paradigm Shift from Waterfall

Page 16: Agile Introduction

16

There are Many Popular Flavors ……

Agile Principles

Scrum

SAFe

XP

DSDM

Crystal

Kanban (Lean)

Flavor Characteristics

Scrum “Reference Implementation” of Agile. Release, iteration and daily planning; prioritized backlog, demos, retrospectives, generalizing specialists. Time boxed

Kanban Focus of understanding how work flows, visualizing the work. Limit WIP. Often outside of SW.

SAFe: Agile @ Scale

Handles integrating multiples teams with program and portfolio layers

Extreme Programming (XP)

Technical focus on development practices. Prescribes practices that are commonly needed to make Scrum deliver high quality. Time Boxed.

Page 17: Agile Introduction

17

…. In the end it’s about the People …..

Page 18: Agile Introduction

18

• New(ish) role introduced by Agile.

• NOT the same as or a replacement of the Project Manager.

• Focus on relationships, listening, facilitating.

• The Agile SME

• Team facing not product facing!

About the Agile Coach

Page 19: Agile Introduction

19

An agile coach…

Coordinating individual contributions

Coaching forcollaboration

Being a subjectmatter expert

Being a facilitatorfor the team

Being invested inspecific outcomes

Being invested inoverall performance

Knowing the answer

Asking the team forthe answer

Directing Letting the team findtheir own way

Driving Guiding

Page 20: Agile Introduction

20

Product Owner

Page 21: Agile Introduction

21

Team Members

Developer [2-4]

Tester [1-2]

Agile BA for larger teams and Scaled Agile

Tech Lead especially for more developers

Technical Writer [Optional]

Specialist roles main join, FE Dev, DBA etc.

Different Sized Teams will benefit from different practices and Agile Flavors• Small 1-4• Medium 5-8• Large > 10

Page 22: Agile Introduction

22

Agile @ Scale: Beyond Team Delivery Models

Agile Enterprise

Scaled Delivery Teams

Agile Delivery Teams

Scaling Considerations

Enterprise:• Team size• Geographic distribution• Regulatory compliance• Domain complexity• Organization distribution• Technical complexity• Organizational complexity• Enterprise discipline

Scaled Teams:• Handoffs/Integration• Incoming and Outgoing

process contracts• Consistency

Team delivery:• Maturity• Construction of working

software; various delivery models

Software Project Management practices focused on delivering working, tested code every 2 – 4 weeks;Highly incremental delivery practices designed to improve code quality;

Program-level alignment to a common, larger mission. Synchronizing planning, development, integration, delivery and customer feedback

A set of Lean leadership principles, that include respect for people, continuous improvement, product development flow and executive sponsorship for a Lean Agile operating mode

Page 23: Agile Introduction

23

Pomodoro 1 is over!

5 mins at the end of the first time box

Questions?

Get and move to another seat!

Page 24: Agile Introduction

24

Pomodoro 2: A Day/Week/Month in the life of an Agile Team

What is the most important part of this go cart? – The brakes, they let you go faster Scrum uses time-boxed “breaks” Kanban uses Work in Progress “breaks” Agile @ Scale: A peak

at the bigger picture

Page 25: Agile Introduction

25

Scrum prescribes roles, artifacts and meetings

Scrum

Artifacts Roles

Meetings

Product Backlog

Sprint Backlog

Burndown Charts

Sprint Planning Daily

Meeting

Sprint Review

Product Owner

Scrum Master

Team

Page 26: Agile Introduction

26

Scrums aims to have a repeatable cadence to delivery

Page 27: Agile Introduction

27

Scrum Cadence

Every Release: The process begins with the product owner collecting and prioritizing requirements in a product backlog.

Every Sprint Beginning: Sprint Planning - The team and product owner work together to select the highest priority requirements/ stories that can be accomplished within a time boxed sprint.

Every Day: The ScrumMaster and the team have a daily scrum meeting.

Every Sprint End: The team demonstrates the completed features to the product owner.

• These features are a potential shippable product.

• The feedback gathered from the demonstration is fed back into the product backlog.

• The team then has a retrospective to determine what worked well, and what improvements need to be made to the process for the next sprint.

Page 28: Agile Introduction

28

What is a Story

Combination of• Requirements that combined

provide a standalone shippable feature

• Visuals to support the knowledge transfer

• Acceptance criteria: Definition of done to drive developer and guide testers

• Small enough to fit in a sprint and be estimable using tasks

Page 29: Agile Introduction

29

Sprint Planning where stories become tasks

Planning Units Ideal hours or days There are other units,

but these two are the most common

Purpose of Estimates Not for tracking time Scrum is results

oriented, not effort driven

Sprint Rules No changes during No change to sprint

duration Team takes work until

they’re fullVelocity How much work the

team actually accomplishes in a sprint

Page 30: Agile Introduction

30

Scrum board = Information Radiator for the Team

• The board Informs

• Highlights impediments

• Burndown shows progress

• Focus of daily meeting

• Swimlanes per story

• Done means shippable!

Page 31: Agile Introduction

31

Scrum: The day starts with a daily meeting

15 minutes or less

Same time, same place – the board

Starts on time regardless with no role calls

3 questions

What I did since the last standup

What I will do before the next standup

What’s in my way

Yes, that’s it. That’s all. No more, no less. It’s a commitment meeting, not a status meeting.

Page 32: Agile Introduction

32

Sprint: Demo and Retrospect on the events of the Sprint

Preparation

• As little as possible

• Low tech, high impact

• No PowerPoint – this is not about slide ware, this is about showing real stuff

Page 33: Agile Introduction

33

Scrums can be linked for larger releases

Release 1

Sprint 1

Sprint Planning

Daily Standup

Retro and Demo

Sprint n

Sprint Planning

Daily Standup

Retro and Demo

Ideas

Product Backlog

Release Planning

Release Backlog

Sprint Backlog

Fixed Time and Resource

Not Done Sprint Backlog Not Done

Page 34: Agile Introduction

34

Lean and Kanban: First in factories, now front offices

ToyotaProduction

System

TQM

TOC

Just-In-Time

Six Sigma

Lean Healthcare

Lean Manufacturing

Lean Marketing

Lean Construction

60’s-80’s 80’s 90’s 2000’s Today

Focus is on the system: rapid flow and feedback, versus planning and “efficiency”

Enterprise Kanban

Page 35: Agile Introduction

35

Kanban in factories allowed decentralized decision making

Set priorities, not schedules

Enterprise Kanban

Kanban is Japanese for visual card

Page 36: Agile Introduction

36

The Kanban Method for Software

1. Visualize the workflow

2. Limit Work-in-Progress

3. Manage Flow

4. Make Process Policies Explicit

5. Improve Collaborativelyusing models and the scientific method

Page 37: Agile Introduction

37

Kanban does not prescribe roles, artifacts and meetings

Start with current process and focus on improvement

Focus on reducing cycle time in the system

Improvements are done “real-time” rather than waiting for retrospectives

Metrics are different reflective continuous flow

Page 38: Agile Introduction

38

For knowledge workers, Kanban = Post-ItTM Notes

Visualizing work provides immediate insight into flow (or not)

bottlenecks

Page 39: Agile Introduction

39

Kanban works well outside of IT

But sticky notes don’t scale, work for distributed teams, or track metrics

Page 40: Agile Introduction

40

Electronic systems support broader view

Enterprise Kanban

Page 41: Agile Introduction

41

Cumulative flow diagrams replace burndowns

Not based on estimates or percent complete – just card moves

Enterprise Kanban

Page 42: Agile Introduction

42

Electronic Kanban boards for distributed visualization

Enterprise Kanban

Page 43: Agile Introduction

43

Project A Project B Project C Project Z

Infrastructure QADevelopment

Multi-level Kanban Supports Scaling Enterprise PortfolioCards:Vertical Lanes:Swimlanes:For:

Key ProjectsQuarters

Lines of BusinessCIO & Peers

Project BreakdownCards: Vertical Lanes:Swimlanes:

For:

DeliverablesMonths

FunctionsProject Leads

DepartmentsOperations

or User StoriesProcess

Team Members

Cards:

Swimlanes:

For:

Road Map

Source Control Change Mgmt Test Planning

API IntegrationLink to multiple

systems

Enterprise Kanban

Page 44: Agile Introduction

44

SAFe Roots

Lean ThinkingProduct

Development FlowAgile Development

Field experience at enterprise scale

Iterative and Incremental

Development

Core Values:1. Alignment2. Code Quality3. Program Execution4. Transparency

Page 45: Agile Introduction

45

SAFe : Multiple layers need to interoperate

Page 46: Agile Introduction

46

Agile Teams act as foundations of productivity

• Empowered, self-organizing, self-managing teams with developers, testers, content authority

• Teams deliver valuable, fully-tested software increments every two weeks

• Teams apply Scrum and Kanban project management practices and XP technical practices

• Teams operate under program vision, system, architecture and User experience guidance

Page 47: Agile Introduction

47

Focus: Strategic Alignment. Code Quality.

Collective Ownership

Test-First:TDD

ATDD

Emergent Design

Scalability Required

Agile Analysis

Continuous Integration

XP Inspired

User Stories

SAFe Scrum

XP Inspired Technical Practices

Strategic Alignment Sprint and PSI/Program

objectives

Aligned sprints and velocities

Program architecture and UX Guidance, governance

Lean prioritization

Code Quality Test First: TDD and ATDD

Continuous integration: component and system

Test automation

Fortnightly system demonstration

Page 48: Agile Introduction

48

Focus: Program Execution. Transparency.

Program Execution Economic prioritization

Frequent, evaluable, quality deliveries

Fast customer feedback

Fixed, reliable cadence

Fast tracking to actual needs

Transparency All backlogs and progress visible

to all stakeholders

Objective reporting based on working code

Everyone understands capacity, velocity, WIP

Page 49: Agile Introduction

49

Scale to the Program Level

A self-organizing, self-managing team-of-agile-teams committed to continuous value delivery

Organized around enterprise value streams

Aligned to a common mission

Delivers fully tested, system-level solutions every 8-12 weeks

Common sprint lengths and normalized velocity

Face-to-face planning cadence provides development collaboration, alignment, synchronization, evaluation

Page 50: Agile Introduction

50

Develop on Cadence. Deliver on Demand.

Deliver on Demand

Develop on Cadence

Customer Upgrade

Customer previewDocs and

certsQA-Release to Market- Governance Firewall

Major Release

Docs and certs

Feature Release

Major Release

PSI PSI PSI PSI PSIPSI

Page 51: Agile Introduction

51

Scale to the Portfolio

• Lean principles emphasize sustainably fastest value delivery • Portfolio vision guides investments and the enterprise architecture

needed to support customer and business needs• Business epic kanban system provides visibility and work-in-process

limits to support continuous product development flow• Enterprise architecture is a first class citizen; architectural epics are

developed and maintained in a kanban system• Objective metrics support governance and kaizen

Page 52: Agile Introduction

52

This session will run more like a Kanban team and can be used as a retrospective technique:

1. Creates 5 ideas for questions using 5 mins of the Crawford Slip Method

2. Get with a Business Unit and figure out the groups favorite 5 questions

3. Post to the backlog

4. Vote with Green dots

5. We will flow questions based on highest priority

6. We will answer each question given it 5 mins

7. If it needs > 5 mins we will ask the team “Enough or another 5”

8. Time Left? Yes - goto 5

9. No – You are released!

Lean Coffee Session

Page 53: Agile Introduction

53

Certification Opportunities (beyond initial training)• Supports both client engagements and internal resources/teams• Certified Scrum Professional • Certified Agile Coach • Certified Agile Trainer

ICF Agile/Lean Community• Connect internal pockets of Agile/Lean enthusiasts across ICF and

Ironworks• Create avenues for idea sharing• Promote Agile/Lean practices and training • Coaching internal key Agile roles

Local Agile/Lean Communities• Engage and support local communities (Agile Richmond, Capital

Kanban, LeanStartUP…)

Community Evolvement