Essential Patterns of Mature Agile Teams

Essential Patterns of
Mature Agile Teams

Bob Galen
President & Principal Consultant
RGCG, LLC
bob@rgalen.com

Introduction
Bob Galen
n 
n 
n 
n 
n 
n 
n 
n 

Somewhere ‘north’ of 30 years experience J
Various lifecycles – Waterfall variants, RUP, Agile, Chaos…
Various domains – SaaS, Medical, Financial Services, Computer
& Storage Systems, eCommerce, and Telecommunications
Developer first, then Project Management / Leadership, then
Testing
Leveraged ‘pieces’ of Scrum in late 90’s; before ‘agile’ was ‘Agile’
Agility @ Lucent in 2000 – 2001 using Extreme Programming
Formally using Scrum since 2000
Currently an independent Agile Coach (CSC – Certified Scrum
Coach, one of 50 world-wide; 20+ in North America)
q 

n 
n 

at RGCG, LLC and Director of Agile Solutions at Zenergy Technologies

From Cary, North Carolina
Connect w/ me via LinkedIn and Twitter if you wish…
Bias Disclaimer:
Agile is THE BEST Methodology for Software Development…
However, NOT a Silver Bullet!

Copyright © 2013 RGCG, LLC

2

1

First, let’s explore…
n 

What are the basics of “Agility”

n 

What would be indicators (patterns) of Agile maturity?

n 

What about Agile immaturity?

n 

Let’s rank order some of them; I.e. what do you think are
the more impactful patterns in either direction?


3

The SCRUM Framework
Do we need to review it?


4

2

Three Common
Meta-Patterns
n 

Achieving Agile Maturity
q 
q 
q 

n 

Simplicity of the ‘Methods’
q 
q 

q 

n 

Many teams seem to have a false sense of over-maturity
Teams become complacent or plateau; often regressing over time
Can you have too much self-direction?
“doing Agile” is easy; “being Agile” is much harder and continuous
Organizations, teams, and individuals often wait till the last minute to ask
for help
Internally - retrospectives are the key; Externally - get a ‘compatible’
coach

Culture seems to be the largest “failure factor”
q 
q 
q 

Scrum can be quite disruptive; Kanban can be less so…
All-in vs. incremental? Salesforce.com as a commitment model?
Generally, how do we handle the term… Commitment?


5

“Doing” Agile vs.
“Being” Agile?
n 

One debate in the agile community surrounds agile maturity. A way
of characterizing it surrounds
q 

q 

Doing Agile – focusing towards is tactics, ceremonies, and techniques
vs.
Being Agile – focusing towards team mindset, leadership mindset,
behaviors, organizational adoption, etc.

n 

As an entry exercise, can we brainstorm aspects of Doing vs. Being
to capture how you view the differences?

n 

The Mature Patterns workshops sort of crosses both, with an
emphasis towards the Being-side of the equation.


6

3

Outline
Maturity Patterns
1. 
2. 
3. 
4. 
5. 
6. 
7. 

Truly Emergent Architecture
Aggressive Refactoring
Pursue Ruthless KISS
Behaving Like a Team
Truly Collaborative Work
Lean Work Queues
Performing Extraordinary
Facilitation
8.  Quality on ALL Fronts
9.  Testing is Everyone’s Job
10.  Active Done-Ness
11. Stopping the Line
12. Investing in Serious CI

13. Product Ownership takes a Village
14. Pervasive Product Owners
15. The Nuance of a Healthy Backlog
16. Righteous Retrospectives
17.  The Power of Complete
Transparency
18. Doing More than Thought
Possible
19. Emphasize Strength-Based
Teams
20. Congruent Agile Measurement


7

For each pattern…
workshop discussions
n 

For sets or groups of patterns, we’ll pause and discuss the patterns
in small groups

Looking for examples where you’ve seen the pattern in operation
and have a story to tell
OR
n  Examples where you’ve seen related anti-patterns in operation and
have a counter-story to tell
n 

n 

Either way, we’ll be looking for group-based discussion around the
ways and means of achieving agile maturity


8

4

Technical


9

#1) Truly Emergent Architecture

n 

Comfortable with on-the-fly
de-composition;
q 

no BDUF!

n 

Sprint #0’s as appropriate

n 

Backlogs contain learning
activity – Research Spike
stories

n 

Architects work in “slices”
q 

q 

n 

Should demonstrate
architectural evolution in
Sprint Reviews


q 

Perhaps ‘skewed’ a bit forward from
other teams
Deliver architecture from within the
Scrum teams
Publish system metaphors,
guidelines, big picture views – to
keep everyone focused on goals
10

