63
Practice Excellence
Practice Excellence
remove or isolate the non-collaborator
Requires self discipline to improved quality
Relies on the team to practice technical excellence instead of imposing discipline
Practice Excellence
Foundational Development Disciplines
Coding Standards
Configuration Management
One Click Build
Continuous Integration
Unit Testing
Automated Testing
Nested Testing
No Partial Credit
Foundational Deployment Disciplines
Production-Hardy Code
Automated Release Packages
Automated Installation
Test Automation
Continuous Integration
Pair Programming
Test Driven Development
Legacy Code and Refactoring
Architecture Spikes
Getting Started
Agile Health Check
Problem
Errors Enter Here
Why inspect here?
Customer
Low Technical Debt is Highly Effective
Thanks – Scott Ambler
Cost/Delay Cycle
The Need for Automation
Find and fix defects the moment they
occur.
Don't Tolerate Defects
If you expect to find defects during final
verification, your development process is
defective.- Mary Poppendieck
continuousintegration
pair programming
test driven
development
Continuous Integration
Automating the
integration and
inspection of
software
continuously
Nested Testing – Fix Immediately
Every Moment ……….. Pair Programming
Auto Tools
Every Few Minutes ….. Unit Tests
Every Day …………….. Acceptance Tests
Every Build Submission Unit Tests
Every Week …………… System Tests
Every Iteration ………… Full Regression
Beta Tests
Pair Programming
Pair Programming
“Yes, I do mean two programmers
on the same computer.”
Can show up to 5% improvement in
development time
Research shows leads to 8-15% less
defects
Pair Programming Benefits
Keeps programmers focused
Helps when programmers get stuck
Avoids mistakes
Produces better code
Best way to learn a new code base
More fun
Test Driven Development
Test Driven Development (TDD)
“Programming practice in which all production code is written in response to a failing test.”
Test Driven Development
List User Stories
Write One Test
Run Test to
Make Sure It Fails
Add or modify just enough code to make new
test pass and all previous tests pass
Refactor to eliminate code
smells (e.g., duplicated code)
19
Test Driven Development
Write unit tests and acceptance tests before
code
Integrate tests and code into system as
often as possible
Stop the line when build breaks
Run larger tests overnight
Run comprehensive tests over the weekend
Test Driven Development
Three times improved productivity
… and fewer defects
Stop the Line Culture - Test before check-in
Andon Loom 1898
Automate Unit Testing
Written and run by developers
Check that my changes don’t break your code
10 Minute “Quicktest”
Don’t write more code w/o a Unit Test22
Test Driven Development
System does what it needs to do and no
more
Improves quality because the new code is
written to be testable
Produces better code: more decoupled,
with clearer, tighter interfaces. Bad designs
show up as hard to test!
Test Driven Development
Get immediate feedback on whether the
code works
Results in a suite of test cases that can
surface regressions
You’re not afraid to refactor
TDD References
http://www.pathfindersolns.com/archives/tag/test-
driven-development-for-embedded-c
Guidelines for Test Driven Development:
http://msdn.microsoft.com/en-
us/library/aa730844%28VS.80%29.aspx
Test Driven Development by
Example
- Kent Beck
Legacy Code and Refactoring
What is ‘legacy’ code?
Still meets customer need, AND:
You didn’t write it, and it’s poorly
documented
You did write it, but a long time ago (and it’s
poorly documented)
It lacks good tests (regardless of who wrote
it)
—Michael Feathers 2004
Exploration and Refactoring
Determine where you need to make changes
(change points)
Is the code around change points (a) tested?
(b) testable?
If tested, good to go
If not tested and testable use TDD cycles to
improve test coverage
If not tested and not testable, refactor
Make it a better place
Add tests to improve coverage as needed
Make changes, using tests as ground truth
Refactor further, to leave codebase better
than you found it
This is “embracing change” on long time
scales.
Refactoring
Keep code base simple
Avoid and remove code duplications
Refactoring
Simplicity
The goal of most patterns
Clarity
Common language
Encapsulation
Self-documenting code
Suitable for Use
Usability
Performance
Refactoring
No Repetition
NO REPETITION!
No Extra Features
No Code Before its Time
No Code After its Time
Isn’t Refactoring Rework?
No way!
Outcome of learning
Builds in the capacity
to change
Doesn’t cost, it pays
References
Working Effectively with Legacy
Code, Michael Feathers A ‘must read’ when working with legacy
code.
Fit for Developing Software,
Mugridge & Cunningham
Architecture Spikes
Some teams (some really good teams) start
their work with an architectural spike (aka
Iteration Zero)
During this iteration, they define
architectures, integration points, release
acceptance criteria, standards, joint
practices, et cetera
To quote Mary Poppins, “Well begun is half
done.”
Architecture Spikes
Sometimes needed during Sprint Planning
Architectural Options impact work plans
Make these decisions
During Planning
Just before implementation
At the Last Responsible Moment
4343
Standardized Work
Create a standard
Follow it
Find a better wayRepeat endlessly
Clarity
Collaboration
Consensus
Establish a best
practice
Document the
standard (make it visual if you can)
Train to the method
Creating Standards
If you believe that standards are
written in stone, you will fail.
You have to believe that standards
are there to be changed.
“ “Yoshio Shima, Director Toyoda Machine Works
Focus on Principles not Detail
Don’t overdo the detail
Get Stakeholder feedback each iteration
Review the process each iteration and
improve it
Process Standards must be continually
updated and changed
Where problems occur get to the root cause
Keep documentation simple
Practice Excellence Exercise?
Practice Occasionally <25% Often >25% <75% Pervasive > 75%
Congfiguration Mgt
Coding Standards
Fix All Compiler Errors
Continuous Integration
Pair Programming
Unit Testing
TDD
Refactoring
Automated Testing
Nested Testing
Architectural Spikes
Legacy Refactoring
Which of the following are used wherever they could be?
Practice Excellence
Your
Questions?
The secret of getting ahead is getting started.
- Mark Twain
Getting
Started
Agile Readiness
Agile Understanding
Agile Leadership
Planning
Tools and technology
Agile development process
Skills/experience
Agile Leadership
Product
Manager
Program Manager
Prod. Owner 2
Dev. Mgr. 2
Delivery Team 1
Delivery Team 2
Delivery Team n
Prod. Owner 1
Dev. Mgr. 1
Delivery Team n+1
Delivery Team n+2
Delivery Team n+m
Agile Leadership
Planning
Release Epics Prioritized
User Stories written
User stories prioritized based on Business
Value (H-M-L)
User Stories estimated in story points
Getting to Done3
An effective development environment
including Unit test automation
Continuous integration capability
Static code analysis tools for all of the code
Pre-check-in test capability for the
development teams
Fully automated test capability for all
aspects of delivery
Resources in place for continuous testing
Tools and Technology
Are tools in place for
Agile working in a distributed team?
Distributed planning and estimating?
Distributed information radiator?
Instant communications between buddies?
Anything else the team feels it needs
Getting Started Tips
Expect the teams to under-estimate in the
first few sprints
It will take about 5 sprints to develop a
cadence and velocity
Teams may take on too much after some
time
Watch out for anti-bodies
Make decisions together to avoid handoff
gaps
Dev Team decides how – nothing technical
in user stories
Cover all types of stakeholders
It’s all about learning
Pace yourselves
Don’t accumulate technical debt
Beware of chicken subversion
Agile HighlightsAgile Tips
Agile Health Check
How is the team doing?
Does your team decide what to work on in
each sprint?
Does your team deliver stable code with low
technical debt at the end of each sprint?
Does your team involve end-users in
evaluating the product you create?
Does your team complete their daily standup
meeting in 15 minutes or less?
How is the team doing?
Does your team involve product managers,
usability engineers, IT staff, or other external
resources in planning and working on each
iteration?
Does your team conduct retrospectives?
What practices for excellence is your team
using?
Logistics Tools and Tips KJM
Logistics Tips and Tools
Distributed Teams
Distributed Teams
Help sort out the communications
Video
Audio
Community space
Build aligned vision and goals
Focus especially on cultural differences
where teams are in different countries
Personal relationships across teams
Clear organization and structure -
understood by all
Clear responsibilities for each team
Inter-team
Project Management / Co-ordination =
"Scrum of Scrums"
Team to team technical interfaces
Overall status reporting
Distributed Teams
Common Tools
Development
Communications
Increase frequency of integration
Set up alert system: Push not pull
Distributed Teams
A Scrum Master at each site
Scrum of Scrums
PO is available for some time to each
team
Post (make visual) how and when the
PO is available
Co-locate entire team for one sprint
Project wide wiki
Distributed Teams Tips and Tools
Encourage informal communications
across members of distributed teams
Scrum of Scrum meeting rotates the
time zone meeting time
Create a “community of practice”
across geography teams to share
resources
Distributed Teams Tips and Tools
Dealing with multiple teams working on the same project
Multiple teams –same project
Multiple Teams Tips and Tools
Set a process for making decisions
Sync the sprints on the same timeframe
Scrum of Scrums with Development
Managers as well as Scrum Masters
Create a communications plan and process
Lean References
Can Distributed Software Development be
Agile?
http://www1bpt.bridgeport.edu/~dichter/cpe4
89/p41-ramesh.pdf
Distributed Scrum
http://jeffsutherland.com/SutherlandDistribut
edScrumHICCS2007.pdf
References
Getting Started
Your
Questions?
