We develop software primarily on teams, but how do you develop the teams? Construx's Mark Griffin and Earl Beede Inspect & Adapt the different ways you can organize your development team. They look at the pros and cons of different approaches and even offer some help for when you're stuck with a team organization that isn't the best.

How should you spend your always-limited testing resources? Is one part of the product more important to test than another? Construx's Steve Tockey and Earl Beede join host Mark Griffin in looking at one approach to answering those questions: risk-based testing. Steve and Earl look at how to do risk-based testing along with its pros and cons.

Why can't I know—with high precision—the final cost, scope, and time frame of my work effort? One of the biggest reasons you can't know all three at once is illustrated by Steve McConnell's Cone of Uncertainty. In this episode of Inspect & Adapt, Construx's Mark Griffin, Steve Tockey, and Earl Beede talk about what the Cone is, how it impacts your ability to estimate, and how you can use it to increase your estimate predictability. 

If hindsight is 20/20—and it's good practice to look back to find ways you could do better—then why do retrospectives seem like such a waste of time? Shouldn't they be a goldmine that we're excited about rather than just another obligatory meeting? Inspect & Adapt host Mark Griffin gathers fellow Construx staff, Steve Tockey, Jenny Stuart, and Earl Beede, to discuss how we can make retrospectives something to look forward to.

There is a lot of talk and ideas about how to scale agile up from the one-team, one-product base so that multiple teams can support a product (I am looking at you SAFe). But what about the case where one team must support multiple products? That is reverse agile scaling. Join Construx’s Mark Griffin, Jenny Stuart, and Earl Beede as they share strategies and proven techniques to have one team work with multiple products and multiple product owners.

What does "value" mean on your product? How do you know you are working on the most valuable thing?  Construx's Earl Beede, Jenny Stuart, and Mark Griffin discuss how to clearly identify and articulate value on development projects. Knowing the targeted value is critical for prioritization and scope control and for knowing when to stop. It is also the key ingredient to meaningful feedback cycles. But how do you reliably identify value? Earl & Jenny will share stories of how they've helped organizations identify their value in a measurable way.

How do you lead product development teams when a company that has always been hardware focused now owes its success to both hardware and software? Construx's Mark Griffin and Earl Beede recently spoke with Inogen's Norbert Leinfellner and Horst Pichler, who have decades of experience leading this transition. We kick off 2024 with an Inspect & Adapt episode on how successful leadership requires a certain system-level mindset to help blend those hardware and software teams.

Listen to Construx's Earl Beede, Jenny Stuart, and Mark Griffin as they assess the role and duties of project managers on software intensive projects. A special focus will be on groups using agile development processes. Earl and Jenny will share stories of what they have seen work and what hasn't with their clients.

Construx's Earl Beede, Jenny Stuart, and Mark Griffin investigate ways to split user stories so they fit in a sprint. Some methods are far preferable—and even easier—than others. Sometimes it just means setting yourself up to make your user stories split-able. Earl and Jenny will share their stories from the trenches and explain how they assist teams to apply the appropriate splitting practices in their environment.

What metrics make sense for a development team? How do you talk about productivity? Construx friend John Belbute joins Construx’s Steve Tockey, Earl Beede, and Mark Griffin to talk about engineering metrics. John has been a software leader at many companies, including Intuit, WebMD, eBay and Capita CCS and is now semi-retired with his own coaching and consulting company. John shares his in-the-trenches experience trying to find the perfect metric to show the rest of the leadership team how well the development teams are doing.

It's been over two decades since we were told that Waterfall development is bad and Agile development is good. Construx's Earl Beede recently did a webinar on the subject (available on YouTube). This Inspect and Adapt looks at some of the comments and questions that came up. Earl is joined by host Mark Griffin and Jenny Stuart as they take a fresh look at Waterfall vs. Agile.

There is a lot of confusion about where the job or role of product owner ends and that of product manager begins. Construx's Earl Beede recently did a webinar on the topic. Now Earl is joined by Construx's Jenny Stuart and Mark Griffin to take a deeper look into how the two roles differ and where they overlap. 

In an earlier webinar, Construx's Earl Beede took on many organizations that create product visions with phrases like, be the world's best ‘x’ or dazzle our customers. Not bad ideas but pretty much worthless in helping you make day-to-day decisions on what work is the most important for your business. This is a follow-up, with Earl and Mark Griffin delving a bit deeper into some of the questions that came up during the webinar.

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

You have engineering managers and you want to adopt agile - or are already doing agile -  development. Where does your engineering manager fit? What activities and roles do engineering managers play in the agile development organization? Join Construx's Jenny Stuart, Mark Griffin, and Earl Beede as they discuss how organizations can Inspect & Adapt the job of the engineering manager.

