I have often been explaining how a LeSS adoption gets started on various occasions, so I decided to write it down as an article, not to avoid doing it any more - I will still do it as the interaction alongside it is irreplaceable - but to make it a
I have advocated to balance framework focus with experiment focus in the use of LeSS. As the framework focus is already strong, I’d like to elaborate more on the experiment focus. Is it possible to adopt LeSS without adopting its frameworks? I think yes, as that is actually continuous
ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั
ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ
กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี
ผมกำลังเรียนวิธีใช้เสียงในคอร์ส Stage Academy ของ Vinh Giang ในคอร์ส ผมได้เรียนเกี่ยวกับแม่แบบของเสียง 4 รูปแบบดังนี้ Motivator ผู้จูงใจ เป้าหมายของผู้จูงใจคือการจุดประกายแรงบันดาลใจ องค์ประกอบของการใช้เสียงรูปแบบนี้คือ * เพิ่มความเร็วในการพูด * เปล่งเสี
ตอนนี้แล้วผมกล่าวถึงความสำคัญของเอกสารที่สามารถ execute เพื่อตรวจสอบดูว่ามันยังจริงอยู่ไหมได้ในรูปแบบของ unit tests ซึ่งเอาไว้เก็บบริบทของปัญหาที่เรากำลังแก้ หรือเรียกง่าย ๆ ว่า requirement ตอนนี้เราจะมาพูดถึงเอกสารที่ใช้ในการ build software เช่น build script หรือแม้
เวลาผมสอนเรื่อง pair programming ปรกติผมจะเล่าคร่าว ๆ ว่า pair programming มี 2 แบบที่ผมใช้บ่อย ๆ คือ ping pong ที่ใช้เวลาคู่ pair ชำนาญพอ ๆ กัน กับ driver-navigator ที่ใช้เวลาความชำนาญต่างกัน ช่วงนี้มีโอกาสได้ pair กับสมาชิกในทีมบ่อย
หลายปีก่อน ผมมีโอกาสได้ pair programming กับเพื่อนร่วมงานสุดหล่อชื่อเจน ตอนนั้นเราพยายามทำ เขียนพวก AD authentication ด้วย Ruby ตอนแรก ๆ ก็ลื่นไหลดี ซักพักเราก็ติดกัน ไปต่อไม่ถูก ระหว่างนั้นเจนก็พูดอะไรออกมาก็ไม่รู้ ผมฟังไม่เข้าใจ ผมเลยกลั
manage interruption อย่าให้ อย่าให้ interruption manage เรา ช่วงสัปดาห์ที่ผ่านมา ผมมีโอกาสได้อ่าน หนังสือ working from fucking home ของ Alexey Krivitsky หนึ่งในคำแนะนำคือ ถ้ามีปัญหาเรื่องการ focus กับงานให้ลองใช้ Pomodoro ดู Working from (fucking) home ผมเคยฝึกใช้ pomodoro
เคยไหมที่เจอเหตุการณ์ให้ต้องไปอ่านโค้ดคนอื่น แล้วพออ่านเสร็จก็เห็นว่าโค้ดมันผิด เลยไปแก้มันให้ถูก แต่พอคิดอีกที ไม่แตะมันดีกว่า แล้วก็ undo จนมันกลับไปเป็นเหมือนเดิม ทำไมนะ? ผมเคยลองถามตัวเองดูว่าอะไรเป็นสาเหตุที่ทำให้
เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ
ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership
ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที
มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี
ไม่นานมานี้ ขณะที่เก๋ไปสอนสกรัมที่ม. วลัยลักษณ์ ผมได้ร่วมสอนคอร์ส Test-Driven Development (TDD) โดยปอนด์กับจั๊วะ ปรกติคอร์สนี้ราคาที่ละ 7,500 บาท/คน แต่ครั้งนี้เหลือ 399 เพราะ พี่รูฟบอกว่า ขณะที่กำลังสอน ก็มีคำถามที่น่าสนใจมากจากผู้เรี
Polarity Management
นอกจากพาราดอกซ์จะปรากฏในรูปของความขัดแย้งภายในบุคคลและภายในทีมแล้ว ยังปรากฏภายในองค์กรด้วย ปรกติวัฒนธรรมขององค์กรจะเอนไปทางขั้วเดียวกับที่ผู้นำให้ความสำคัญ เช่น ถ้าผู้นำให้ความสำคัญกับระเบียบวินัยและความเรียบร้อย ความสร้างสรรค์ซึ่งมักจะมาพร้อมกับความวุ่นวายไร้ระเบียบก็จะถูกกดทับ แล้
Paradox
ในตอน 2 ผมได้แบ่งปันว่าถ้าผมมองพาราดอกซ์ออก ผมสามารถเอาไปปรับใช้ในบริบทของ life coaching ได้อย่างไรบ้าง เป็นบริบทของการบริหารความตึงเครียดของพาราดอกซ์ในชีวิตคน ๆ นึง ตอนนี้เรามาดูรูปแบบของพาราดอกซ์ที่ออกมาในระดับทีมบ้าง ปรกติในทีมที่ทำงาน เป็นธรรมดาที่เราจะรวมผู้คนที่หลากหลาย แต่
skills
ก่อนหน้านี้ผมเคยสงสัยฝ่าเวลาเรากำลังฝึกฝน เราจะรู้ได้อย่างไรว่าแบบไหนที่เรียกว่าพยายาม และแบบไหนที่เรียกว่าฝืนเกินไป ปรกติผมจะแยกมันด้วยผลลัพธ์ นั่นคือถ้าฝึกเสร็จแล้วไม่บาดเจ็บ ก็เรียกว่าพยายาม แต่ถ้าปรากฏว่าเจ็บ ก็เรียกว่าฝืนเกิ
Paradox
ครั้งที่แล้วผมแนะนำให้รู้จักกับพาราดอกซ์คร่าว ๆ และบอกแล้วว่ามันไม่ใช่ปัญหาที่ต้องแก้ แต่เป็นสมดุลย์ที่ต้องบริหาร เพื่อให้เข้าใจคำว่า ชีวิตติดลูป มากขึ้น เรามาดูตัวอย่างตอนผมมองพาราดอกซ์ไม่ออก แล้วหลงคิดว่าเป็
Polarity Management
ผมเพิ่งกลับจากคอร์ส polarity management ของ Tong Yee ที่สิงคโปร์ ผมได้เรียนรู้ว่า polarity หรืออีกชื่อหนึ่งเรียกว่า พาราดอกซ์ (paradox) นั้นคือขั้วตรงข้าม แต่เป็นขั้วที่จำเป็นทั้งสองด้าน เช่น การฝึกฝน กับ การพักผ่อน ถ้
The Candidate LeSS trainers mailing list is where passionate people have interesting discussions. This post is a result of one of those discussions. An assumption in the agile community is that scaling agile is mainly about managing and reducing dependencies, either between teams or with others outside of a product
In the article “Beyond adopting LeSS”, I advocated for more balance between framework focus and experiment focus. In this article, we shall explore the key factors and dynamics involved in them. “framework focus” means: - adopt frameworks, which are more prescriptive and introduce a big batch of changes. For example,
While developing products, there are two common modes. One is creating development projects when needed; and the other is doing continuous product development. While improving organizations or changing things for the better, there are two similar modes. One is creating change projects when needed; and the other is doing continuous
Will you adopt LeSS? Not wanted, or not possible; end of story. This is a loss of opportunity for both. For LeSS, it loses much of its potential to make an impact in the domain of large-scale product development; while for organizations, it loses the opportunity to get inspired by
CLD (Causal Loop Diagram) consists of causal links and loops. Without solid links, there will be no solid loops. While we practice system modeling using CLD, the first gap is usually at stating a causal chain of links clearly. Therefore, we often spend the majority of time in practicing causal
In many if not all Agile ways of working, team self organizes to take shared responsibility. This often means to transition from role-based working model to agreement-based working model. This transition doesn't happen automatically, and it needs to be nurtured. Roles are gone When a team takes shared
In many organizations, there is dedicated team responsible for shared components. Meanwhile, there are multiple business/product teams, and they all request work from the shared-component team. The below diagram shows a typical case. The most pain associated with shared-component team is the waiting, leading to longer end-to-end cycle time.
It seems self-evident that story is only about change - when it gets done, it becomes part of the baseline. However, in practice, I often observe that people don't make the distinction between change and baseline, which causes pains. Mixing change and baseline Let's look at
Reorganize to adapt Uncertainty causes the need to adapt, but the current organization structure is a drag for adaptation. It seems inevitable to reorganize to adapt. Let's elaborate. The current organization was set up based on certain (pun intended) assumptions. We looked at what needs to be done,
Ultimately, we want to have one product backlog for the whole organization in order to optimize value globally. However, the current reality is often lack of global priority, with many local backlogs. What could be practical next steps in order to gradually establish global priority? I have been suggesting to
I have written the series of "limits to one product backlog" for a while, and the recent observation and thought triggers me to write another one, which is an addition to the 4th article. We shall elaborate on the capability of prioritization as a limit. The above diagram