Johanna Rothman Create Technical Excellence Chapter 9 Copyright © 2017

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

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

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

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

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

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

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

“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!

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

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”

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

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” https://leanpub.com/mobprogramming

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: http://mobprogramming.org/

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

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”

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.

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

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

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)

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)

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

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