Lean Thinking and Agile Testing


In the past, we saw testing as the later phase, if not the last, in waterfall pipeline. The project manager always says “Finish the coding early so we can have time to catch and fix bugs”. This sounds straightforward and no brainer but if we look back all of those projects were mostly failed.

According to Lean Thinking it is not a good idea to try to finish work in big batch and test it in bulk. The reason is, if there is a misunderstanding in the design, the more code we do the more bugs we fix, and of course, the more rounds of testing. It is all wasted.

In Lean, there are three levels of problem solving. The lowest one is Reactive which is when we create the problem and fix it later. The second is Proactive in which we have the solution prepared before the problem occurs. And, the best one is Preventive, the one we keep the problems from happening. It is the most cost-effective one.

The waterfall way of work is Reactive. That is why it is very wasteful. The team needs to spend much time on fixing and re-testing the products. On the other hand, in Agile, the testing ideas are discussed before the real code is implemented. It is similar to when the teacher gives the students all questions and answers before the test, the students will make good scores.

The Preventive testing in Agile should not be stopped just on discussing and sharing the testing ideas. To eliminate more waste, the quality must be built-in in every step. There are many methods to help this, for example, Domain Driven Design (DDD), Test Driven Development (TDD), Acceptance TDD (ATDD), Continuous Integration and Continuous Delivery (CI/CD), etc. These methods will help to free up our precious QA to be able to do the more valuable work for example, explorative test, usability test, etc.

The Lean/Agile Testing may seem hard to implement at first but in the long run it will promote a quality culture that everyone focuses on preventing the defect to lurk in to the product code base, which will result in better teamwork, lower cost and shorter time to market.

— Home Assignment from Agile Testing Certification – Bangkok

Advertisements

Maxwell Curve : ทำไมยิ่งลงแรงมากยิ่งได้งานน้อย


ถอดความจาก The Maxwell Curve: Getting more production by working less!

Maxwell Curve

เรื่องมีอยู่ว่าระหว่างที่เจฟ ซัทเทอร์แลนด์(Jeff Sutherland) ทำงานเป็นโค้ชให้กับ OpenView Venture Partners หนึ่งในผู้บริหาร(Scott Maxwell) ได้มาหาเขาพร้อมกับกราฟ หน้าตาเหมือนข้างบน เขาตั้งชื่อมันว่า “เส้นโค้งของแมกซ์เวล” (Maxwell Curve) อ่านเพิ่มเติม

Sprint เป็นแค่ checkpoint


โค้ชหน้าแมว ได้รับการมอบหมายจากเจ้านายใหญ่ให้มาดูแลสกรัมทีมทีมหนึ่ง ซึ่งโค้ชหน้าแมวรู้สึกว่าตนเองโชคดีเหลือเกิน เพราะทีมดูจะเข้าใจวิธีการทำงานแบบอไจล์ดีอยู่แล้ว และที่สำคัญทีมร่วมกันทำงานมาถึง 17 สปรินต์ ซึ่งถือว่าไม่ใช่มือใหม่แล้ว ซึ่งความจริงก็สงสัยว่าเจ้านายใหญ่ทำไมจึงคิดว่า ทีมนี้จะต้องการโค้ชอย่างโค้ชหน้าแมวได้ แต่ก็ได้แต่เก็บความสงสัยไว้ในใจ

อ่านเพิ่มเติม

Agilist + Defensive = Manager


สิ่งสำคัญที่อาจเรียกได้ว่า เป็นหัวใจของอไจล์ คือ การร่วมไม้ร่วมมือกันทำงาน หรือที่เรียกว่า collaboration ในวงการอไจล์นั้นมีคำติดตลกที่เรามักใช้เรียกกลุ่มคนที่มีแนวคิดหรือปฏิบัติที่ตรงข้ามกับแนวคิดอไจล์ว่าพวกเขาเป็น Manager ลักษณะที่เรามักเห็นในคนกลุ่มนี้คือ พวกเขามักจะ ยึดตนเองเป็นศูนย์กลาง คอยกำกับควบคุมคนอื่น ตัดสินใจเรื่องต่างๆ เองคนเดียวโดยไม่สนใจรับฟังความคิดเห็น หรือเรียกได้ว่า มีลักษณะ dictatorship สูงกว่า leadership จึงไม่น่าแปลกใจว่าในกลุ่มคนที่เชื่อในแนวทางอไจล์น่าจะพบเห็นลักษณะแบบนี้น้อยกว่าคนกลุ่มอื่น

นั่นเป็นสิ่งที่ไม่จริง!!! อ่านเพิ่มเติม

Output, Outcome และ Scrum Master


เมื่อท่าน Bomb โพสคำถามลงใน agile66 คำถามนั้นย่อมไม่ธรรมดา ท่านถามว่า

ผมกำลังสับสนระหว่าง output กับ outcome ของกลุ่มคนที่เรียกตัวเองว่า ScrumMaster หรือ อีกกลุ่มนึงท่เรียกตัวเองว่า Agile Coach ผมเคยได้ยินว่า output ของคน 2 กลุ่มนี้คืดการการ Build Team เพราะฉะนั้น output คือทีม แต่ outcome ที่ได้คือ product ที่ทีมนี้สามารถสร้างออกมา เป็นรอบสั้น ๆ รับ feedback และเอามาใช้เพื่อให้ได้ product ที่ตรงตามความต้องการและตอบโจทย์ของธุรกิจ แต่ผมไม่รู้ว่า พี่ ๆ ในห้องนี้มีมุมมองยังไง กับเรื่องนี้ครับ

อ่านเพิ่มเติม

The Matrix, Enterprise และ ความอยู่รอดของ Agile


ช่วงนี้มีการพูดเรื่อง scaled Agile เยอะมาก สิ่งที่ผมรู้สึกหวั่นคือ บางค่ายบอกว่า อไจล์นั้นมีแค่ Scrummaster ProductOwner และ ทีมเท่านั้น โรลหรือแผนกอื่นๆ เช่น project manager หรือ Architect เป็นสิ่งไม่จำเป็น ซึ่งในตอนแรกผมยังไม่ค่อยเข้าใจตนองว่าทำไมจึงรู้สึกหวาดหวั่นกับ แนวคิดนี้มาก จนกระทั่งนึกย้อนไปถึง หนังเก่าเรื่องหนึ่งที่ตัวเอง ออกตัวว่าชื่นชอบมาก The Matrix อ่านเพิ่มเติม

เรื่องเศร้า ชาวฮิปสเตอร์


ได้รับการแชร์วิดีโอนี้เมื่อวาน ไม่ได้สนใจมาก แต่บังเอิญลูกสาว เดินผ่านมา แล้วบอกว่า อยากดูอันนี้ คงเพราะเป็นรูปการ์ตูน จึงสนใจตามประสาเด็ก พอดูเสร็จก็บอกว่า “หนูเสียใจ” (คงแปลประมาณเธอรู้สึกเศร้า แต่ภาษาเด็กยังมีคำไม่เยอะ) ซึ่งเรื่องนี้ก็เป็นเรื่องเศร้าจริงๆ อ่านเพิ่มเติม