Inspect and Adapt

Second in our series in which Steve McConnell describes the 28 key principles in his new book, More Effective Agile (Construx Press, 2019). The principles discussed this time: "Motivate Teams Through Autonomy, Mastery, and Purpose." Agile practices inherently support the factors that contribute to motivation. Teams are intended to work with Autonomy and to become better over time (Mastery). In order to do so, they need to understand their Purpose. The concepts of “healthy Agile team” and “motivated Agile team” are strongly intertwined. "Develop a Growth Mindset." Whether you look at it from the point of view of the “Mastery” part of Autonomy, Mastery, and Purpose or from the point of view of Inspect and Adapt, effective Agile teams maintain a steady focus on getting better. "Develop Business Focus." Developers frequently need to fill in gaps in requirements and in direction from their Product Owner. Understanding their business helps them fill those gaps in ways that are beneficial to the business.Check out the book's reviews here! More Effective Agile: A Roadmap for Software Leaders 

Teams succeeding with Agile approaches on smaller projects often encounter difficulties when attempting to scale those methods. In this episode, Construx Senior Fellow Earl Beede and Mark Griffin discuss specific strategies for successfully scaling Agile. First, they cover the importance of batch sizing. Overly large batches easily lead to waste, and many scaling issues can be solved by manipulating batch size. The next strategy—backfilling—addresses two challenges: The tendency for teams to focus on invention rather than on problems that need solving, and lack of clarity regarding product or feature direction. Backfilling also serves as a prompt for identifying the decision makers for the product. The final strategy relates to collaboration: How is collaboration ensured in scaled Agile environments (and even in single Scrum team instances)? The trick is to encourage collaboration on actual work—doing work together on some specific deliverable, not just sharing information. Otherwise, collaboration ends when work kicks in and information sharing is displaced.

We’re happy to continue the conversation between Steve McConnell and Jeff Atwood. Jeff is a software developer, author, and entrepreneur known for blogging at Coding Horror, co-founding the computer-programming question-and-answer website Stack Overflow, and, currently, developing Discourse, a powerful open-source discussion platform. Over the holidays we recorded Jeff and Steve discussing Steve’s new book, More Effective Agile, which Jeff had just read. Their discussion touches on numerous aspects of effective—and wise!—software development.

We’re happy to the share the first of two episodes featuring Jeff Atwood, a software developer, author, and entrepreneur known for many things: blogging at Coding Horror, co-founding the computer-programming question-and-answer website Stack Overflow, and, currently, developing Discourse, a powerful open-source discussion platform. Over the holidays we recorded Jeff and Steve McConnell discussing Steve’s new book, More Effective Agile, which Jeff had just read. Enjoy a conversation that touches on numerous aspects of effective—and wise!—software development. And check back for the second part of the conversation in a couple of weeks.

Construx Principal Consultant Steve Tockey and Mark Griffin discuss design patterns in a unique way by emphasizing the importance of understanding fundamental design principles when you’re using patterns.Of the top five reasons that software projects get into trouble, the most significant issue that is directly under the control of software developers is the complexity in the code base. Both industry data and Steve’s own engagement-derived data over 20 years of software consulting support this. As Steve McConnell has argued, the prime directive of the software professional is to manage complexity.Steve and Mark dive into specific kinds of code complexity—such as cyclomatic complexity, depth of decision nesting, fan out, and number of parameters—and describe the fundamental design principle related to complexity: minimize overall complexity by balancing local and global complexity. Without measuring complexity in your code base, you can’t actually effectively control it. By measuring it, you can achieve the balance of complexities that most significantly decreases your code’s overall complexity.Steve and Mark continue by listing the fundamental design principles Steve covers in his design patterns training so as to begin to address a key question: Why is understanding the fundamental design principles important if you’re using design patterns? The list of principles applies across a broader spectrum of software creation than the SOLID principles do. Steve’s list causes you to pay attention to software attributes that you wouldn’t pay attention to if you were using only the SOLID principles.Steve argues that you can’t deeply understand what a pattern is up to unless you understand why the pattern looks the way it does. Each software pattern is primarily driven by a fundamental design principle and can be influenced by other fundamental design principles. For example, the Strategy pattern is primarily driven by the encapsulation principle and is influenced by Liskov substitutability and cohesion and coupling. Understanding the connections between design patterns and design principles vastly deepens your understanding of the patterns and their applicability.The episode ends with a thorough discussion of another fundamental design principle: encapsulation, which is achieved only via Design by Contract. The difference between code syntax and code semantics enters the discussion to help explain how code contracts operate. You have to get beyond syntax to achieve higher quality code with fewer defects, which are semantic inconsistencies. Compilers are ruthless masters of syntax but can’t help with code semantics.Links to Steve Tockey’s books:How to Engineer Software: A Model-Based Approach (Wiley-IEEE Computer Society Press, 2019)Return on Software: Maximizing the Return on Your Software Investment (Addison-Wesley Professional, 2004) 

In the first of a series of episodes sharing crucial information from Steve McConnell's new book, More Effective Agile, Steve and Mark begin to describe the 28 key principles you need to understand to reap the full benefits of effective Agile. The principles discussed in this episode are"Inspect and Adapt." Agile is an empirical approach that depends on learning from experience. This requires creating opportunities to reflect periodically and make adjustments based on experience. "Start with Scrum." Scrum is not necessarily the final destination on an Agile journey, but it is the most-structured, best-supported place to start. "Build Cross-Functional Teams." Work on Agile projects occurs within self-managed teams. To be self-managed, teams must include the full set of skills needed to make well-informed decisions that are binding on the organization. "Integrate Testers into the Development Teams." Tighten the feedback loop between development and test by having the people doing the work work more closely together. Check out the stellar reviews of the book here! More Effective Agile: A Roadmap for Software Leaders (Construx Press, 2019) 

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.