Comments on: Software process improvements with Lean and Kanban at BNP Paribas http://gojko.net/2009/12/08/software-process-improvements-with-lean-and-kanban-at-bnp-paribas/ Building software that matters Fri, 18 May 2012 13:40:15 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: gojko http://gojko.net/2009/12/08/software-process-improvements-with-lean-and-kanban-at-bnp-paribas/comment-page-1/#comment-68619 gojko Tue, 08 Dec 2009 21:07:32 +0000 http://gojko.net/?p=1461#comment-68619 Thanks for the corrections, I updated the article. Thanks for the corrections, I updated the article.

]]> By: Benjamin Mitchell http://gojko.net/2009/12/08/software-process-improvements-with-lean-and-kanban-at-bnp-paribas/comment-page-1/#comment-68597 Benjamin Mitchell Tue, 08 Dec 2009 13:02:38 +0000 http://gojko.net/?p=1461#comment-68597 Thanks for the comprehensive write-up. I'm intrigued that you thought it was a flawed scrum implementation. To my mind it was pretty 'textbook'. It did give us greater visibility and helped politically.  The inital use of Scrum was politically motivated, but the many improvements we've made since then were less due to politics and more due to continuous process improvement. The move away from Scrum came when we had a deviously difficut big in Internet Explorer (not a disasterous quality release; we did have to fix a lot of bugs before go live, but in general the production quality from this release has been good), during which we stopped many Scrum practices. After the IE issue was resolved we reviewed the process and decided we would customise the project and focus more on flow of ideas through the system in a continuous or JIT way, with the only time-boxed cadence on the release (every 2nd Wed). I now think that a continuous flow model is a far superior way of working in my context. I wouldn't go back to some of the Scrum constaints because I think they are constraints which we no longer get value from. Thanks for the comprehensive write-up.

I’m intrigued that you thought it was a flawed scrum implementation. To my mind it was pretty ‘textbook’. It did give us greater visibility and helped politically. 

The inital use of Scrum was politically motivated, but the many improvements we’ve made since then were less due to politics and more due to continuous process improvement.

The move away from Scrum came when we had a deviously difficut big in Internet Explorer (not a disasterous quality release; we did have to fix a lot of bugs before go live, but in general the production quality from this release has been good), during which we stopped many Scrum practices. After the IE issue was resolved we reviewed the process and decided we would customise the project and focus more on flow of ideas through the system in a continuous or JIT way, with the only time-boxed cadence on the release (every 2nd Wed).

I now think that a continuous flow model is a far superior way of working in my context. I wouldn’t go back to some of the Scrum constaints because I think they are constraints which we no longer get value from.

]]>