Our team has decided to take a step back towards scrum and away from our previous semi-Kanban approach. I think that it’s a good plan at this time, although I also suspect that many of the benefits of our earlier approach will continue to show through.
Why did we do this? Here’s some of my thoughts. They do not at all reflect the thoughts of anybody else on my team or in my company.
- We were unable to fully realize the benefits of Kanban. For example, we had a visual mapping of our value stream, but we never made the transition to using that visualization to improve how the team communicates within itself or to the outside.
- We lacked the process maturity to accurately forecast release dates for specific features based on lead times and SLA. I believe this was in large part due to the ongoing issues we’ve had with controlling batch size (both too large and inconsistently sized). I think we’ll be able to better do this in the future, but the current failures did not go a long way to building trust in our approaches with stakeholders.
- We had early success with Scrum before we changed product targets. Scrum has been highly effective for our management team in planning features at a high level. I believe that ordering and allowing the dev group to choose the amount of focus on each one would be more productive overall; however, we’ve had issues in determining a good order, and we’ve struggled to structure a good focus across roles within the group.
I anticipate that our “outward facing” status and planning will be Sprint-based, while our internal approach will remain somewhat Kanban. The sprint backlog will serve as our feeding buffer, while we’ll manage how much work we allow to be active amongst the team during a sprint the same way that we are now. The biggest difference is that our in-process lead time is artificially fixed at 30 days and our overall response time to external requests will average around 45 days.