These slides are from a talk that I gave to the Tampa Bay Agile Meetup on August 19, 2014. The talk was titled "Mastering Agile Practices to Build High Performing Teams". http://www.meetup.com/tampa-bay-agile/events/193898502/
Description:
You've read the books. You already know what your Agile team SHOULD be doing. Your Daily Standup meeting should be short and sweet. Your deployments should be automated. Your Sprint Retrospectives should inspire improvement.
So if you know what to do, why aren't you doing it?
The short answer is because Agile is hard. It takes real discipline and leadership to master even the most basic practices. Many teams have committed to adopting Agile, but they just don’t know how to get to the next level.
In this talk, I will share my real world experiences from years of coaching high performing Agile teams. I will discuss the key practices that must be mastered for a team to become great. Additionally, I will identify useful measurement techniques so that teams know if they are improving.
Software Project Health Check: Best Practices and Techniques for Your Product...
Mastering Agile Practices to Build High Performing Teams
1. Mastering Agile Practices
to Build High Performing Teams
Tampa Bay Agile Meetup
Steven Granese
Agile Coach & Consultant
Custom Software Development
8/19/2014
Steven.Granese@tribridge.com
www.sgranese.com
@sgranese
3. How Does Mr. Miyagi Establish Trust?
COMMITMENT
“First, make sacred pact. I promise - teach
karate. That my part. You promise - learn. I
say, you do. No questions. That you’re part.”
HABITS
“Wax On. Wax Off.
Breathe.”
DISCIPLINE
Repeat habits while
keeping commitment
4. A little about me….
• Psychology
• Organizational Change for Tech
• Business / Computer Science
Education
• Developer (CF, PHP, .Net)
• Director of Technology
• Manager of Development
• Software Consultant
Experience
Agile
since
2009!
5. Tribridge at a Glance
Nearly 600 team members
averaging 20 years of experience
in consulting and industry
15 years of profitability
One of Microsoft’s top partners –
Microsoft Dynamics Worldwide
Partner of the Year 4 times in 6
years (2008, 2010, 2012 and 2013)
Largest Microsoft Dynamics
customer base in North America
Big Five quality delivered through
practical methodologies and
intimate customer relationships
Received Ernst &Young
Entrepreneur of the Year award
6. TODAY’S AGENDA
• Team Formation Model
• Trust and Commitment
THEORY
• 10 Agile Practices
• Identify Top Habits and
Measureable Results
PRACTICAL
7. Storming
Forming
Norming
Performing
- Power struggles
- “Me”
- Fear and excitement
- Play it safe
- Engagement
- “You and Me”
- Shared goals
- “We”
COMMITMENT,
DISCIPLINE AND
TRUST
11. CODER
DEVELOPER
CRAFTSMAN
• Can read and write code
• Cannot build sustainable
applications by himself
• Can design/build solutions
• Often delivers bugs
• Focuses on technical
limitations
• Takes pride and ownership
• Rarely delivers bugs
• Focuses on users / business
• Trusted
Mike
Aaron
Linda
(Craftswoman)
13. User Stories
The Language of
an Agile
Organization
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
14. The Art of Writing Good User Stories
WHO WHAT
As a <user/role>, I want to <goal/desire>
so that <reason | benefit>.
WHY
I-N-V-E-S-T
HOW
15. User Stories – Examples
As a user, I want to my
view grades online so that
I can view them.
As a student, I want my
grades to appear on the
left side of the screen
with Helvetica font.
As an undergraduate
student, I want
electronic notification
of my grades so that I
don’t have wait until I
return to campus to
know if I passed last
semester’s courses.
Unclear Value
Can’t Negotiate
Valuable
16. User Stories Habits
1. Story format also used by
non-development teams
2. Start high level with
valuable why’s
3. Improve story title and add
details over time
17. Design Analysis
Design vs.
Documentation
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
20. Before
Sprint
During
Sprint
End of
Sprint
DESIGN
Think & Make
“How” Decisions
Test and Adjust
Decisions
DOCUMENTATION
Document Final
Decisions
• Acceptance
Criteria
• Prototypes
• Process Flows
• Graphics
& UI Layout
• Test Cases
• Code
• Rough
Documentation
• Valuable
Documentation
21. Design & Analysis Habits
1. Collaborative Design
2. Prototyping
• Feature-level: Demonstrate value to
business
• Story-level: Communicate
requirements to team
3. Documentation delivered with code to
avoid documentation debt
24. Daily Standup Habits
1. Meeting occurs everyday, on-time, no
matter who shows up.
2. Everyone is prepared. Everyone talks.
3. No discussion of “how”.
4. Issues are assigned and resolved quickly.
25. Retrospectives
Airing of
Grievances
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
26. START STOP CONTINUE
Facili-tator
Embrace
Conflict
2-3
Goals
GOOD
BETTER
“Builds trust within team”
27. Retrospectives Habits
1. Not allowed -> management,
customers, product owners
2. Safe environment where
everyone can speak their mind
3. Identify and track actionable
improvements
28. Sprint Planning
Making a
Commitment
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
29. Sprint Planning
Story: Electronic Notification of Grades
Task Name Assigned
To
Estimate
(hrs)
Design Mary 4
Test Cases Jason 2
User Interface Mary 8
Backend Logic Samantha 16
SQL Jason 8
Unit Tests Samantha 4
Testing & Bugs 12
Documentation 4
Capacity
3 Team Members
6 Hours / day
10 days
180 hours (total)
Total Task Estimate: 58
Sprint Capacity
>=
Total Task Estimate
30. Sprint Planning Habits
1. Estimate ALL known tasks in hours.
2. Estimate known-unknowns
(i.e. bug fixing)
3. Leave buffer for unknown-unknowns
(i.e. production issues, external
meetings)
31. Sprint Testing
QA vs Testing
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
32. Testing is a mentality. It is the
RESPONSIBILITY
of the entire team.
QA Professionals improve
the quality of a team’s
ability to test.
33.
34. Sprint Testing Habits
1. Test and fix bugs in the
sprint
2. Define test cases before
writing code
3. The entire team tests
36. A FLAWLESS Sprint
Review is the best way to
establish TRUST between
a team and its business.
Polished, prepared demo for each
committed story.
All Acceptance Criteria are demoed.
37. Top 10 Ways to Destroy Trust at a
Sprint Review
10) Demo starts
late
9) Team not
prepared
8) Code samples
7) Pace is too fast
6) Spelling Errors
5) Poorly Worded
Dialogs Messages
4) Technical
jargon
3) Resistance to
new ideas
2) Missed
Acceptance
Criteria
1) Bugs
38. Sprint Reviews Habits
1. Occur at the same time, on the same day.
2. Visibly record feedback and new ideas.
3. Entire team is present and given the
chance to present.
4. Measure percentage of stories accepted.
39. Automated
Tests and
Deployments
Fast Feedback
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
41. Automated Builds and Deploys
DEV PC 1
DEPLOY
SERVER
4) Build App
Benefits
1) Repeatable & Fast
2) Reduces Risk
3) Reduces team
friction
SOURCE-CODE
SERVER
BUILD
SERVER
1) Check
-ins
3) Run
Auto-Tests
DEV PC 2 DEV PC 3
5) Deploy
App TARGET
SERVER
2) Get Fresh Code
42. Automated Tests and Deploys Habits
1. Disciplined writing of unit tests for
each story.
2. Fast feedback from Automated
Unit Tests upon code check-in.
3. Automated Deployments occur at
least daily so that testing occurs
daily.
43. Lean & Kanban
Continuous
Delivery of
Value
Disciplined
Iterations
Communication
& Transparency
Continuous
Delivery
Automation
Lean &
Kanban
Tests Deploys
Planning Testing Reviews
Retro-spectives
Daily
Standups
Design &
Analysis
User
Stories
44. Lean Principle:
Code that is not in
production is waste!
Deploy code to production regularly.
Not all production code must be
executed by all users.
48. Q&A
Mastering Agile Practices
to Build High Performing Teams
Steven.Granese@tribridge.com
Steven Granese
Agile Coach & Consultant
Custom Software Development
www.sgranese.com
@sgranese
Editor's Notes
https://www.youtube.com/watch?v=SMCsXl9SGgY
What does the Karate Kid teach us about building high performing teams?
- Establishing trust
https://www.youtube.com/watch?v=SMCsXl9SGgY
“First make sacred pact. I promise - teach karate. That my part. You promise learn. I say, you do. No questions. That you’re part.”
Reality about Agile. It requires:
Habits – this is what the ceremonies are all about
Commitment – complete and deliver what you promise
Discipline – stick with it when it gets hard (ex: no bugs within sprint, no pushing stories to next sprint)
Trust – This is developed slowly over time as commitments are met. Both trust within the team and trust from the business.
Team Formation Model
Forming
Getting to know each other, little trust, formal and rule based
Signal ->Individuals sit by themselves and work alone, tasks assigned to one person
Storming
Power struggles, lack of understanding, conflict
Signal -> Arguments / passive-aggressiveness, reduced communication, fights, “that’s not my bug!”
Erick Fleming: “Automation reduces friction on the team.”
Healthy conflict needs to be addressed, not squashed or hidden.
Norming
Shift from individual focus to team focus
Signal-> pairing / people sitting and working together, signs of shared responsibility (“can we assign that task to both of us?”, fixing each other’s bugs)
Self-organization- The purpose of self-organizing teams is not for management to lose control. The purpose is to unlock creativity!!
Performing
Complete focus on the team goal
Output comes faster. Becomes harder to stay ahead of team and provide them with work.
Ironically, this is when the habits are engrained and some of the formal disciplines can be dropped.
Not just for software teams
Storming- kids don’t trust:
If I throw the ball to you, you will throw it back
If I let you catch this ball, you’ll me get the next one
I started asking them to make small commitments (“pinky swear”)
Keeps coming back to trust and commitment
In last month’s meetup, Erick Fleming as asked the following question:
Q: How do we convince management to allow our development team to implement TDD?
A: “First you have to gain the trust of the business.”
If you want to be a software craftsman, you have to earn the trust of the business.
Too many technical people focus exclusively on obtaining technical skills. But that doesn’t build trust.
How do you build trust?
Start with good habits, like we will discuss tonight.
Make small commitments to yourself, your team, and your organization. And keep them.
Have the discipline to stick with your commitments when things get hard.
This picture is from Diana Larson’s keynote address from the Agile 2014 conference last month called “Best Job Ever”.
Teams start out with a lack of trust.
They build trust slowly by making and holding small commitments.
Inevitably there is conflict as the team attempts to switch from focus on individuals to focus on the group.
This is where habits and discipline become important.
Only when conflict has been addressed can a team reach its true creativity.
And finally become high performing.
Coder vs Developer vs Craftsman
There is no technical difference between developer and craftsman.
Learning more technical skills won’t make you a craftsman.
Pyramid Model
User Stories Pyramid
Measure – how many stories have a descriptive and powerful “why”?
INVEST
Independent
Negotiable
Valuable
Estimable
Sizeable/Small
Testable
Measure – how many stories have a descriptive and powerful “why”?
Design vs Documentation
Design
Acceptance Criteria
Test Cases
Prototypes
Process Flows
Graphic Design
Design
Acceptance Criteria
Test Cases
Prototypes
Process Flows
Graphic Design
Before the Sprint – think about how to implement the story. Complete prototypes and acceptance criteria. Get sign off from Product Owner.
During the Sprint – test out the designs by writing code and getting feedback from Product Owner and customers. Begin documenting decisions that are made.
Before the end of the Sprint – soon after the sprint ends, update all relevant documents with changes made during the sprint.
Do no wait for multiple sprints to lapse, or for a major release, to update documentation. It will never happen!
Daily Standup
The Power of Habit by Charles Duhigg
Keystone habits are habits that are so transformative, that they naturally lead to other habits.
Should the team all stand for the standup meeting? Yes!
Definition of Done
Facilitator: Coach or ScrumMaster.
Scrummaster should not be PO, PM, or manager
Definition of Done
Identify all tasks needed to complete the sprint definition of “Done”.
Definition of Done
QA
Edge Cases
Test Cases
Automation
Developers tend to be optimistic.
Testers tend to be pessimistic.
Test your edge cases!
The team must test and deliver the acceptance criteria.
QA can help to identify edge cases and conditions that the acceptance criteria did not cover.
Definition of Done
QA
Edge Cases
Test Cases
Automation
Identify all tasks needed to complete the sprint definition of “Done”.
Erick Fleming – Automation “reduces team friction”
Fully automated
“If it hurts, do it more often.” Do not be scared of deploying to production.
The answer is not to document more or create better checklists. Deploy to production more often.
Code not deployed is “waste” – lean principal. It’s like inventory sitting in a warehouse.
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
You’re doing continuous delivery when: [1]
Your software is deployable throughout its lifecycle
Your team prioritizes keeping the software deployable over working on new features
Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
You can perform push-button deployments of any version of the software to any environment on demand
This is why stories must be valuable.
Pyramid Model
This picture is from Diana Larson’s keynote address from the Agile 2014 conference last month called “Best Job Ever”.
Teams start out with a lack of trust.
They build trust slowly by making and holding small commitments.
Inevitably there is conflict as the team attempts to switch from focus on individuals to focus on the group.
This is where habits and discipline become important.
Only when conflict has been addressed can a team reach its true creativity.
And finally become high performing.
QA
Edge Cases
Test Cases
Automation
Team must have mindset that everyone tests
QA Professionals can help lift quality of testing.
Bottlenecks
Not testing during sprint
Not fixing all bugs during sprint
Isolating testing to one person on team