Is team in Scrum feature team?

Feature team gains popularity, but the difference between feature team and cross-functional team is still confusing to many people. Surprisingly, I failed to find good reference to clarify it, thus I decide to write one.

1. Does Scrum require feature team?

If you read Scrum Guide, the below defines the (development) team.

"The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of 'Done' product at the end of each Sprint."

And it is clear that team is cross-functional.

"Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment."

However, it is not clearly stated whether it is feature team (vs. component team). This creates lots of confusion about whether cross-functional team implies feature team, and whether they are the same thing.

2. Does SAFe require feature team?

In my previous articles and presentations, I mentioned that SAFe did NOT require feature team, though it might still recommend it, it is not part of essential SAFe. One friend in the community argued with me that SAFe also requires feature team. His view was, as Scrum is used at team level in SAFe, and Scrum requires feature team, therefore, SAFe requires feature team. His argument has relevance to the same confusion - does Scrum require feature team?

If you read SAFe, the below defines the (Agile) team.

"An Agile Team consists of a small group of dedicated individuals, who together have the skills necessary to define (elaborate and design their component/feature), build (implement their component/feature), test (run the test cases and validate the component/feature) increments of value in a short timebox."

It is clear that team is cross-functional. It is somewhat clear that component team and feature team are both possible.

3. Does LeSS require feature team?

In LeSS, the below rule makes it clear that LeSS requires feature team.

"The majority of the teams are customer-focused feature teams."

The root of the confusion

Back to Scrum, it uses "Increment of 'Done' product" when defining the team. The root of the confusion is from being unclear about what the product is. In SAFe, it uses "increments of value". It does not help much to clear the confusion as it is not clear what value is either.

The question of "what the product is" sounds trivial but deserves deeper thinking. LeSS states, "When starting a LeSS Adoption, one of the first things to clarify is what your product actually is."

The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product.

  • If you define your component as product, the requirement on the component becomes feature.
  • If you define your platform as product, the requirement on the platform becomes feature.
  • If you define your "product" as product, the requirement on the "product" becomes feature.
  • If you define your solution as product, the requirement on the solution becomes feature.

The feature-ness is a continuum!

This is nicely illustrated by feature team adoption map in LeSS. In my view, the more precise name should be cross-functional feature team adoption map, as there are two dimensions - cross-functionality and feature-ness.

Does it mean that the whole distinction of component team and feature team is meaningless? Not really. It means that the distinction is contained by what the product is.

In LeSS, there is a rule regarding what the product is.

"The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred."

Clarify what the product is, and form feature team to deliver Done product increment.

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