Thinking about continuous improvement the other day I tried to figure out what makes a continuous improvement process work and what makes it stick, these are my thoughts:
- It should be a slow, gradual process of change, no “sudden movements”.
- It should be a continuous flow of change, no settling down into a rut.
- It should be a culture, not a bunch of individuals with ideas.
- It should be unanimously accepted.
- It should be measurable.
- It should be celebrated.
- It should be evangelized.
- There should be room for failure, and for success.
- It should be rewarded.
- It should be encouraged.
- It should become default behaviour.
- It should be transparent.
After completing the first sprint since the training I feel I need to have sort of retrospective for myself on how I handled it.
What I did well
Always difficult to toot your own horn, but here goes:
- I believe I explained the process reasonably well to anyone that asked.
- The (improvised) Scrum Board I created was pretty good and effective I think, I’ll post a picture for comment, I specifically asked total strangers to come in and ask them if, by glancing at the board, they got a decent idea of what was happening, most people answered “Yes”, some people didn’t care, and others asked me to stop harassing them… go figure 😉
- I evangelized Scrum so well that I’ve had a few requests from people to meet one on one with them and explain in detail what it’s about.
- I protected the team well, they were relaxed throughout the sprint and were, for the most part, uninterrupted (managers sneak in when you’re not around, note to self: investigate Tesla Coil option…)
- I assisted the Product Owner effectively in generating a prioritized Product Backlog.
Where I can improve
Ok, here goes with the places to improve (that I can think of)
- I interfered too much, often guiding the thoughts of the team. This one was difficult to avoid because of my (prior) senior technical role, and I don’t think it had a bad impact, although it did not give the team the opportunity to become a fully autonomous unit.
- I ended up prompting people during the daily scrums, not good, the team needs to run these.
- I updated the Scrum Board and managed the burn-down chart, again, not good, I believe the team must run this.
- I allowed the daily scrums to degenerate into a problem solving session.
- I did not manage the time-boxing of meetings well.
- People missed meetings, or were late, without any form of “reprimand”. Not sure how to fix this though?
- Did not hold a review at the end of the sprint, bad! Must have this in future, perhaps pre-schedule the meetings at the beginning of the sprint.
- The retrospective needs improvement, again I prompted alot of the talking, perhaps the team wasn’t comfortable with opening up?
- I need to understand the finer details of Scrum better, especially around estimation.
- The team did not define DONE, I should have encouraged this.
- I allowed the sprint backlog to be changed during the sprint! Very bad.
- I did not include all the necessary people into the “team”. Important people were excluded initially (like testers) without realizing it. This contributed to the sprint “failing”(coming in 2 days late, features could not be removed) due to test tasks not being included initially.
Ran the first retrospective today, the team seemed a bit apprehensive but eventually started talking, but only after alot of coaxing, which for me bordered on interfering again, but what else could be done? I explained the point behind a retrospective, to see what we did well, and where we could improve; I tried to set a relaxed mood but I don’t think it worked too well, people were very quiet for the most part. I still struggle with this part, how to get people to open up and talk about things. Eventually though we did hammer out some potential improvement areas and put those up on our impediments list for me to deals with. I guess there was some value gained from it, although I’m wondering how the team will fair once I’ve left…