What it Really Means to Be Agile

What it really means to “be agile”

Kent J. McDonald@beyondreqs

Agenda Overview

Doing Agile vs. Being Agile

Key Ideas in Agile What does this mean

for Project Managers?

We interrupt this presentation for a quick survey…

Doing AgileVs.

Being Agile

From Agile2012

Doing Agile

Being Agile

What is an agile mindset?

People are…A. CogsB. Resources that need extrinsic motivationC. Human beings with intrinsic motivation.

People are…A. CogsB. Resources that need extrinsic motivationC. Human beings with intrinsic motivation.

http://finding-marbles.com/2011/12/10/agile-mindset-examples/



People are good at their jobs because…A. They put in effort and always learnB. They’re just more intelligentC. Where I work, no one else is good.

People are good at their jobs because…A. They put in effort and always learnB. They’re just more intelligentC. Where I work, no one else is good.




Decisions are taken…A. By management after conferring with the

people impactedB. By managementC. By someone up the hierarchy and we never get

informedD. Usually by consensus among the people that

are impactedE. Implicitly. We muddle through.

Decisions are taken…A. By management after conferring with the

people impactedB. By managementC. By someone up the hierarchy and we never get

informedD. Usually by consensus among the people that

are impactedE. Implicitly. We muddle through.




You build the right products by…A. Rigorously analyzing requirements and

writing detailed specs.B. Frequently showing it to the customer and

prospective users

You build the right products by…A. Rigorously analyzing requirements and

writing detailed specs.B. Frequently showing it to the customer and

prospective users



Retrospectives are…A. Not necessary anymoreB. Only done after a projectC. A place to rant about the same problems

every iterationD. A way to find improvements and implement

them.E. What’s a retrospective?


Retrospectives are…A. Not necessary anymoreB. Only done after a projectC. A place to rant about the same problems

every iterationD. A way to find improvements and implement

them.E. What’s a retrospective?



When trying to improve…A. Not only do we change, we oscillate.B. What is the simplest thing that will work?

What can we start right now? Can we use something physical?

C. Obviously we need a tool/framework/process.

D. We never try to improve.


When trying to improve…A. Not only do we change, we oscillate.B. What is the simplest thing that will work?

What can we start right now? Can we use something physical?

C. Obviously we need a tool/framework/process.

D. We never try to improve.




When people show undesirable behavior, you…A. Do nothing.B. Give feedback so they might change.C. Give feedback, but also check whether the

system inadvertently rewards said behaviorD. How should I know what’s undesirable?

When people show undesirable behavior, you…A. Do nothing.B. Give feedback so they might change.C. Give feedback, but also check whether the

system inadvertently rewards said behaviorD. How should I know what’s undesirable?




Something needs clarification, you…A. Do nothing.B. EmailC. Call themD. Talk to them in personE. Clarify it, but don’t tell anyone so that several

people clarify it independently.


Something needs clarification, you…A. Do nothing.B. EmailC. Call themD. Talk to them in personE. Clarify it, but don’t tell anyone so that several

people clarify it independently.



Documentation is…A. There’s none. Haven’t you read the

Manifesto?B. OutdatedC. Extensive and hard to maintainD. Just enough. When you discover something’s

missing, you add that particular part.


Documentation is…A. There’s none. Haven’t you read the

Manifesto?B. OutdatedC. Extensive and hard to maintainD. Just enough. When you discover something’s

missing, you add that particular part.


Key Ideas in Agile

From Ron Jeffries

KEY IDEAPut people with needs in direct contact with people who can fulfill those needs

How we’ve done it.

Stakeholders Involved only here

What are your requirements?

The stakeholder goes away….

Design

Implementation

6 Months Later…

Here’s what you asked for, please

go test it.

Verification

This isn’t what I

wanted!

It’s what you asked

for!

This doesn’t work.

Stakeholders Involved only here

Involve your stakeholders

Best: stakeholders sit with project team full time

Still quite good: regular touch points with stakeholders

Bare minimum: Demo with stakeholders every couple of weeks

Active conversation looking at work, not a meeting

This also means no intermediaries!

