Inspect and Adapt

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.