The need to inspect and adapt is the fundamental concept at the centre of the agile software development movement. It’s the beating heart of the system, without which clever technical practices like continuous integration, test-driven development, mob programming or dependency injection would amount to little more than cooler ways of building software that people don’t want.
I think most of us get that now; software should be built iteratively with meaningful feedback cycles. Whether most of us actually do the latter is, well, debatable. Nevertheless, the approach of building the exact software we thought we needed to build right at the start of an endeavour has become unusual.
The essence of this is an acceptance that we will always know more about what we are building and who we are building it for at any point in the future than we do right now. Given this realisation, making all our decisions about the build right now and committing to them for the duration, seems pretty negligent. The responsible reaction to this realisation include regular, frequent feedback mechanisms in our development process. This allows us to take stock of, and respond to, our improved understanding of the market, users or technology. To inspect and adapt.
We ensure products and services are built iteratively by creating an environment that forces this. We break features up into small end-to-end chunks, we applying continuous delivery principles and define “done done” to include having work in the hands of users. We ensure we respond to feedback by making our key metrics focus on usage, framing work as hypotheses and embedding user feedback mechanisms directly into our software. We shape our processes and practices so we no longer have to remember to inspect and adapt; it’s built in.
However, it often seems that the drive to inspect and adapt is only deliberately applied to what we build and not how we build. This means how a team works together, the technical practices they utilise and the processes they employ can go unimproved. This is a pity given the axiom that we will always know more in the future about how we work than we do right now. So, the chances are we could improve, if we had a meaningful feedback mechanism and the inclination to adapt.
Efforts to inspect and adapt over the how often amount to little more than a tacit agreement in the team to solve problems when they come up. I would argue in most cases this means that, despite best intentions, teams do not improve over time as much as they could. At best, teams that take this approach fix an array of real problems that come up in daily life with tactical fixes and workarounds. At worst, teams play whack-a-mole dealing with painful symptoms when the underlying root causes go unidentified and remain unresolved.
My instinctive remedy for this situation is to suggest that teams have a regular retrospective. Unfortunately, the stock of these meetings appears to be at an all time low in many organisations. A situation that speaks more to an inability to lead these collaborative session engagingly and constructively, than a lack of goodwill or time on the part of team. Effectively, most teams have learnt retrospectives are a waste of time by being in retrospectives that were a waste of time. Seems reasonable.
Although I am a massive advocate of the regular retrospective meeting and am keen to improve the facilitation of these sessions in order to make them more valuable, I am more moderate in my attitude to the universal application of retrospectives than I once was. I have come to the conclusion that the most important thing is the outcome, rather than the mechanism.
I want teams to deliberately inspect and adapt how they build software (technically and as a team) and would like teams to choose the mechanism that fits them best to achieve that. If that’s not a dedicated meeting, it could be a continually updated Start/Stop/Continue chart on a wall in the team’s area or an online collaboration tool or a dedicated Slack channel or an extra question at the daily stand-up. Teams should define and embed their mechanism of choice, so that they don’t have to remember to inspect and adapt how they work, as it’s built in to their approach to development.
Leading Agile Teams 
Another corker Chris! I absolutely agree that teams should apply “inspect and adapt” to the way they work. In addition to the reasons you described, I relate this to other sources of change. New tools and discoveries in the field of software engineering may have created better ways of working. The composition of the team may change over time; even if it doesn’t, each member has grown in skills and experience. And the nature of the work may change – sudden shifts are likely to be noticed, but more subtle trends can be missed unless group reflection happens regularly and effectively.
Thanks David, great point. Totally agree that gradual changes over time are unlikely to get addressed by an adhoc ‘we fix the problems we see’ approach. Making space and taking a step back to view from a wider perspective is much more likely allow teams to spot those changes and react.