Yesterday was the Israeli Scrum User Group for 2009. While we have monthly gatherings, usually for an afternoon or so, we try to have at least one full day gathering a year. The gatherings are organized by Agilesparks – we are trying to push the Agile/Scrum community forward as much as possible – both because we believe in the collaboration and value add that this community/tribe provides, as well as because the stronger we are as a community, the further Agile will go in Israel, which is good for everyone working in the Agile space.
We had very interesting speakers from all over the israeli community, including some of our partners and friends, topped by a humbling appearance by the one and only Dr. Alistair Cockburn who gave a keynote and a couple of sessions. I still need to gather my thoughts and notes as there were several ideas I took home with me, both from sessions as well as lobby discussions and questions from my session.
One concept that struck home was Feature Thinning which Alistair presented as a way to have the minimum (thinnest) implementation possible, relevant especially in the tale end of projects, when under schedule pressure. This is especially useful when under Fixed Contracts, where you need to have that “checkmark” that a feature exists, and having some minimal implementation is better than paying a penalty for having nothing.
As the other coaches in Agilesparks know, I have somewhat of a Kanban fever these days. I implemented a Kanban flavored Scrum over in Sanrad when I was VP R&D there, and I think it was a neat solution for our situation. My presentation, inspired by ideas from David Anderson, Corey Ladas and Karl Scotland, was an introduction to the subject, and covered the Why we might want to look at Kanban, What is it, how it can Complement Scrum, and what can we do with it.
One of the key places I see Kanban providing some much needed answers is what happens upstream to an Enterprise-scale Scrum development cycle. In one of our clients, we see a lot of mess around the backlog, requirements elaboration, having just enough design/architecture ready, and all in all being READY-READY for the sprints. We are working on a workflow that will include Kanban that will try to address this issue. I’m very much a workflow kind of guy, and had a lot of fun playing with workflows in Issue Trackers (mainly JIRA) in the past. I see great promise in the visibility and WIP control that Kanban will provide in this area.
I also think teams can get a lot of value from visualizing the workflow and thinking in WIP terms inside their Scrum framework. This will lead to a process of addressing problems in the short term and identifying and removing systemic constraints in the long term, assuming retrospectives are held effectively.
One of the key questions, which was also raised by one of the other speakers – Guy Nirpaz, is whether it is wise to use Kanban as a starting point on the way to agility. Kanban is clearly a less prescriptive methodology, and can be abused quite easily to become a phased/waterfall process, if the strive towards small MMFs, fast cycle times and SLA is not there.
OTOH the Kanban approach seems to have some advantages compared to Scrum – transition can be smoother, and agility/leanness can grow from the needs of the workflow and metrics, not from thin air. This can make it easier and clearer to some folk, and since an Agile Transition is a tough change, anything that makes the process itself smoother is quite important. I’m looking for the opportunity to try this approach and see.
For now, I think it is safe to say that if you are considering a Kanban-based transition, you should seek some professional help to help ensure you are going to the right direction, and your guide/coach is keeping you honest. Same is still true for a Scrum-based transition IMHO…
In the meantime, take a look at my presentation and tell me what you think…
FYI it has been featured on the slideshare homepage – the editorial staff liked it for some reason or the other ;-)
[slideshare id=1708889&doc=scrumban-taking-scrum-outside-its-comfort-zone-1721]