Inspect and Adapt

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