At the end of 2022, Construx surveyed our clients to hear their best disaster stories of 2022 and what areas they want to improve so they won't repeat their disasters in 2023.  Join host Mark Griffin with Construx experts Earl Beede and Steve Tockey as they Inspect and Adapt those disaster stories and improvement opportunities. 

Is there a "best" way or process to develop software? Is there one size fits all?  Construx has always said, "no". One of our 10x Principles is "Tailor the Solution to the Problem". Join host Mark Griffin with Construx's Earl Beede and Steve Tockey for an Inspect and Adapt of right-sizing software development process. We cover the process for figuring out what your process should be–the "meta process".

If you want to be notified of future live-stream recordings, be sure to sign up for our newsletter at our website: www.construx.com

Individual expert judgment estimation (a.k.a. best guess, gut, swag, etc.) is the most common method of estimating development projects. Yet it almost always is not a good estimate. Join host Mark Griffin with Construx's Earl Beede and Steve Tockey for an Inspect and Adapt of individual estimation. We cover the pitfalls of individual estimation but counter with specific ways you can make individual estimation a bit better.

If you want to be notified of future live-stream recordings, be sure to sign up for our newsletter at our website: www.construx.com

Backlog Refinement is a practice that most agile teams should do - but many don't.  Join host Mark Griffin with Construx's Jenny Stuart and Earl Beede to Inspect & Adapt  backlog refinement. We cover how backlog refinement has become a critical part of agile teams, how it should work, common mistakes in backlog refinement, and how it adapts to different situations.

This episode is edited from a live-stream discussion. If you want to be notified of future live-stream recording, be sure to sign up at our website https://www.construx.com

"How much testing is enough?" is a question Construx gets asked a lot. Join host Mark Griffin with Construx's Brian Daugherty and Steve Tockey for an Inspect and Adapt of the enough testing question. We cover the drivers of testing, strategies to help determine "enough," and the common mistakes organizations make when developing and executing tests.

If you want to be notified of future live-stream recordings, be sure to sign up for our newsletter at our website: www.construx.com 

What does it mean to bring your full self as a woman to leadership in a software or technical organization? Join Construx's Mark Griffin as he interviews Jessica Garcia about how to deal with the challenges of leadership specifically as experienced by women. Jessica leads and coaches women toward both leadership and authenticity. She will go over her six week leadership seminar and share key practices for women in technical leadership.

Many, if not most, agile teams include the practice of a daily gathering. It goes by slightly different names: the daily standup, the daily scrum, or walking the board.  Join host Mark Griffin with Construx's Jenny Stuart and Earl Beede for an inspect and adapt of the daily. We cover the daily's origins, how it differs across agile approaches, common errors in the daily (we are looking at you, status reporting) and how to adjust it to different environments.

This is an edited from a live-stream discussion. If you want to be notified of future live-stream recording, be sure to sign up at our website https://www.construx.com

Hearing about different scaling frameworks and wondering which one is for you? Join host Mark Griffin and guest Jenny Stuart for an overview of the popular Agile scaling frameworks SAFe, Nexus, and LeSS, including their strengths and relative weaknesses. We’ll cover the frameworks’ core techniques and approaches; this will provide you with a basis for determining whether one of these frameworks is a good fit. Jenny will also provide six scaling recommendations for you to think about regardless of the framework you might be considering.

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.

Construx welcomes Onorio Catenacci to the microphone to ask questions about software development that continue to puzzle him and perhaps to see whether Construx has the answers. Join Contrux's Mark Griffin and Steve Tockey to see if they can give sound, helpful, and actionable answers to Onorio's questions—and find out whether Onorio can stump Construx!

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

Join Construx VP of Consulting Jenny Stuart and Mark Griffin for the first in a series of episodes describing the power of Kanban. In this episode, they'll cover the most common misconceptions about this extremely useful method: #1 Kanban is only a board, #2 Kanban is good only for support, #3 Kanban is good only for small teams, #4 Kanban can't support long-range planning, and #5 Kanban or Scrum is an "either-or" decision.

Some organizations still aren't using Kanban because of these misconceptions, but many would be well served by some use of Kanban!

Construx's Jenny Stuart is retiring from the software industry, and we will miss her! In this podcast, Jenny Stuart looks back on her three decades in the software industry and shares stories and wins from her long career. Joining Jenny are three of her Construx work companions for the last 20 years, Mark Griffin, Steve Tockey, and Earl Beede.

Sixth in our series in which Steve McConnell describes the 28 key principles in his new book, More Effective Agile (Construx Press, 2019). The principles described this time:

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