5

#2) Aggressive Refactoring
n 

It’s easy to refactor on new
work or greenfield project…so
clearly do that.
q 

n 

n 

Aggressive refactoring
Put it on your Backlogs
q 

n 

But what about hairy, old, fragile
code?

Justify / explain it in business
terms

Remember the relationship to
automation – making
refactoring effective & FearLess


11

#3) Ruthless KISS
n 

Getting LEAN deep into your
cultural DNA
q 
q 

q 

Fight complexity
People & Collaboration over
Process & Tools
Fight Gold-plating developing
(Just Enough) of
EVERYTHING!

n 

Deliver small increments (Just
in Time) and pay attention to
feedback

n 

Continuously engage your
Product Owner


12

6

Teaming


13

#4) Behaving Like a Team
n 

n 

Includes the Scrum Master and
Product Owner
Developing trust
q 
q 

q 

Congruent feedback
Getting the “Elephants” on the
table
Asking for help; helping each
other
n 

n 

Passionate debate; Healthy
conflict

n 

Succeeding or failing – as a
team

Spending personal time
together

n 

Strengths & weaknesses;
adjust to each; maximizing &
minimizing


14

7

#5) Truly Collaborative Work
n 

Co-located teams

n 

Avoiding Scrummerfall-like
dynamics
Stages and gates within the
team
Long queues with hand-offs

q 

q 

n 

Comfortable pairings
(across the team); Triad

n 

Listening to each other;
mutual respect, honor
experience

15

#6) Lean Work Queues
n 

Limiting WIP
q 

q 
q 

n 

Blending roles – individuals
doing more themselves and
handing off less
q 

n 

Fewer things “in process” and
small tasks
Visible workflow
Kanban is interesting variant of
the ‘correct’ team behavior

Swarming!

Think in terms of reducing &
eliminating WASTE


16

8

Kanban
Iteration-less Production


17

#7) Performing Extraordinary Facilitation
n 

Grooming meetings
q 

q 

n 

Everyone on the team
facilitates
q 
q 

n 

Discussions are at the “right
level”
Win-win discussions

Off-line action setting
Planning meetings

Teams get options on the table
and pick best solutions
q 
q 

Craftsmanship
Technical debt


18

9

Quality & Testing


19

#8) Quality on ALL Fronts
n 

Leaving behind the notion of
“Testing in quality…”

n 

Professionalism within the team
q 

n 
n 

Self-inspecting; self-policing
Just enough quality
q 

n 

Doing the right things…doing
things right

Quality has a cost and should
be variable based on your
context

Focus on Craftsmanship and
Professionalism


20

10

#9) Testing is Everyone’s Job
n 

Willingness on the part of the
whole-team to pitch in for
testing
q 
q 
q 
q 

All types, even manual
Extending it to test automation
Never letting tests break
Building in testability

n 

Listening to test estimates as
part of work estimation

n 

Understanding functional and
non-functional testing

n 

Root Cause Analysis as a team


21

#10) Active Done-Ness; Readiness
n 

Actively create and automate
Acceptance Tests on a Story or
a Feature basis
q 

q 

n 

Have established a view to
multiple levels of Done-Ness
q 
q 
q 
q 

n 

Customer heavily involved with
definition
Not functional tests

Work - Done
Story Acceptance
Sprint Goals
Release Criteria & Goals

Think in terms of traditional
Entry, Exit, and Release criteria


22

11

Levels of Criteria
Activity

Criteria

Basic Team
Work Products

Done’ness criteria

User Story or
Theme Level

Acceptance Tests

Sprint or
Iteration Level

Done’ness criteria

Release Level

Release criteria

Example
Pairing or pair inspections of code prior to check-in; or
development, execution and passing of unit tests.
Development of FitNesse based acceptance tests with the
customer AND their successful execution and passing.
Developed toward individual stories and/or themes for sets
of stories.
Defining a Sprint Goal that clarifies the feature
development and all external dependencies associcated with
a sprint.
Defining a broad set of conditions (artifacts, testing
activities or coverage levels, results/metrics, collaboration
with other groups, meeting compliance levels, etc.) that IF
MET would mean the release could occur.


23

#11) Stopping the Line!
n 

Fix your bugs
q 

q 

n 

Build is broken ?
q 

n 

Build it!

Need to refactor ugly legacy code
that is bug infested?
q 

n 

Fix it!

Need automation for a key area?
q 

n 

Ruthless testing; immediate
testing; immediate feedback
Less logging more fixing

Refactor it!

Key impediments to your team?
q 

Resolve them!


24

12

