Some teams think they can be agile by using a defined process or set of practices as defined by one of the agile approaches. This is just “doing Agile.” Other teams are agile in name only – the team says it’s “doing Agile” but ends up using the same old practices and achieving the same results. Teams adopt agile for a variety of reasons, but it’s not the process or set of practices they select that produces the results they seek. Teams are most successful when they adopt a particular mindset in order to “be agile”. Join Kent McDonald as he describes this mindset through 7 key ideas based on how people and organizations work best. We’ll discuss some specific techniques you can use to adopt the mindset on your project, how the project manager role changes along with the mindset, and how to help your team move from “doing Agile” to actually “being agile”.

1. What it really means to “be
agile”
Kent J. McDonald
@beyondreqs

2. Agenda Overview
 Doing Agile vs. Being
Agile
 Key Ideas in Agile
 What does this mean
for Project
Managers?

3. We interrupt this presentation for a
quick survey…

4. Doing Agile
Vs.
Being Agile
From
Agile2012

5. Doing Agile

6. Being Agile

7. What is an agile mindset?
People are…
A. Cogs
B. Resources that need extrinsic motivation
C. Human beings with intrinsic motivation.
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

8. What is an agile mindset?
People are good at their jobs because…
A. They put in effort and always learn
B. They’re just more intelligent
C. Where I work, no one else is good.
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

9. What is an agile mindset?
Decisions are taken…
A. By management after conferring with the
people impacted
B. By management
C. By someone up the hierarchy and we never get
informed
D. Usually by consensus among the people that are
impacted
E. Implicitly. We muddle through.
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

10. What is an agile mindset?
You build the right products by…
A. Rigorously analyzing requirements and
writing detailed specs.
B. Frequently showing it to the customer and
prospective users
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

11. What is an agile mindset?
Retrospectives are…
A. Not necessary anymore
B. Only done after a project
C. A place to rant about the same problems
every iteration
D. A way to find improvements and implement
them.
E. What’s a retrospective?
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

12. What is an agile mindset?
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.
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

13. What is an agile mindset?
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 behavior
D. How should I know what’s undesirable?
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

14. What is an agile mindset?
Something needs clarification, you…
A. Do nothing.
B. Email
C. Call them
D. Talk to them in person
E. Clarify it, but don’t tell anyone so that several
people clarify it independently.
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

15. What is an agile mindset?
Documentation is…
A. There’s none. Haven’t you read the
Manifesto?
B. Outdated
C. Extensive and hard to maintain
D. Just enough. When you discover something’s
missing, you add that particular part.
http://finding-marbles.com/2011/12/10/agile-mindset-examples/

16. Key Ideas in Agile
From Ron Jeffries

17. KEY IDEA
Put people
with needs
in direct
contact
with
people
who can
fulfill those
needs

18. How we’ve done it.
Stakeholders
Involved
only here

19. What are your
requirements?

20. The stakeholder goes
away….

21. Design

22. Implementation

23. 6 Months Later…

24. Here’s what you
asked for, please go
test it.

25. Verification

26. Thiswhat
It’s isn’t
what I
you asked
wanted!
for!

27. This doesn’t work.
Stakeholders
Involved
only here

28. 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

29. Active conversation looking at
work, not a meeting

30. This also means no intermediaries!

31. 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.”

32. KEY IDEA
Populate projects with
all the needed people
and capabilities to get
the job done

33. Instead of a team built on roles
Sr.
Lead Development
Business
Business Lead
Analyst Sr.
Analyst
Developer
UX Analyst Sr.
Developer
Architect
QA
Analyst
Project
Manager
Test Lead

34. Build one based on skills
Analysis Development
Testing
UX

35. 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

36. 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

37. Selecting a Program Team

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

39. KEY IDEA
Build work
incrementally and
check results as you
go

40. Meaningful feedback does not come
from specs

41. Meaningful feedback comes from
seeing actual product

42. We need real feedback sooner than
after we’re done
We really don’t
know if it’s right
until here.

43. The more often we deliver, the more
often we learn.
Identify
Scenario
Reflect
Change
on
product
results
Use
product
Based on Kolb Learning Cycle

44. 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.

45. Incrementing a Data Warehouse

46. KEY IDEA
Prepare for and
influence the
future but don’t
predict it

47. Historic views on plans
It is a bad plan that admits of no modification.
Publilius Syrus
No [campaign] plan survives first contact with the enemy
Field Marshall Helmuth Graf von Moltke
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
[In preparing for battle] I have always found that plans are useless, but
planning is indispensable.
Dwight D. Eisenhower

48. Incorrect assumption about projects
The Plan is always
correct. If
something does not
go according to
plan, we messed up
implementation.

49. Incorrect assumption about agile
Are you
planning? Are
you planning?
ARE YOU
PLANNING?
There's no
planning!
THERE'S NO
PLANNING IN
AGILE!

50. Shi[f]t Happens

51. Planning Levels
Product vision Yearly by the Product Owner
Product
roadmap Bi-yearly by the Product Owner
Release plan ~quarterly by Product Owner
and Team
Sprint plan
Every 2 weeks by the Product
Owner and Team
Daily plan
Daily by the team

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

53. KEY IDEA
Make tasks concrete and
quickly finish them.

54. Small chunks of value delivered in each
iteration

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

56. Wishlisting.org

57. KEY IDEA
Give people work to do
and the knowledge to
do it, do not push them
around like pawns on a
chessboard

58. Shocking Admission
Most “teams” act more like workgroups

59. High performing project teams should
resemble communities

60. Shocking Admission #2
People are not “resources”

61. Treat team members like… people

62. Shocking Admission #3
3(a) Multi-tasking is
not effective.
3 (b) People do not
multi task. They
switch rapidly
between areas of
focus

63. Let them focus.

64. “They’ll never volunteer for tasks”

65. KEY IDEA
Focus on providing value frequently and
rapidly, not directly on cost

66. Success is not based on a triangle
Scope
Cost Schedule

67. Success is based on meeting objectives
As Steve Denning would say: “Delighting Customers”

68. Address first, or phone first?

69. What does this mean for PM’s?

70. You need great relationships with your
customers

71. Act like a kid from Ottumwa

72. Learn the Leadership 2 Step

73. Channel your inner Coach

74. Come see my talk this afternoon

75. Want another perspective?

76. 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

77. Questions?
Kent McDonald
kentjmcdonald@gmail.com
@BeyondReqs
www.beyondrequirements.com
Slides available from:
http://www.kbridgepartners.com