Join Construx Senior Fellow Erik Simmons and Mark Griffin as they discuss the ins and outs of metrics for software teams. To kick off, they draw a distinction that can help alleviate overarching concerns about metrics and measurement in general: operational measurement (How are we doing? Metaphor: dashboard) and aspirational measurement (What’s our progress toward our goals? Metaphor: map). The remainder of the episode addresses realities within the dashboard context.

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. 

Join Construx Senior Fellow Earl Beede and Mark Griffin as they discuss methods for improving the chances of success by driving down inherent uncertainty (common-cause variation) for large software efforts.

These methods involve early decision making related to primary consumers, possible technologies, and broad software estimation. The conversation continues with a description of the Cone of Uncertainty, how to record your early decisions and their varying scopes and importance, and the helpful technique of priming the product backlog.

Join Construx Senior Fellow Erik Simmons and Mark Griffin as they discuss the ins and outs of Construx's organizational assessments, which go beyond software engineering technical practices to also examine organizational structure, the architecture of the system, the way people communicate, and the degree of interteam trust. Culture can play as important a role as technical practices, so Construx's assessments also assess the effect of an organization's culture on autonomy, mastery, and purpose, which are required for motivating teams. Check out our "More Effective Agile, Part 2" episode to hear Steve McConnell describe how to motivate teams through autonomy, mastery, and purpose.

Erik and Mark then discuss the numerous and varied reasons Construx's clients request organizational assessments. Next, they dive into the process of assessments: planning, information gathering, analysis, and reporting. The episode ends with a focus on results: multiple examples of the findings and recommendations this service has provided Construx clients.

Construx Software recently surveyed software professionals to determine the effect that working from home (WFH) during the coronavirus pandemic is having on software development. Our survey explored changes in communication and the impact on individuals, on teamwork, on leaders’ ability to lead, and on specific technical practices. The survey was conducted from April 7 to April 22, 2020, with 624 respondents participating from 63 countries.

The context was sobering, with most respondents reporting that they felt more disruption from personal stress related to coronavirus than they did from any aspect of changes related to working from home. The responses to WFH were more surprising. Respondents detailed dozens of creative adaptations that are allowing them to WFH effectively. Some of the adaptations are specific to this time. Others offer lessons that will help companies improve their operations long into the future—with benefits that more than offset the challenges.

Future speculation aside, respondents also described a new world now. They described people being kind and supporting, and they described unexpected staff members rising to the occasion. Many described participating in virtual coffee meetings, happy hours, and team chats to stay connected. One respondent wrote that, “The whole world has become a friendlier, more caring place.” Another wrote, “There is a lot more humanity than we thought.”

Our survey was focused specifically on software professionals. However, we believe most of the findings are broadly applicable to all companies with staff and leaders who WFH.

Download the full report today.

Fifth 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:

"Manage Technical Debt." A consistent focus on quality is part of an effective Agile implementation. Managing technical debt supports higher team morale, faster progress, and higher quality products. (See page 131 in the book.)

"Support Large Agile Projects Through Architecture." Good architecture can support portioned work on a project and minimize large-project overhead. Great architecture can make a large project feel like a smaller one. (See page 144.)

"Automate Repetitive Activities." No one likes repetitive activities, and many of the activities that can be automated in software development provide more benefit when they’re automated than when they aren’t. (See page 208.) 

Fourth 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:

"Keep Projects Small." Small projects are easier and more often successful. Not all work can be structured into small projects, but the work that can be structured that way should be. (See page 120 in the book.)

"Keep Sprints Short." Short sprints support a frequent Inspect and Adapt feedback loop. They expose problems quickly, making it easy to nip small problems in the bud before they become large problems. (See page 123.)

"Deliver in Vertical Slices." Feedback is important in Agile. Teams get better feedback on their technology and design choices—both from customers and the business—when they deliver in vertical slices rather than horizontal slices. (See page 128.) 

Is your team fairly new to Scrum? Construx Senior Fellow Earl Beede and Mark Griffin discuss specific strategies and concepts that will help your first Scrum efforts be successful.

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? 

Third 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:

"Tighten Feedback Loops." Don’t take any longer to learn lessons than you need to; keep the feedback loops as tight as possible. This supports more rapid progress from the "Inspect and Adapt" key principle and faster improvements in effectiveness from the "Develop a Growth Mindset" key principle. (See page 89 in the book.)

"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 

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 

Why do software gurus keep talking about the Cynefin Framework? What is it? How is it even pronounced? In this episode of Inspect & Adapt, Construx puts many brains on the topic with Mark Griffin, Jenny Stuart, Steve Tockey, and Earl Beede making the link between Cynefin and doing actual software development work. They cover where Cynefin is best applied and where this sense-making system just doesn't make sense.

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)