Inspect and Adapt

Today’s episode focuses on the very basis of Agile: its principles and values. Steve McConnell recently gave a keynote at XP2021 in which he said they need to be updated. You'll hear a quick recap of Agile’s beginnings, what was happening in software development when people got together at that Snowbird conference: primarily "code & fix" and the SW-CMM (Software-Capability Maturity Model). Steve will describe the current non-agile institutionalization of Agile. Then Steve and Mark will work one by one through the Agile values and principles to describe their relevance (or lack of relevance) to today's software development practices and culture.

Working with external software development partners often increases stress for the existing internal staff. A Construx client asked us to conduct research with our clients on approaches to reducing this stress. We identified six recommendations and related specific actions that organizations can take to decrease internal stress and improve overall teamwork with their partners.

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.

Construx VP of Consulting Jenny Stuart and Mark Griffin cleared up common misconceptions about Kanban in Episode #19. In Episode #24, they discussed numerous best practices for establishing and optimizing your Kanban system. Here, they focus on seeing the big picture—working with Kanban at higher levels of workflow. Topics included setting up program-level and portfolio-level Kanban boards. Jenny shares various approaches she's used with clients to determine work items, model the workflow, define exit criteria, and establish WIP limits at the program level, a much higher level of abstraction than user stories. Also discussed are Kanban in the context of SAFe and two-tier Kanban boards, which illustrate multiple levels of abstraction or types of work on one board: epics and features at one level and user stories or children stories underneath.

For the past year, Steve McConnell has applied his extensive estimation expertise to a timely problem: Covid-19 forecasting. Steve’s Covid Complete Data Center provides US national data, state data for every state, state scorecards, forecasts, forecast evaluations, and other data on the pandemic: https://stevemcconnell.com/covidcomplete/ His Covid Complete forecasting model has been accepted into the US Center for Disease Control’s “Ensemble” model, which means that it is one of the models driving overall CDC forecasting. In this episode, host Mark Griffin and Steve explore what Steve has learned from his modeling efforts and the lessons learned that are valuable for the software world. You’ll learn the importance of the following for software estimation: using historical data, keeping "control knobs" to a minimum, the difference between accuracy and precision, the difference between reported and actual ground truth, and the absolute necessity of closing the loop and judging your forecasts’ accuracy and effectiveness.

We thought we’d do something fun to start our second season and use a familiar vehicle to help new listeners and our old friends understand Construx’s software engineering expertise. And how are we going to do that? We’re going to use beer! You might be thinking, "Well, now you have my attention." Host Mark Griffin and Construx consultant Steve Tockey are accomplished home brewers, with 39 years of beer-brewing experience between them. In this first part of the conversation, they’ll work through the beginning phases of software development—requirements, design, and estimation—choosing beers that pair well with each phase, given the similar desired outcome of the particular beer and the software phase. Learn, for example, how software design is similar to an English IPA. We’re pretty sure you’ve never heard anything quite like this.

Construx VP of Consulting Jenny Stuart and Mark Griffin cleared up common misconceptions about Kanban in the first episode in this series (episode #19). This time they cover numerous best practices for establishing your initial Kanban system—determining work item types, workflow, work state policies, work-in-progress limits, and more—and running it well, including multiple approaches to handling blocked items and replenishing the queue of work. The conversation concludes with ways to optimize the system to make it better for the business and better for the people using it. Data-driven metrics such as cumulative flow diagrams, cycle time performance, and lead time performance are extremely useful here.

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.

It's a sad truth that many software teams are working with no explicit definition of success.

Join Construx Senior Fellow Erik Simmons and Mark Griffin to learn about the landing zone, a table that you can use to define success in a quantified, explicit way. Erik played a role in the development of the landing zone method during his time at Intel, so you're learning about it from one of its earliest proponents.

In addition to learning how to build landing zones and when to use them, you'll learn what makes a good success definition, the benefits of using landing zones (including creating accountability and transparency and enabling distributed decision making), tips for creating your first landing zones, who should be involved when creating them, how you can use landing zones with OKRs (Objectives and Key Results), and much more.

Learn more about Landing Zones from Erik's on-demand webinar: https://www.construx.com/webinar-value-stream-mapping-for-devops/

Steve McConnell completes the series in which he describes the 28 key principles in his new book, More Effective Agile (Construx Press, 2019). The final principles described are:

"Focus on Throughput, Not Activity." Similar to managing to outcomes, adding the nuance that busyness is not the objective—getting valuable work done is the objective. (See page 223 in the book.)

"Plan Based on Measured Team Capacity." Agile is an empirical approach; teams and organizations should plan their work based on their measured performance. (See page 232.)

"Decriminalize Mistakes." Decriminalize mistakes so that teams surface them without hesitation and you can learn from them. A mistake you don’t learn from penalizes your organization twice. (See page 227.)

Make sure to check out the first 8 parts in this series to learn all the principles.

Steve McConnell continues to describe the 28 key principles in his new book, More Effective Agile (Construx Press, 2019). The principles described this time:

"Express Clear Purpose with Commander’s Intent." Support your teams’ ability to make timely, local decisions by clearly communicating your objectives for the desired end state. (See page 220 in the book.)

"Model Key Agile Behaviors." Effective leaders model the behaviors they want to see in others. (See page 224.)

"Manage to Outcomes, Not Details." Support your team’s Autonomy by clearly communicating desired outcomes while leaving the team free to define the detailed means by which it completes its work. (See page 219.)

Steve McConnell continues to describe the 28 key principles in his new book, More Effective Agile (Construx Press, 2019). The principles described this time:

"Create and Use a Definition of Done." A good Definition of Done helps catch incomplete or faulty work early, minimizing the gap between defect insertion and detection. (See page 157 in the book.)

"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.)