In my prior post, I provided a backdrop to the importance of empirical process control in software product development. I discussed that because software development is a complex, unpredictable, and uncertain process, we need tools that actually embrace the complexity in order to manage and control that process. Those tools are what Scrum calls its three pillars of Inspection, Adaptation, and Transparency. I like to think of each pillar as a complement (input) to the others and helps support the purpose of managing this complexity. Let’s take a look at each in a little more detail to see how they can help manage and control the software creation process.
Transparency
Transparency ensures that everything in the process of building software is readily accessible, visible, and observable. In order to manage a complex process, it’s best to make as much visible as possible. Why would this be? Visibility and transparency provide the opportunity to see what’s going on so that everyone has insight into what is being done, the decisions being made, and the progress forward. Sounds obvious, but you may be surprised how many times I have worked with teams who had a better appreciation for the work they were doing when they could easily see that work on a Scrum wall (for example) or actually follow through with retrospective action items because they were radiated in a team room. When we don’t have transparency we can easily end up working in silos performing independently (or worse, assuming someone else is doing the work). This leads to interpreting information such as requirements, business rules, and stories differently because each person has his or her own perspective. When teams make their process visible to everyone, team collaboration and coordination improve, expectations and assumptions are better understood, an overall understanding of the sprint goal is shared, and the opportunity to inspect the work performed is much more accessible. Which leads us to…
Inspection
Inspection is the activity of analyzing and evaluating what was made transparent in order to determine how well (or not) the particular practice is operating, running, and functioning. Because we are dealing in a complex environment, one that we should acknowledge is not easy to define and plan for upfront, we should be taking every opportunity to inspect what we are doing and how well we are doing it. Inspections should be occurring frequently in Scrum. Sprint reviews, retrospectives, and burn charts are good examples to name just a few. Metrics are another great tool teams can use to help validate (or not) the efficacy of the process or practice being inspected. Frequent inspection of these metrics helps inform and guide the team as to what they may want to continue and what they may want to stop. Ensuring frequent inspections exist and acting upon those inspections gives us the opportunity for…
Adaptation
Adaptation is the activity of taking the observations from inspection and adjusting and modifying the process and practices for the purpose of improving upon the software development process. Teams must have a mindset towards continuous improvement and be willing to adapt and make changes. For example, retrospective sessions can yield a lot of good ideas. But once the session is over, if teams simply go back to business as usual without being mindful of actively adjusting and adapting their activities, improvements will not occur. Adaptation is not just about team dynamics either. If our inspections tell us that what we are building is not what is expected, we have the opportunity to make the changes needed now rather than learning about it later.
Teams sometimes get hung up trying to implement a large change that will seemingly fix everything. But adaptation does not have to be a large endeavor. Small changes can also be very rewarding and easier to manage. And just because we adapt does not mean it has to be permanent. Adaptations should be looked at as experiments accompanied by acceptance criteria that help measure whether the experiment is working or not.
As an Agile coach, I like to make sure the teams I work with understand why they are doing these practices. When understanding Scrum is designed to embrace the complexities and uncertainties software product development brings, the three pillars should help any software team.