We hear a lot about applying agile techniques to software projects for producing software. Can Scrum techniques be applied to action-items from a retrospective; specifically process-improvement? Imagine you’ve reached the end of an iteration and you’ve held your retrospective. You and the team now have some action items regarding feature changes and you also have changes to your process. How do your process changes fit into your Scrum project-cycle?
This question arose at a recent XP Toronto meeting and we had several thought-provoking answers. Here is one answer to the question.
In essence the technique for dealing with process-related goals is no different than dealing with features or user stories in a sprint with the addition that we will make a decision about who executes the work.
Step 1 – Who is the customer?
We need to find a product owner for the process improvement items. This step is essential because we need to know the business value of the process improvement and also who benefits from that improvement. For example we may have identified an improvement item during an iteration for a customer but the improvement benefits us and may not produce business value for our customer. In this case our process improvement needs to be owned by us.
Step 2 – What’s the value?
Providing we can identify the customer we can ask the customer or the customer-representative what the business value of the improvement is. With a business value in-mind we can add our process-improvement item to our backlog ad proceed with our sprint planning as usual.
The question that arose in our XP Toronto meeting was this; how do you convince a customer that they should accept a schedule-hit for making a process improvement. The answer is by presenting the customer with the business value of the improvement. For example; if we spend 2 days implementing a new build system we can improve time-to-market and reduce customer costs by 5%.
If we cannot present the customer with the business value of the improvement that’s a strong indicator the improvement either isn’t worth doing, or, it’s an improvement that benefits us and not the customer. If the benefit is to us then we should structure the work outside the customer’s project and execute the improvement work using separate resources. Since our improvement work executes separate from our customer’s work we do not have to convince our customer to take a schedule hit because there is no schedule hit from the customer’s perspective.
(Many thanks to XP Toronto and Ryerson University for hosting our monthly meetings)
Posted by robertmacgregor 
Posted by robertmacgregor 
Posted by robertmacgregor 
