I have had many great conversations with people and their stance on Kanban, time boxed iterations, etc… Recently, the conversation has been more towards why we do time boxed iterations? Developers who are fantastic engineers and are practicing many of the models for great software delivery (CI, CD, TDD, etc…) say they should just release the feature when it is done, no need for time boxing.
First, I could not be happier when I hear developers talk like this, they get the fact that we want great software that can be delivered in a pipeline requiring little to no manual intervention. While this is a good thing, it is not necessarily a reason to say time boxes are not necessary. Scrum strives to impact the entire organization, not just the development team. It is not simply about creating user stories, using crafty sequences of numbers that indicate relative complexity and effort, doing sprints, reviews, and retrospectives. While that is the core of the framework, those are just the mechanisms to help understand our progress and expose the issues on how we can improve along the way.
Time-boxes (in my opinion) serve as a good cadence/rhythm that allow for us as a team to deal with all the issues that prevent us from doing better. We get to have some time to review the work we just did as a check-point that we are on the right track, we get to look back as a team and understand ways we can improve, and we get to plan the next iteration. We can focus on seeing what is next in priority, plan how we are going to attack it, and then do it. Outside of those processes is the ability to take all the things that are preventing us from doing better and we get to challenge and educate the organization of our struggles and what we can do to change.
It is not simply about the team (although that is where it usually starts, because that is where the work is happening). It’s about the team showing the organization why it can’t do better and then working to do better. Scrum states “start with a product backlog”, but doesn’t necessarily define or prescribe a way to do that, so let’s work at getting a better understanding of what our software should do and the problems it is suppose to solve. Scrum states “working software at the end of each sprint”, but it doesn’t prescribe a way to do that (by design), so let’s work on our engineering practices to ensure we can get a feature from UI-DB in a vertical slice of the feature all the way through our development environment (what does it take to make a text change in your system and deploy through the entire system to production?).
Scrum is a great framework to help guide you on the continuous improvement journey and deal with the risks, uncertainty, and complexity that exists in software development. Let’s embrace that and have a framework that can help us manage the risk, uncertainty, and complexity. It is very small and simple to understand, but is very hard to do. It takes behavior and discipline to want to do better and stick to that. It is a never ending journey, take the attitude that you celebrate the problems exposed and know there will always be problems, don’t let that get you down. Be an eternal optimist and fight through those for the better.