Improve Continuously
Last year I spent 3 months training, majority on our 1-day Introduction to Scrum course. This was an incredible opportunity, not only help teams start on agility, but also to iterate, improve, and innovate on the course itself.
Scrum teams improve every sprint in 2 ways: they improve the product, and they improve how they build the product. This improvement is continuous, with a regular cadence in the form of the sprint. I drew parallelisms to this from the training courses I gave last year.
There is always a better way
Improvement is the struggle between the good from the better. When is good enough, good enough? Our course was interactive and activity-driven at the start of 2017, one of the many refinements we’ve taken in the last 4 years. I honestly thought we couldn’t improve on that. That is, until we did.
Talking about frameworks is a struggle. People learn Scrum better through experience — after all, Scrum Masters master Scrum by doing Scrum. A simulation would be great, but fitting everything in a single day is difficult. We eventually asked: why not treat the entire 1-day course as a sprint itself? This freed up time for all the content, while providing a simulation to experiencing Scrum so we could reflect on it as a class.
This is underscored by the belief that there is always something better. In software development, practices and understanding continue to evolve and improve. I remember a few years back when story points and velocity where the norm, only to be refined and improved by sizing items to 2–3 day increments and splitting relentlessly — the former is good, but the latter is clearly an improvement and superior.
Failure is always a possibility
Improvement is taking a step into uncertainty, perhaps to do something that hasn’t been done before. This may be a new idea, or one that will be applied in a new situation. Thus, there is a chance that it will be successful, and a chance that it wouldn’t.
In our course, I once tried to have teams role play the 12 Agile Principles. Each principle was an item in the Product Backlog, and we prioritized each sprint. That didn’t work out at all. Fun, yes, but it simply revolved on the misunderstandings everyone had on Scrum. I had to align that, so that the participants won’t pick up the misunderstandings. And that experience led to the training-as-a-sprint improvement.
Accepting that you can be wrong is the first step. This allows one to reframe each step as experiments to learn more about a situation, rather that something definitive. The key is to make failures small, so we can recover from them and try again. In software development, the features that we build are assumptions that are really validated only when we get them out. This is where sprints and increments come in, as they focus the effort and lead Scrum teams to validate quickly.
Let the team drive improvement
In the end, the team will deal with the change caused by improving, so it is best to leave them on the driver’s seat. In our course, I always ask myself if I am confident enough to be able to clean things up when the improvement I’m about to try goes south. If yes, proceed, otherwise perhaps the improvement is too large and that I need to take a smaller step.
Same thing with Scrum teams when they try to improve, and events such as the Sprint Review provides feedback on the product, and the Sprint Retrospective on how the team builds the product.
Defining the intent of an improvement, improving one small thing at a time, and being deliberate were some useful things I took from this. Doing the same course over and over again, the way that we build software day in an day out, allowed me to make small improvements along the way.
Some participants who attended again after a few months pointed out the differences and how it made the course better. And I’m sure there are a lot more things we can improve this 2018.
I’ve had participants ask me how I survived all those courses last year. Improving continuously was the key. On reflection, I’ve been part of product development teams for long periods of time, mostly years. There are points that even getting out of bed was hard, and the only way I continued was to deliberately try to improve things one at a time.
Continuous improvement is really about reaching perfection — we’ll never be perfect, but we can get closer and closer to it with each passing moment. It all starts with the belief that we can improve, that every try may or may not work, thus we should take control and move to the direction of our goal. Keeps things a lot interesting too.
