You already know the root of the problem. Work your way from there...
1- Get the products owners (PO)/business...and let them know the situation.
2- With the POs, divide the departments into two backlog lists. Group them in a way so that the dept. that are most related to each other are bunched up. So now you have 2 backlogs.
3- POs will then re-prioritize based on what is best for the business as one entity and not on what is best for the department.
4- Divide the team. 2 devs and 2.5 devs, each will take care of one backlog.
5- If the two teams need to still know what the others do, apply scrum or scrums.
Just by doing that, you will improve the quality because devs will have a smaller scope to focus on.
Showing posts with label backlog. Show all posts
Showing posts with label backlog. Show all posts
Friday, September 23, 2011
Saturday, August 21, 2010
How Scrum handles the case when you have 1 scrum master and 1 product owner and 3 teams working in the same product? each team consists of 6 members.
To Answer this question for simplicity, I will assume that we all know how "scrum" in a single team works, and I will assume we will have two teams of 6 rather than 3 to simplify my explanation. This same approach will apply to any number of teams (Proof by induction Anyone? :) )
* In my opinion, a rule of thumb is to make sure that no scrum team is larger than 6 +/- So If you have multiple teams that can be combined into one team of 6 +/- 1, then I would make it one team. Otherwise I would apply "Scrum of Scrums".
* In "Scrum of Scrums", each scrum team has one representative who is most knowledgeable in what everyone is doing in the scrum team.
* The Product Owner will have to have setup two backlog list for the different scrum teams. ( if not, then go based on Epics/themes)
* Each team will have its own iteration planning with the Product Owner going through the remaining items in the backlog list in priority. (so the meeting times need to be adjusted accordingly).
* After the iteration planning, the representatives will have a secondary iteration planing (much shorter) answering the following:
(1)"what we will be working on",
(2)"Any Issues we foresee in our way", and finally
(3)"How do you foresee that our changes will impact you?".
This way each team will know what the other team is working on.
* Daily, each team will have its own stand up meeting. Usually in a stand-up each individual will state
(1)"what I have worked on",
(2)"what I will be working on",
(3)"Any Issues in my way".
* Daily, after both stand ups for each scrum team, the representatives will have a "Scrum of Scrums" stand up meeting. The value I will focus on in this stand up is the "Impact" of a change. The biggest hurdle you will have in a team working on a single product will be the impact of one team making changes that will affect another. In the "Scrum of Scrums" stand-up, there is a bit of a twist to those three questions and a fourth; and they would be
(1)"what have WE worked on",
(2)"what WE will be working on",
(3)"Any Issues in OUR way", and finally
(4)"How will our changes impact you".
The last question will drive the conversation between the representatives on how the changes will affect each other.
* In my opinion, a rule of thumb is to make sure that no scrum team is larger than 6 +/- So If you have multiple teams that can be combined into one team of 6 +/- 1, then I would make it one team. Otherwise I would apply "Scrum of Scrums".
* In "Scrum of Scrums", each scrum team has one representative who is most knowledgeable in what everyone is doing in the scrum team.
* The Product Owner will have to have setup two backlog list for the different scrum teams. ( if not, then go based on Epics/themes)
* Each team will have its own iteration planning with the Product Owner going through the remaining items in the backlog list in priority. (so the meeting times need to be adjusted accordingly).
* After the iteration planning, the representatives will have a secondary iteration planing (much shorter) answering the following:
(1)"what we will be working on",
(2)"Any Issues we foresee in our way", and finally
(3)"How do you foresee that our changes will impact you?".
This way each team will know what the other team is working on.
* Daily, each team will have its own stand up meeting. Usually in a stand-up each individual will state
(1)"what I have worked on",
(2)"what I will be working on",
(3)"Any Issues in my way".
* Daily, after both stand ups for each scrum team, the representatives will have a "Scrum of Scrums" stand up meeting. The value I will focus on in this stand up is the "Impact" of a change. The biggest hurdle you will have in a team working on a single product will be the impact of one team making changes that will affect another. In the "Scrum of Scrums" stand-up, there is a bit of a twist to those three questions and a fourth; and they would be
(1)"what have WE worked on",
(2)"what WE will be working on",
(3)"Any Issues in OUR way", and finally
(4)"How will our changes impact you".
The last question will drive the conversation between the representatives on how the changes will affect each other.
Subscribe to:
Posts (Atom)