Lean Software Engineering

{ 8 }

Comments

1. Nivi | 15-Dec-08 at 1:35 pm | Permalink

   Hi guys, I really enjoy this blog. Are you planning on posting any sample chapters of the book to entice us to buy it? I’m interested in the book but I would like to learn more before I buy. Thanks!

2. Kenji HIRANABE | 15-Dec-08 at 6:59 pm | Permalink

   Congratulations!

3. Gerry Kirk | 15-Dec-08 at 9:31 pm | Permalink

   Looking for any reviews? Any reviewer copies available?

4. Ted’s Rants and Raves by Ted M. Young :: Kanban Book :: December :: 2008 - Software Development, Software Engineering, Agile Development, User Interface, and Applications Commentary | 20-Dec-08 at 1:00 pm | Permalink

   [...] BayAPLN meeting. On the Kanban developer email list, a new book on the topic was announced "Scrumban", so I immediately went over to Lulu.com and purchased it. I’ll probably start reading [...]

5. Clive Skipper | 22-Dec-08 at 4:44 am | Permalink

   Is the book still available? The link states “item not available”.

6. Corey Ladas | 22-Dec-08 at 3:13 pm | Permalink

   Hi Clive,

   Looks like we had a hiccup with lulu. Book is available as of 14:30 PST.

7. Jean-Marc Gerber | 01-Jun-09 at 1:11 am | Permalink

   Hi Corey,

   I just finished to read Scrumban book. Very interesting. It requires to be read carefully (and even re-read) to catch well concepts and practices you introduce but the book clearly worth the effort.

   I would like to submit to you a point which is still unclear for me. Page 102 “OFF WITH THE TRAINING WHEELS” section, you write “At the moment the item is
   pulled by the development team, the planning team is
   signaled to begin selecting the next item. If the planning
   team is fast enough in its response, then the
   development team will never stall.” As you mention, in Scrum the development team is supposed to provide/review size estimation for each thing to develop. In Scrumban, the estimation work should ensure that items to develop are of the same average size. Features, use cases or user stories which are considered too big should be then split in smaller items. In the prioritization-on-demand process, the planners must be very reactive to plan the next item to develop has soon as one item has been pulled by the development team. How the development team is involved in this planning activity ? I guess that in this case not all the team is involved in the estimation of each new item to plan, are there one or two experts from the development team which are supposed to be involved in the prioritization-on-demand activity ?

   Thanks

   Jean-Marc

8. Corey Ladas | 01-Jun-09 at 9:31 am | Permalink

   Hi Jean-Marc,

   It could be experts, it could be consensus. Daily standups can be used to organize ad-hoc planning assistance from the development team. The chapters at the end of the book about collaborative prioritization offer some suggestions. Something like the Priority Filter creates space and feedback to balance business desire with technical feedback. Similarly, for project work, Rolling Wave Planning makes the arrival of new work items less surprising.

   Another observation is that a kanban card becomes available because developers have completed work and have free capacity. You could have a policy where some developers are expected to review the backlog and provide feedback following the completion of the kanban they were attached to.

Post a Comment