The May 30 I participated at the Lean Kanban Southern Europe meeting in Bologna. The experience was great, very inspiring and when I came home I was tempted to change the schedule of my blog and to post a report of it instead of the post on “pawns and tiles”.
At the end I preferred not to rush and take my time to metabolize what I learned.
I have to warn you that this post probably won’t come to some resolution, it’s mostly free thoughts I like to share.
No surprise that my favorite speaker had been Joakim Sundén from Spotify, his speech was fresh, intriguing and he described a well known and winning situation: I like the happy ending mostly if it arrives thanks to practices in which I believe so much.
First of all I LOVE his accent, but more important, before his speech I knew not to know Kanban very well and after his speech I knew that I didn’t know it at all.
That’s ok, I mean, I never pretended to know Kanban, I was born with Scrum and I ever practiced only this.
Now I think it’s about time that I learn Kanban.
Anyway the point I appreciated the most was:
Frequent deployment is more agile.
On-demand deployment is most agile!
Maybe it sounds obvious to you, for me it wasn’t.
I think it is a powerful concept and I remember all the times my Stakeholders asked for more flexibility in our process.
I think we improved a lot and now our sprints are more valuable than in the past and our Stakeholders are more satisfied (I was tempted to write “completely”, but I’m not a good liar 🙂 ), but we are far far away from a “on-demand” process.
Maybe we don’t need it right now, but what if it will be needed?
Should we try even if we don’t need, because we committed to the improvement?
What are the better steps to improve our workflow and to have a real continuous improvement?
Joakim Sundén showed a chart of the agile methodologies used at Spotify:
Listening to him it didn’t sound wrong that teams didn’t go with pure Scrum or Kanban.
His point of view is more agile: find the perfect method to manage the specific problem.
It makes sense to me, but the risk is to lose the direction.
When are you improving your processes and when are you performing a Scrum-but?
When are you doing your duty defending the team and the process and when are you resisting the change?
What are the metrics to say you are leading a team to a useful Kanbanesque and not to a complete mess?
Maybe the approach “by the book” is my limit, it is my personal comfort zone I have to leave in some way.
I hope to come out with something smart in the future, but if you want to share your thoughts about this, or you have experienced these doubts, please share your thoughts leaving a comment.
Here few links about these topics, I hope you will find them useful.
David J Anderson