Bugs in Agile

I would like to state again that "any agile project should not have much open defects". Let me explain this a little more.

First, the reason for not keeping defects open has several reasons. The first kind-of obvious reason is that the longer it stays open, the more it costs to fix. This is mainly because the developer has moved on to other things and it's not "fresh" in his mind. The second reason is feedback which I come back later. The third reason for this is IMHO somewhat more important to understand. One of the key points of Scrum and iterative development is the ability to reprioritize and respond to the market, every month. This can be done because every sprint delivers "done" functionality. When software is kept in such a state then whenever the product owner says: "ship it!" then it ought to be shippable. Yes, there are some things (delivery stuff) that need might not be done, but they sort-of take a "fixed time". Bugs from earlier iterations, however, are UNDONE work. A bug means the work was not finished. A bug backlog means a list of functionality that was not implemented yet because something needs to be done. This means that there is a unknown-size buffer in the project, which makes the project not flexible or, if you wish, not agile in the exact meaning of the word. Having open bugs gives the product owner a fake sense of progress, an illusions. It moves the project back in waterfall. There will need to be awful bug-fixing periods at the end of the release. Same as previous panic.

Thus, having open bugs is a bad sign for an agile project and suggests that they are either back in some kind of waterfall or will fall back into it in the future when they are closer to release. (At least they will break the sustainable pace).

Someone pointed out, correctly, that it's very difficult to actually make no defects. Especially in "traditional" development. So how can this then have changed? Well, there are a few agile practices which allow for faster learning cycles and thus should make it possible to reduce bugs to, at least almost, zero. The most obvious one is, of course, iterative development with retrospectives. If you have 10 bugs at the end of an iteration, does your team ask: Why do we have 10 bugs open. Which means: Why do we have undone work. Which means: Why have we not finished one month of work in our estimate. Teams that are answering this question every month, or better, every 2 weeks SHOULD make improvements in their ways of development rapidly. If not then they do not use the feedback information that iterative development provides them.

Next to this basic practice, agile development promotes some "engineering practices" which ought to create a capability within the development teams to create bug-free software. Continuous integration for giving quick feedback on synchronization issues and showing the current status. TDD for the personal development cycle and working to high levels of regression test. Pair programming for constant reviewing. A-TDD for bringing in functional and system testing and letting them work together with development on the same functionality in the same iteration. Refactoring to keep you fast and clean.

Thus: "A project with a big open bug list is not an agile project"

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