You can find the webinar here: https://youtu.be/yVA-k6aWE0k

Join Construx Senior Fellow Earl Beede as he describes the results of this client-driven research. You'll learn the six recommendations and specific actions you can take to lower your internal staff’s stress. You'll also hear about some case studies that describe what worked and what didn’t work in the case of several specific external partnerships Construx studied.

This episode went a little longer than we expected—there’s so much information to share! If you’d like to absorb the episode in two sittings, a good stopping/restarting place is at 44:52, where the discussion of metrics begins.

"Maintain a Releasable Level of Quality." Maintaining a releasable level of quality helps catch additional defects that slip through an earlier DoD. (See page 160.)

"Use Automated Tests, Created by the Development Team." Automated tests help to minimize the defect detection gap. Making everyone on the team responsible for the tests reinforces the idea that quality is everyone’s responsibility. (See page 168.)

"Refine the Product Backlog." Backlog refinement ensures the team is working on the highest priority items, is not filling in gaps in requirements on its own, and is not starved for work. (See page 187 in the book.) 

"Create and Use a Definition of Ready." Part of backlog refinement is ensuring that requirements are truly ready before the team begins implementing them. (See page 188.)

"Minimize the Defect Detection Gap." The cost to fix a defect tends to grow the longer it stays in process. A benefit of Agile’s focus on continuous quality work is detecting more defects closer to the source. (See page 155.) 

The first unfortunate reality is that few organizations do any measurement. Culture plays a large role here, specifically a lack of trust. Erik describes how trust is created and the three principle factors in trust: ability, benevolence, and integrity. Without these, people cannot trust one another and measurement will fail. A second cultural issue is the restriction of measurement to the perception of effort and to resource utilization—none of the benefits of really good metrics and indicator programs can come from that. Even worse is the use of metrics for penalization. In fact, the irony of such misuse or lack of measurement within the larger context of Agile and Lean methodologies is that those methods are all about inspecting and adapting for continuous improvement, which require good, trustworthy, safe measurement.

Erik and Mark continue by defining the following specific elements of a measurement program: a measure, a metric, an indicator (sentinel indicator vs. rate-based indicator). They also discuss the importance of leading metrics/indicators vs. trailing ones.

The conversation continues with a description of how to envision, launch, and run an effective measurement program, including setting priorities, matching metrics to the nature of your work, and setting appropriate scales for your measurements (natural, scale, and proxy). Erik and Mark discuss techniques for ensuring that your measurement program is both valuable and cost-effective. Erik concludes by describing specific metrics-related work with Construx clients. 

Learn about the shift in mind-set from individual contributors to a true team dynamic in which throughput is far more important than being busy in parallel activities. You don’t need to be good at everything, but you need to be able to help out on anything, rather than focus only on your specialty. Helping others finish work in process—countering the common reality of having lots of things started but nothing finished—helps lowers various kinds of risk related to isolated/stuck team members, team members leaving, and new team members being onboarded. And team-driven design and decision-making is better.

Earl and Mark discuss the J-curve that describes a team’s performance and productivity in a situation of change, such as when it’s beginning to use Scrum. Business pressures aren’t put on pause, so what’s a good approach? First, you don’t need to go fully Scrum immediately. Also, you need 3­–5 cycles to learn a new process, so the sprint retrospective is crucial in this process.

The guys also discuss the persistent role of design in Agile, which can be a surprise for new Scrum teams. High-level decisions have to be made before a team kicks off, and low-level design continues during sprint planning. And the episode ends with a discussion of staffing Scrum roles. The Product Owner works the business, the Development Team works the product, and the Scrum Master works the process. Which of these are crucial if you can’t staff all of them? 

"Fix the System, Not the Individual." Most software professionals want to do good work. If they aren’t doing good work—and especially if it seems like they’re trying not to do good work—understand what dynamics are contributing to that. Look for the system problem that’s frustrating the person. (See page 98 in the book.) 

"Increase Team Capacity by Building Individual Capacity." Teams exhibit attributes that are a combination of the team members’ individual attributes and of their interactions. Strengthen your teams by strengthening the individuals on the teams. (See page 103 in the book.)

Check out the reviews for Steve's book here! More Effective Agile: A Roadmap for Software Leaders 

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)