One question that is constantly coming up is this one – How do we form Scrum Teams?
Here' my opinion – and blunt answer:
It does NOT matter what team you form the first time you will get it wrong! So what matters is HOW you plan to re-form the teams. Rather than assuming you can get the correct solution – figure out a way to work toward a better solution. This is applying the concepts from Complex Adaptive Systems (CAS) the great grandmother of Scrum. Almost any system with a human is going to be complex – the question is – will it be adaptive. FIRST - Plan to form your second team – how will you reform teams. Then it doesn't so much matter what the first (and obviously wrong) team is – you will have a way for that team to decide when & how to reform into a better team. So now we need some ideas about what might decided when and what might decide who and what might be a measure of good & bad and good enough the criteria by which the team decides to reform.
So I'm not going to tell a group who should be on what team. I want them to realize there is not a perfect answer – but we do have principles!
What are those principles? Come on – dig deep – what principles can we draw upon to define Scrum teams?
Here' some background on this – if you want to have an informed opinion about Scrum and team formatting – this is a great place to start…
http://featureteamprimer.org/
Here' my opinion – and blunt answer:
It does NOT matter what team you form the first time you will get it wrong! So what matters is HOW you plan to re-form the teams. Rather than assuming you can get the correct solution – figure out a way to work toward a better solution. This is applying the concepts from Complex Adaptive Systems (CAS) the great grandmother of Scrum. Almost any system with a human is going to be complex – the question is – will it be adaptive. FIRST - Plan to form your second team – how will you reform teams. Then it doesn't so much matter what the first (and obviously wrong) team is – you will have a way for that team to decide when & how to reform into a better team. So now we need some ideas about what might decided when and what might decide who and what might be a measure of good & bad and good enough the criteria by which the team decides to reform.
So I'm not going to tell a group who should be on what team. I want them to realize there is not a perfect answer – but we do have principles!
What are those principles? Come on – dig deep – what principles can we draw upon to define Scrum teams?
Here' some background on this – if you want to have an informed opinion about Scrum and team formatting – this is a great place to start…
http://featureteamprimer.org/
"A feature team is “is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Feature teams are an essential element to scaling up agile development. Without a feature team structure (but instead, a component team organization—based on code ownership, combined with a single-function organization—analyst group, programmer group, testing group, ...) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, ...) development cycle. Feature teams structure resolves many of these wastes but also introduces change and challenges."
Comments