Inspect and Adapt: Recent Episodes
Construx
World-class software development requires far more than language/platform expertise and steady sprints. Join us as we describe time-tested, industry-proven software best practices at the team, organization, and leadership levels, sharing examples from recent engagements with software teams of all sizes.
Construx is led by industry leader Steve McConnell, author of Code Complete and More Effective Agile. Software experts first and software trainers and consultants second, our team has seen what works and doesn’t work in hundreds of software organizations.
Host Mark Griffin spent the first half of his career as an electrical engineer doing silicon hardware design and leading software automation teams. He moved into the sales side of software because he wanted to spread the value of what his company was building. It was supposed to be a one-year assignment that turned into the second half of his career. His balance of deeply technical skills and right-brain artistry also makes him a masterful home brewer!
The product owner is often considered the most critical accountability in the triad of
What do we do when we are faced with "The New"? When something is new to us, it's harder to estimate, harder to plan, and harder to execute. Some development projects involve much more that is new than others. How do we identify the new and deal with it in a constructive way? In this episode of Inspect & Adapt, Construx's Mark Griffin, Steve Tockey, Earl Beede, and Jenny Stuart dive into ways to have the best development project when dealing with 'The New."
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 a product owner ends and a product manager begins. Construx's Earl Beede recently did a webinar on this. 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.
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 judgement 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 is frequently asked. Join host Mark Griffin with Construx's Brian Daugherty and Steve McConnell for an inspect and adapt of the enough testing question. We cover the drivers of testing, what 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 recording, be sure to sign up at our website https://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 on how to deal with the challenges of leadership specifically as it is experienced by women. Jessica leads and coaches women to both leaders and their authentic self. She will go over her six week leadership seminar and share key practices every female technical leader can use.
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.
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!
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
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 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.
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 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.