ScrumBan Review


Scrumban in a small book by Corey Ladas self-published by lulu.com. The name is somewhat confusing since most of the book is about setting up a SW Kanban system and only a couple of pages are about scrumban (the hybrid between kanban and scrum).

Scrumban is an rather interesting book. I loved reading it and I think that it is an important contribution to software development. I say this even though I disagree with perhaps half of the book -- or at least consider them to be build upon shaky assumptions. Whether that is true or not, Corey delivers an interesting way of thinking about software development and a good basis for further discussion and improvement.

The book describes applying lean manufacturing techniques to software development. Unlike earlier lean material, it takes lean techniques and maps them to software on a very concrete level. The main technique taken from lean is the kanban technique for scheduling work. The book starts by describing "ideal" states of how software development should look like when mapping lean ideas to software. After that, it takes a couple of steps back and gradually builds up a kanban system by discussing one improvement to the system at the time. Halfway the book it describes how you can start applying kanban within your Scrum implementation and gradually improve it until its not scrum anymore, but kanban.

The end of the book discusses some more 'advanced' techniques like handling bugs, improving handovers, prioritizing backlogs and ... silver bullets :)

Corey tries to find a balance between traditional learnings and agile learnings. He tried to balance advantages of specialization with flexibility of generalization. He also tried to define a way of defining processes where Scrum basically just says "go and figure it out for yourself." This approach brings an interesting perspective to development processes.

So, what didn't I like? The book seems to assume that there is such a thing as a perfect workflow for software development. It even goes so far to suggest that this perfect workflow looks like the V-Model. If thats not bad enough yet, it suggests that XP is a "modern implementation of the V-Model." Here I start to feel somewhat uncomfortable. Why? A good team, IMHO, switches between the activities of software development constantly, within minutes. Work doesn't flow from one activity in another activity. Thats a workflow does doesn't fit in development, but has been artificially put over it. I would call it far from ideal, however, the V-Model workflow assumptions seem to run pretty deep in the book.

I loved the discussions on specialization and generalization. However, I'd stress domain-based specialization over activity-based specialization. Though, that doesn't seem to be covered much, except in a small part on scaling, but here it suggests to scale via component teams...

Another interesting thought that made me uncomfortable is the idea that there is such a thing as "in-control production" and special/common causes within that. To me, it feels like a manufacturing assumption within product development. Though Corey does cover these assumptions and makes great points about how to control variability, I'm not sure if it is a good thing to do.

All in all, the book gave me interesting thoughts and I might even be experimenting with some of them! I would NOT recommend reading the book when you are fairly new to agile development. The book assumes a pretty good understanding of certain concepts. However, if you want a different view on agile development and some different ideas, I would suggest reading this book. It will almost certainly contain some new ideas which makes the book worth reading.

Thanks to Corey for writing this small and interesting book.

The book is available here.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai