Agile is not one specific method, but includes a broad set of methods and techniques that subscribe to the values and principles of agile. Well known agile methods such as Extreme Programming (XP) and Scrum but are both focused on the product delivery side of things. The agile manifesto contains values, one of them is “to value individuals and interactions over processes and tools”. So should we consider process improvement as a part of the Agile focus?
Process improvement puts much emphasis on the process as the base for developing software. At first sight, agile and process improve might look incompatible, but that is certainly not the case. As the agile manifesto states, it is not that that they do not value the right statement, but they value the left more. So as long as processes help professionals to interact effectively and efficiently, they can certainly be agile.
Scrum / Lean / Agile are underpinned with the expectation that an empowered team will continuously look to improve their process. Regular retrospectives provide the opportunity to reflect and choose new actions to try in the upcoming sprint. That’s all very well… but to getting meaningful traction from this can create gaps. Agile should be very honest about the effort it takes to adapt a process (framework) to the realities of each situation. Even now though we do not truly understand how relentless we have to be to succeed at continuous improvement. Successful lean organisations are characterised by an obsession with delivering value to clients and a complete intolerance of waste.
A retrospective that starts with ‘what do we need to do next to improve the way we would and our Agile process’ gets the team into a proactive, creative mindset. Here is a four step approach to encouraging process / continuous improvement as part of the daily stand-up:
Step 1: – Get the team to explore what the scale that process / continuous improvement should be measured on. Is it the overall effectiveness of the team, value delivered to client, quality of work or some other metric? Discussing what it does not represent can also provide insights or to have a narrow focus.
Step 2: – Place the starting point (A) somewhere which fits where the team thinks it is at. Though a quick poll of the team may indicate to everyone the scale of the challenge ahead.
Step 3: – Agile teams reflect on a different questions – ‘what do we need to do to get to where we want to go’. Not what theories or principles do we need but what actions shall we take.
Step 4: – Those who come with the illusion of a quick fix or ‘the’ process solution suggest you can get to where you want to go through the adoption of their techniques. This should be discarded based on the action focus rather than this big picture ‘process’ focus.
Working in small steps, like all good agile teams, is the way to move forward with process / continuous improvement.
How do we know we are moving in the right direction? The answer to this question will depend on what area the team has decided to focus on. Are we trying to move to overall effectiveness? If so then perhaps velocity or completed stories might be the measure. However, if we are trying to eliminate waste due to poor coding then perhaps the amount of peer review, pair programming or number of unit tests in the regular build is a more useful measure. The team may change what they measure to reflect current realities and priorities.