A stakeholder’s perspective“…it [agile] allows for interaction directly between the business and the developers. While waterfall allows the business to review specs prior to development, agile allows the business to see the actual development while it’s in process. We’re able to see the developer’s interpretation of the requirements before development is completed and make changes/tweaks as necessary. This has proven to be very beneficial as we’re able to show code to the end users while it’s still in a state where changes can be made.”

KEY IDEAPopulate projects with all the needed people and capabilities to get the job done

Instead of a team built on rolesLead Business Analyst

Sr. Business Analyst

DevelopmentLead Sr.

Developer

Sr.Developer

Architect

ProjectManager

Test Lead

QAAnalyst

UX Analyst

Build one based on skillsAnalysis Development

Testing

UX

Ideal - Build a Real Team

7 +/- 2 People Necessary skills No defined roles Focused on one project Bring work to the team,

not the other way around

Have them sit together

Making it work

Select based on skills, not roles

Allow team members to focus for blocks of time (at least half a day)

Provide tools to help communication

Selecting a Program Team

What if the team is already formed and a change is needed?

KEY IDEABuild work

incrementally and check results as you

go

Meaningful feedback does not come from specs

Meaningful feedback comes from seeing actual product

We need real feedback sooner than after we’re done

We really don’t know if it’s right until here.

The more often we deliver, the more often we learn.

Identify

Scenario

Change

product

Use produc

t

Reflect on

results

Based on Kolb Learning Cycle

How to increment

Organize work by feature delivered

Fit work into time boxes Deliver small bits of

production quality work at the end of each time box

Learn from each delivery.

Incrementing a Data Warehouse

KEY IDEAPrepare for and influence the future but don’t predict it

Historic views on plans

[In preparing for battle] I have always found that plans are useless, but planning is indispensable.Dwight D. Eisenhower

It is a mistake to look too far ahead. Only one link in the chain of destiny can be handled at a time.Winston Churchill

A good plan violently executed right now is far better than a perfect plan executed next week.

George S. Patton

It is a bad plan that admits of no modification.Publilius Syrus

No [campaign] plan survives first contact with the enemyField Marshall Helmuth Graf von Moltke

Incorrect assumption about projects

The Plan is always correct. If something does not go according to plan, we messed up implementation.

Incorrect assumption about agile

Are you planning? Are you planning? ARE YOU PLANNING? There's no planning! THERE'S NO PLANNING IN AGILE!

Shi[f]t Happens

Planning Levels

Product vision

Product roadmap

Release plan

Sprint plan

Daily plan

Yearly by the Product Owner

Bi-yearly by the Product Owner

~quarterly by Product Owner and Team

Every 2 weeks by the Product Owner and Team

Daily by the team

“But the Plan said we’re supposed to start on the next release”

KEY IDEAMake tasks concrete and quickly finish them.

Small chunks of value delivered in each iteration

Tasks of 4 – 16 hours to deliver those chunks of value

Wishlisting.org

KEY IDEAGive people work to do and the knowledge to do it, do not push them around like pawns on a chessboard

Shocking Admission

Most “teams” act more like workgroups

High performing project teams should resemble communities

Shocking Admission #2

People are not “resources”

Treat team members like… people

Shocking Admission #3

3(a) Multi-tasking is not effective.

3 (b) People do not multi task. They switch rapidly between areas of focus

Let them focus.

“They’ll never volunteer for tasks”

KEY IDEAFocus on providing value frequently and rapidly, not directly on cost

Success is not based on a triangle

Cost Schedule

Scope

Success is based on meeting objectives

As Steve Denning would say: “Delighting Customers”

Address first, or phone first?

What does this mean for PM’s?

You need great relationships with your customers

Act like a kid from Ottumwa

Learn the Leadership 2 Step

Channel your inner Coach

Come see my talk this afternoon

Want another perspective?

If you remember nothing else…

Doing agile is using techniques

Being agile is changing your mindset

Tis better to be agile quietly than do agile gregariously

Questions?

Kent [email protected]@BeyondReqswww.beyondrequirements.comSlides available from:http://www.kbridgepartners.com

mailto:[email protected]

http://www.beyondrequirements.com/

http://www.knowledgebridgepartners.com/

http://www.knowledgebridgepartners.com/

What it Really Means to Be Agile

Business

Transcript of What it Really Means to Be Agile