As architects become more senior, we are expected to contribute to growing the product, the organization, and the people. I gave a talk at the OOP Conference for Software Architecture in February 2021 that explores three roles of an architect that help them meet these expectations: architect as leader, as mentor, as coach. This session offered practical tools, methods, and frameworks that help both experienced and aspiring architects succeed in each of these roles. The slides are available here.
The Cynefin sensemaking framework (created by Dave Snowden of Cognitive Edge) has grown in popularity in the agile community in recent years. Used to its full potential, sensemaking and the Cynefin framework are powerful and effective approaches to informing action in complex, dynamic, and uncertain situations. Tony Quinlan and I led a workshop session at the XP2020 conference where we introduced a practical, effective approach based on our work applying complexity techniques in large global technology organisations.
The slides from our workshop are available here. This workshop is based on years of experience with dozens of sensemaking projects. We covered the fundamentals of using micronarrative-based sensemaking and the Cynefin framework to foster transformation, resilience, and agility. This session focused on use of sensemkaing to support transformations. We covered sensemaking in organizaitons, the Cynefin framework, how to determine appropriate action in a given context, how to design experiments for navigating complex situations, how to tailor a sensemaking framework for a particular purpose, and how to integrate sensemaking into your organizaiton.
Software product development organizations operate in an environment of ever-increasing volatility, uncertainty, complexity, and ambiguity. The pace of change is accelerating, business and technology complexity is growing, and organizations are struggling to keep pace. The software development industry has a $300 billion productivity problem, according to one study. Value is not flowing as it should. Flow-based software development is part of the continued evolution of contemporary software development approaches contributing to addressing this problem. It builds on agile and lean software development approaches and incorporates lessons from Deming’s management method, the Toyota Production System, Lean Product Development, Theory of Constraints, Operations Management, and other influences. Flow-based development is foundational to modern systems approaches, including DevOps, Continuous Delivery, Site Reliability Engineering, and more. Creating and sustaining flow in organizations is a challenging problem. Drawing on insights developed over many years working with multiple global product development organizations, this session presents a framework for establishing, understanding, and sustaining flow in organizations.
I presented this session at the XP2020 conference. The slides are available here.
This session addressed the following questions:
- What is flow?
- What is the relationship between flow, lean, and agile?
- Why do organizations adopt flow?
- Where to get started?
- What contributes to flow happening?
- How do we measure flow?
- What makes flow difficult to achieve?
- How can organizations overcome these impediments to flow?
- What is the role of culture in determining how effective flow can be?
For my PhD research I studied several large software product development organizations to get a better understanding flow and impediments. Flow-based development is a rich and growing field with many concepts; the specific focus for this study is impediments to flow. This study takes the perspective that organizations are complex adaptive systems. This research uses sensemaking to get a richer, more-informed understanding of flow, impediments, and the context and culture of the organizations that are experiencing impediments to flow. The organizations that are part of this study are all large software product development organizations. The focus of this study, then, narrows to managing impediments to flow in large software product development organizations, using a sensemaking and complexity perspective.
More details, including a link to my thesis, can be found here.
This is the abstract and summary of lessons learned from an experience report I wrote and presented at the Agile 2015 conference in Washington DC. The full paper is available here. Among other things, the paper talks about using A3 problem solving, Cynefin, and the Containers, Differences, Exchanges model from Human Systems Dynamics in the context of portfolio management in large organizations.
Working in a multi-team, multi-program, multi-product environment brings several challenges. One of those is providing a smooth flow of work to teams, and incorporating their feedback, while staying responsive to the needs of the business in a changing environment. Managing the portfolio backlog is a critical piece of the solution. This Experience Report documents several years’ experience working in such environments. The focus of this Experience Report is specifically on managing the portfolio backlog, not the full scope of what could be considered under a portfolio management strategy and implementation. We have found that getting the portfolio backlog management strategy right is a key element in the success of the overall portfolio management approach.
Summary of Lessons Learned
This section summarizes some of the key lessons learned in managing portfolio backlogs. Some general lessons related to solving problems in organizations include:
- Understanding the nature of the problem helps us to take appropriate action to solve the problem. The Cynefin framework helps with this.
- Make sure you are solving actual problems and causes, not just symptoms. A3 problem solving helps with this.
- Understand how to create a balance between agility, self-organization and coherence. HSD and the CDE model helps with this.
- Focus on the end-to-end flow of value through your organization, and on actively removing anything that impedes the flow of work. Lean thinking helps with this.
- Understand what success and failure could look like before running your experiments. This will help you pay beselective about the patterns you pay attention to.
Some specific lessons related to managing portfolio backlogs in large organizations include:
- Define the focus of your portfolio. In general, it is good practice to base the portfolio structure on your product line rather than organization structure. The former is what your customers care about; the latter more temporal.
- Understand what content goes on the portfolio backlog. Define different types of items, e.g., features, initiatives, architecture items, etc.
- Focus on the flow of work from portfolio to teams. The portfolio backlog management approach is an enabler of flow. Define policies for centralized portfolio-level decisions and localized program- and team-level decisions.
- Set up a portfolio backlog management meeting at a regular cadence with the right participants. Create a Definition of Ready for portfolio items. Focus the meeting on feedback from the development teams, and on moving portfolio backlog items to a ‘ready’ state. Do not let it become a status or strategy planning meeting.
- Create conditions that encourage a strong relationship between product managers, engineering leaders and architects. Together they bring multiple important perspectives to creating the portfolio backlog items. Consider also adding user experience design leaders to this mix, depending on the nature of your products.
Finally, this is a process of continuous experimentation and improvement. While some things can ultimately be moved to the obvious domain of best practices, or the complicated domain of good practices, we still operate within an ever-changing and complex environment that requires continuous awareness, experimentation, learning and adaptation. We continue to experiment and make improvements.
This is the abstract from a short paper I write for the Managing Technical Debt workshop at the International Conference on Software Engineering (ICSE 2013) in San Francisco. A preprint of the paper is available here.
Understanding the impact of technical debt is critical to understanding a team’s velocity. For organizations with multiple teams and products, the impact of technical debt combines non-linearly to impact the organization’s velocity. We can think of the capacity of a team as a portfolio. Not all of that capacity can be invested in new features or defect fixing, without incurring negative consequences. A portion of the team’s capacity needs to be invested in the ongoing management and reduction of technical debt. This paper describes a simple technique for visualizing, quantifying and tracking a team’s technical debt as a portion of their overall capacity investment. The knowledge and insights gained through this technique help with better capacity planning, improved forecasting, and helps to justify the business case for investing in managing and reducing technical debt.
This paper described a technique for considering the capacity of your team as an investment portfolio. Investing in technical debt management and reduction needs to be a part of a healthy portfolio. If neglected, a team’s Technical debt will mount over time and impact their feature velocity. Consider the different ways a team could invest its time as Real Options. Make investments in debt reduction explicit and visible, and track actual investments at regular periods. Taken to an organization level, the organization needs to be ware of the amount of technical debt it has, and the overall strategy for investing in managing and reducing that debt.