Creating projects is not optimized for product development

Creating projects is still common in product organization, but it is really not optimized for product development. In this article, we give an analysis from one viewpoint.

website-optimization.png

1. The conflict between static skill and dynamic work

If you prioritize the work from customer point of view, you will inevitably find that the effort in each specialization area varies over time. The specialization area could be different functions, e.g. programming and testing. For some requirement, the effort on programming is big while the effort on testing is small; for other requirement, the opposite is true; still for other requirement, their efforts are similar. The specialization area could also be different technologies, e.g. front-end and back-end.

Here comes the conflict between static skill and dynamic work. If people are only working in their specialization area, the capacity will not match with the effort for any requirement. This means that if you work on one requirement at a time, some areas become bottleneck while others do not have sufficient work. The situation in those areas changes over time. Overall, the resource utilization will be low. How do you solve this problem?

2. Creating projects as a solution

One common solution is to create projects. Project groups a set of requirements and creates  batch. Even though for any single requirement, the effort in the specialization area does not match with the capacity, it is likely to match at the project level as the variation among requirements in the batch may average out. Taking it further, creating multiple projects in parallel makes it even more likely to match. In essence, one project and many projects both create the work batch, just to different extents. By doing so, the resource utilization gets improved.

3. The consequences, intended or unintended

However, while creating project and then projects, you increase the WIP and get longer cycle time. The flexibility drops due to the high WIP. Because the work in different specialization areas gets out of sync at requirement level, it creates various wastes such as waiting, interruption and relearning.

Do you see those consequences? Sometimes not, as you solely look at improving the resource utilization. Sometimes yes, then is it acceptable? That depends on your system goal.

4. What system goal do you optimize for?

If your system goal is higher resource utilization, then, you get what you want. However, if your system goal is something else such as higher speed and flexibility, then, creating projects is conflicting with your goal. For product development, speed and flexibility are critical factors, and they are often system goals to optimize for. That is why I state, creating projects is not optimized for product development.

In order to optimize for product development, the focus should be on the unit of requirement, i.e. doing smaller number of requirements in shorter time, ideally one requirement at a time. Instead of creating projects, you adopt product backlog and limit the WIP by either doing sprints in Scrum or setting WIP limit in Kanban.

How about you may still want to consider the resource utilization? You should look for alternative solutions by fostering dynamic skill to meet dynamic work. The cross-learning is essential to increase your resource utilization in the long term, without damaging your system goal.

The end

By the way, I did system modeling with CLD for this analysis, but decide not to include it. I envision a format of systems thinking analysis - first you see the analysis with text; then if you click "Expand", you see the analysis with CLD. Just imagine:-)

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