#12) Investing in Serious CI
n 

Build on every check-in
q 

q 

n 

Automation everywhere!
q 
q 

n 

All artifacts – DB code (stored
procedures, structure)
Automated deployments to
environments (real and/or
virtual)

Dashboards
Lava lamps

Serious focus – dedicated team
q 

q 
q 

Tools are only part of the
answer
Develop infrastructure
Continuous refactoring of CI


25

Product


26

13

#13) Product Ownership takes a Village
n 

Fostering an environment
where the entire team ‘owns’
the Product Backlog
q 
q 

n 

Shared—
q 
q 
q 

n 

Freely contributes User Stories
Passionate debate on priority,
themes, and release goals

Vision & Goals
Business Values
Technical direction

Functional, Technical, and
Product ‘voices’


27

#14) Pervasive Product (Customer) Owners
n 

Can be a ‘team’, but needs a
unified decision-maker
q 

Organizationally ‘sticky’
decisions

n 

Engaged as a team member

n 

Outwardly focused toward the
market & stakeholder demands
q 

n 

Advocate for the team

Engage the customer and
stakeholders
www.leadingagile.com


28

14

#15) The Nuance of a Healthy Backlog
n 

Considering it a tapestry of
work that is considered in turn:
q 
q 
q 
q 
q 

n 

As well, planning
q 
q 
q 

n 

Architecture & design
Quality & Test Automation
Technical debt, Infrastructure
Bugs
Innovation & creativity
Feature workflow & value
Dependencies & risk
Ultimately deployment

Never ‘done’ grooming; iterative


29

Organization


30

15

#16) Righteous Retrospectives
n 
n 

For the team!
Remember Norm Kerth’s
“Prime Directive”:
q 
q 

n 

Everyone tried their best
Safe environment

Drives “Continuous
Improvement”
q 

Challenge one other!

n 

Get the “Elephants” out in the
open

n 

Be creative – try new things;
take some risks


31

#17) The Power of Complete Transparency
n 

Opening up your stand-ups &
Sprint Planning to everyone
q 

n 

n 

Rampant Information Radiators
Tell it like it is
q 
q 
q 

n 

Even sales folks and customers

Congruent truth-telling
Courage
Success or Failure

Expect organizational
engagement – questions,
suggestions, trade-offs towards
core goals


n 

It is what it is…now how do we
ADJUST towards our GOALS

32

16

#18) Doing More than Thought Possible
n 

Stretch goals within Sprints

n 

Creative
q 

q 

q 

n 

solutions – not simply following
the Story or Task lists
exploring alternatives with
Product Owner
The Wisdom of Crowds

Iterations that lead towards…
“Good Enough”
n 

n 

Fighting Parkinson’s Law and
Student Syndrome


Supporting – Slack Time
q 
q 
q 

Innovation Time
Creativity thinking
Experimentation
33

#19) Strength-Based Teams
n 

Individuals focus on what they’re
good at; enjoy
q 

n 

While still ‘stretching’ themselves

Notion of Appreciative Inquiry
leveraged in retrospectives
q 

And continuous improvement

n 

Team-building - interview for
complimentary strengths

n 

At scale, consider strengths
q 

q 

When Release Planning – loading
work
Load-balancing teams by skill-set


34

17

#20) Congruent Agile Measurement
n 

Don’t focus too heavily on
metrics; instead on results

n 

Look for measures
surrounding–
q 

q 
q 
q 

n 

Value Delivered & Customer
Delighted
Quality being Built-In
Team Health & Morale
Productivity & Predictability

1-2 measures per area
q 
q 

Focus on trending
Behaviors

n 

Traditional measures can lead
to Metrics Dysfunction
q 

q 

Measure bugs for reward…get
more meaningless bugs
Measure LOC for reward…get
more meaningless LOC


35

Workshop
Wrap-up
n 

What were the most compelling
patterns?

n 

What essential patterns did I miss?

n 

Final questions or discussion?

Thank you!

36

18

Contact Info
Bob Galen
Principal Consultant,
RGalen Consulting Group, L.L.C.

Experience-driven agile focused training,
coaching & consulting
Contact: (919) 272-0719
bob@rgalen.com
www.rgalen.com

Blogs
Project Times - http://www.projecttimes.com/robert-galen/
BA Times - http://www.batimes.com/robert-galen/
Podcast on all things ‘agile’ - http://www.meta-cast.com/


37

19

Essential Patterns of Mature Agile Teams

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Essential Patterns of Mature Agile Teams

Similar to Essential Patterns of Mature Agile Teams (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Essential Patterns of Mature Agile Teams