Improving Ways of Working
Agile teams continuously seek to improve their working practice, improving quality of service and increasing rate of delivery. The most effective learning is local to the team. They inspect the work that has been done, looking for successes and for problems. They adapt to reinforce practice that leads to success and to remove practice the leads to problems.
Specific Practices
Blameless Post-Mortems are adopted as part Google’s Site Reliability Engineering framework. The concept has existed for sometime as part of traditional Service Operations. Its use within SRE shows its adoption in "DevOps” too. In this context, post-mortems are used to analyse the causes of operational failures and to decide how to improve the situation.
The team or wider organisation may readily identify that there are problems with its current way of working, that it wishes to improve its performance, or change its technology. Understanding the problem is inherently simpler than identifying a solution. Even if a potential solution is evident, we may be uncertain about its effectiveness. We experiment with changes to understand whether they will be effective and, if so, the extent of improvement we can realise.
We review the flow of work through our system, paying attention to the overall rate of flow and to bottlenecks as work flows through our process. Where bottlenecks are identified we seek to understand the root causes of each bottleneck. With this understanding we relieve the constraints by experimenting with changes to our process. Where we see examples of accelerated flow, we look for practices facilitating this acceleration. We experiment to find ways to incorporate these practices into our process.
The Sprint Retrospective is a Scrum event. Its purpose is to allow the team to inspect and adapt its way of working, the functioning of the team, the working context and all other factors which may impact the team’s ability to deliver its goals. Some factors the team have direct control over, other factors will require external influence to change.
Stop the Line is a practice in Kanban. Whenever a defect is detected downstream of the point where it should have been eliminated, the line is stopped. The team take time to identify and explore the reasons for the escape of the defect. They decide what action to take to prevent defects of the same type escaping in the future. Best practice also uses Stop the Line to identify and reinforce modified practice that brings performance benefits to the work of the team.