1. Johanna Rothman Create Technical Excellence Chapter 9
Copyright © 2017

2. How much quality does your product need?
“Create technical excellence...” How? Discuss the stories with the Product Owner so you know what is needed. Review the code and tests already available to see what might need to change. Create tests at a variety of levels to keep the code clean as you proceed! You “need to think about what you will do and how you might do it, and then keep the workspace clean as you proceed.”

3. For software products Spend the time discussing what should be done
(defining and refining requirements – the 3 C’s)
Read the existing code and tests … spend more time doing this than you would spend writing new code.
To go fast optimize:
for reading the code and tests (“requires refactoring”)
for early delivery to see how you are doing (requires small stories and continuous integration)
for creating technical excellence as you proceed… testing at a variety of levels as you proceed

4. Geoffrey Moore’s Technology Adoption Life Cycle
What Customers Want
enthusiasts
Time to release
Low defects
More features
visionaries
pragmatists
conservatives
skeptics

5. Geoffrey Moore’s Technology Adoption Life Cycle
What Customers Want
enthusiasts
Time to release
Low defects
More features
visionaries
pragmatists
conservatives
skeptics

6. Geoffrey Moore’s Technology Adoption Life Cycle
What Customers Want
enthusiasts
Time to release
Low defects
More features
visionaries
pragmatists
conservatives
skeptics

7. Geoffrey Moore’s Technology Adoption Life Cycle
What Customers Want
enthusiasts
Time to release
Low defects
More features
visionaries
pragmatists
conservatives
skeptics

8. Geoffrey Moore’s Technology Adoption Life Cycle
What Customers Want
enthusiasts
Time to release
Low defects
More features
visionaries
pragmatists
conservatives
skeptics

9. “Zeroth of Software Quality”
“If you don’t care about quality, you can make any other requirement”, including the schedule”
Project speed is a function of:
the code and tests that already exist
the clarity of what we want to do next
the complexity of what we need to do
The team (each member) has options to create a high-quality product!

10. Creating a high quality product
The ideal… a continuous flow of running tested features!
The team needs to be able to:
Integrate often to see progress
Keep the code and tests clean
Work together to maintain throughput and focus
Test at all levels so the team has support for frequent change

11. Integrate as Often as Possible
Continuous integration
… work on small code chunks of value, check-in the code, make a build, check the build, and if nothing “breaks” you are done with that chunk
…do this “at least twice a day”
Why?
You can see what you have “done” & what is still “in progress”
You can see if you “broke the build”
Automated “smoke tests” can check that the product’s performance or reliability still is OK
Other people can use what is “done”
You learn “fast”

12. Refactor every time you touch existing code or tests
Keep the code and tests clean! “Refactoring is simplification” The goal is to maximize the ease of understanding the design! Work as a whole team to create the Product Again… the need for the ability for team members to work together Teams need members to collaborate… for members to feel “safe” and to trust each other. Success is not about “me”, but about “us”.

13. Collaborating with pairing, swarming, or mobbing
Pairing … and xP’s paired programming
Two sets of “eyes” … double checking
The opposite of the rush, the expedient approach… quick and “dirty” result
Swarming …
When each person is done with “their” part, they assist whomever is still working
Mobbing … “The entire team works together on one keyboard”

14. Collaborating with pairing, swarming, or mobbing
Why?
Limits the amount of WIP with the focus on getting work done.
The team learns together.
The collaboration reinforces teamwork…
Multiple “eyes” assess small chunks of work with the benefits you get from continuous review (not one time, one person review)
Check Rothman’s discussion of Pairing Creates…, Swarm on the Work… and Mob on the Work
link:

15. Test at all levels so Change is Easy
Automate the following
Unit testing for the code so that refactoring is easy
Automated and exploratory testing (acceptance testing) to know if the story’s “done” criteria have been satisfied
Feature testing to know that the feature looks and feels as if there is a coherent view
Smoke testing for a build to know if the build is any good
System testing from the GUI, possibly with some automation, so we know the first interaction the user has actually works
Exploratory testing at the system level to find interactions and potential problems we didn’t or couldn’t find with automation

16. Test at all levels so that Change is Easier
Automate as you proceed
“Aside from build and smoke test automation, consider asking testers to automate all the testing they do.”
Use testing to drive Product Development
Test Driven Development (TDD)
Implement the test for each requirement before it has been designed and implemented… the test fails (red)
Then design and develop the code needed for the test to pass (green)
Behavior Driven Development (BDD)
For each user “behavior” (interaction), test for the required result
Acceptance test-driven development (ATDD)
“Helps in creating tests by thinking of acceptance tests for the product”

17. Beware of Technical Debt and Cruft
“We did the bare minimum… we had code for the bare minimum”
You didn’t plan for unfinished work
Rothman: “Technical Debt is Not Unfinished Work”
This is not the standard SCRUM definition
Cruft
Trash, debris, or other unwanted matter that accumulates over time.

18. Work at a Sustainable Pace
Optimize for reading code
When people read code, they think.
When people discuss what to do in the form of a small story and how to do it in the form of design, they are also thinking.
Sometimes, they think collaboratively with others when they define stories or acceptance criteria (the 3’Cs)
“Software development – is about the thinking ability of team members developing the product.”
“When managers or Product Owners pressure a team to deliver instead of think, the team creates defects.”
… see it when shortcuts are taken
… artificial (not realistic!) deadlines don’t help
“I have seen many teams improve their throughput when they stopped working overtime.” Rothman

19. Resources to “create technical excellence and learning”
The Pragmatic Programmer Clean Code: A Handbook of Agile Software Craftsmanship Practices of an Agile Developer Working Effectively with Legacy Code Agile Testing: A Practical Guide for Testers and Agile Teams More Agile Testing: Learning Journeys for the Whole Team Test Driven Development Beyond Legacy Code … and more

20. Recognize Excellence Traps
Trap: We can go faster without Clean Code and Tests
“You can go faster when you avoid technical excellence”
Trap: Waiting for Other People or Teams to Test
“… waiting for another team to test its work… increases the cycle time and creates WIP” … not a Lean practice!
Trap: Defects Prevent the Team’s Progress
It the code and tests are not “clean”, the code and tests can become so complex that it’s impossible to make progress.
(Why refactoring is so important)

21. Example
“… one team started to chart several practices when they started their Agile adoption. The team experimented with these practices, under the assumption that if they practiced these ideas, they would have fewer defects and a lower Fault Feedback Ratio.” FFR = (Fixes that require more work) / (All the fixes)

22. Initial Agile Practice Chart
INITIALLY the team charted several practices… with practice they expected to get fewer defects and lower their fault feedback ratio

23. Agile Chart Three Months Later
AFTER The team worked on it’s technical practices …