During a meeting with one of our clients in New York the other day, the topic of enterprise development came up. He told me how in his environment – a globally distributed team working literally around the clock – Scrum was difficult to implement as there was a lack of standard development practices forming a base on which to add Scrum. I wasn’t surprised as they work with a total of 4 teams set up to have a 24-hour development cycle, and are dealing with 4 distinct cultures. That and it’s enterprise, which for me has traditionally meant heavy and slow.
I have made a conscious effort to stay away from enterprise-level consulting, which is ironic as some of our Rails clients are enterprise-level companies. I like working with smaller companies as they are more receptive to change, and even though there are some politics to deal with, they are nowhere near the extent to which you find them in large companies. I don’t deal with BS very well, and have 0 issue pointing out problems to be addressed. Our clients like this, however I’m told that enterprise clients, well, not so much.
I then read Simon Bennett’s blog post, “The philosophy of Kanban is kryptonite to Scrum.” I’ve been reading about Kanban, and looking to see where it would be most effective, and this post helped immensely. The main premise of Simon’s post was summed up by David Anderson – “Kanban is evolution while Scrum is revolution.” Simon also points out that, “Kanban allows for you and your team to simply ‘accept’ impediments, and measure their effect.” In Scrum, we make impediments known to all and ruthlessly seek to destroy them. It’s a not so subtle difference between Kanban and Scrum.
Now armed with that knowledge and what I know so far of Kanban, I believe that I can approach enterprise-level clients with Kanban, and use it to lay the groundwork for implementing Scrum. Awesome and exciting.
