Inspect and Adapt

Construx Senior Fellow Melvin Perez-Cedano and host Mark Griffin dive into developer testing in response to a recent engagement with a telecommunications client trying to improve quality and productivity.As developers, we know that we’re going to make mistakes. The point of developer testing is to discover those mistakes as early as possible so that we can remove them when it is far more economical to do so. Test-driven development (TDD) and behavior-driven development help here. Plus, writing test cases first helps us clarify our understanding of what we need to do before we write the code. But the overall point is to decrease the gap in time between defect insertion and defect removal. Even testing after you write a function helps you in this regard.The most common question in our developer testing engagements is this: How do we apply these techniques to the existing code that we have, to our legacy code that was not designed to be testable? Melvin describes how to change the future of this extremely valuable code. For example, minimize manual integration to minimize the risk of changes.Melvin continues by describing a concept during the engagement that the attendees at first struggled with: modified condition decision coverage (MCDC). The technique provides a level of test coverage that is required when you’re building safety-critical software that requires high reliability. (This was appropriate for this engagement because the company is involved with self-driving cars.) Typically, across the industry, when 80% of line coverage is achieved, the testing is considered good, but this definitely isn’t always sufficient. MCDC vastly improves your coverage by testing every condition independently.Our final topic today, which was of particular interest in this engagement, is how to test configurations with multiple factors: different network protocols, different operating systems, different databases, different UIs, etc. When you try to have complete coverage in this environment, the number of required test cases grows rapidly and the cost of testing increases similarly. Pairwise testing lets you provide wiser coverage when total coverage is likely impossible. The number of test cases is reduced significantly, but the crucial coverage is assured. To have strong confidence without investing half the project in testing, this method is invaluable.

Construx Senior Fellow John Clifford—our Agile Practices lead—joins host Mark Griffin to discuss a repeated theme of multiple recent engagements: how to get Agile teams unstuck.Many teams are struggling with “Scrum adoptions,” they think, but this characterization is inaccurate because the teams aren’t really running Scrum. Instead, they’re doing an approximation based on faulty assumptions—namely, that the teams can take a bit of this and a bit of that and make it work. But Agile frameworks are systems that are more than the sum of their parts. When you leave out parts of Scrum, you start having problems. Furthermore, organizations often do what works in the short term even if it’s not best for the organization in the long term. John describes multiple ways to help teams overcome the pain of change and fix their adoptions.The Agile and Lean approaches don’t solve your problems—they expose them. Once the problems are exposed, what will you do? This is the Agile Test. John describes healthy and unhealthy approaches to the Agile Test. Will you try a solution and, even if it fails, learn from that failure? Or will you stubbornly persist in your ways, not solving the problems, and therefore fail the test? John also describes leadership’s role in this moment of challenge. To pass the Agile Test, teams must inspect and adapt their processes and then start the inspect-and-adapt approach again.In the final segment of this episode, John and Mark discuss the failure mode of missing your sprint goal. The sprint goal is the measure that we evaluate ourselves by, but missing the sprint goal is common. John describes a solution that has worked in multiple engagements: helping teams learn how to properly size their backlog items. He shares simple rules of thumb to help ensure properly sized items. Stretching the length of your sprint to achieve your goals is not addressing the problem; it’s working around the problem. Varying team velocity across sprints is another sign of improperly sized items. In fact, irregularly sized items is a form of waste because it makes flow vary. Don’t make your sprints longer if you can’t accomplish your goal—commit to less, and make sure your items are properly sized.Bonus topic: delivery versus deployment. Our goal is to always deliver value, but there must be value to a customer before deployment. 

Construx Senior Fellow Melvin Perez-Cedano joins host Mark Griffin to discuss two recent engagements: a Lean-Agile Practices custom workshop with a team using proto-Kanban (a board without work-in-process limits) and a deep-dive Scrum class with experienced Scrum practitioners.In the first case, Melvin describes using a participatory decision-making technique to determine whether everyone on the team was in agreement about the team’s primary challenges. In this case, team members ranked the severity of the seven forms of waste (according to Lean) in their efforts, and Melvin and Mark review these forms of waste. Melvin then describes guiding the team to redesign their Kanban board so as to improve visibility (by adding missing steps and buffers) and to better manage work-in-process (by establishing WIP limits). To-Do, Doing, and Done columns don’t make a Kanban board! Melvin goes on to describe multiple ways to approach setting good WIP limits.Regarding the second engagement, Melvin describes many organizations’ desire to do longer-term planning—that is, to plan beyond the current sprint. For example, will a particular feature be available by a particular date? Melvin describes the shorter-scale release planning that is possible with Scrum, which involves forecasting based on team velocity and determining on an ongoing basis which features will provide the most value.