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.
Saturday, August 21, 2010
Has anyone used Agile for ERP type projects or with large projects? Any suggestion or inputs are welcome
Yes it can be done. Some pointers (there can be much more)
* You are bound by requirements, audit policies, company policies info, ... etc. so each iteration will need to accommodate for such information. so your estimates need to account for all that are to be done.
* communications. not to enforce it, but rather to facilitate it. If you need to move people to improve this, then do so. if you want a collaboration tool, then get it ( you can use something like SharePoint or Microsoft Access ... etc) . I have dedicated the stand up room to be a place where people will go and talk out solutions to problems.
* stand up, and story board. I cannot stress how valuable these were. anyone lost is back on track just by being in a stand up facing a story board.
* If you have a large team, then apply the "scrum of scrums" concept. keep each scrum team no more than 5 or 6 members. The more people you have, the less communication.
* teach members about scrum.
* keep iterations short. and make it a policy to be ready for live at the end of it.
* focus on quality. this means include unit testing, automated testing, test scripts, manual testing, code review, test script review... etc.
* Last but not least; have a retrospective meeting at the end of each iteration; this will allow the team to reflect back on the it.
* You are bound by requirements, audit policies, company policies info, ... etc. so each iteration will need to accommodate for such information. so your estimates need to account for all that are to be done.
* communications. not to enforce it, but rather to facilitate it. If you need to move people to improve this, then do so. if you want a collaboration tool, then get it ( you can use something like SharePoint or Microsoft Access ... etc) . I have dedicated the stand up room to be a place where people will go and talk out solutions to problems.
* stand up, and story board. I cannot stress how valuable these were. anyone lost is back on track just by being in a stand up facing a story board.
* If you have a large team, then apply the "scrum of scrums" concept. keep each scrum team no more than 5 or 6 members. The more people you have, the less communication.
* teach members about scrum.
* keep iterations short. and make it a policy to be ready for live at the end of it.
* focus on quality. this means include unit testing, automated testing, test scripts, manual testing, code review, test script review... etc.
* Last but not least; have a retrospective meeting at the end of each iteration; this will allow the team to reflect back on the it.
Tension within the team. Does anyone have any recommendations on how to handle personal tensions within a team?
A ScrumMaster (SM) is a facilitator and an example for a scrum team. Based on this premise, below are some ideas that might help.
1- If people in the group are in disagreement/tension, then let them work it out.
2- If they are not working it out, then create the right environment to work it out. have the stand-up room available for people to talk things through. If they want more privacy, then they close the door and talk it out.
3- If there is still an issue, then be the mediator. The SM's job is to "clear hurdles" for individuals in a scrum team, not just watch them deal with it. To clear this hurdle, you have to act as a mediator. No need to bring a third party unless you as the SM are in tension with others (but as an SM, I would really hope not). In my opinion, the more people you involve in a tense situation, the more complicated it will be and harder to resolve.
4- Be an example to everyone. As painful as it seems, be the most patient person ever when dealing with such a problem.
5- The best way to avoid tension is to anticipate it. And how do you anticipate it? By getting feedback from the team. I am THE BIGGEST FAN of the retrospective meeting. This 45 min every iteration meeting is a key to relief people stresses in future iterations. Less stresses for individuals in a team will make them happier in the team which makes them more patient and thus less tension. Of course, as a SM I would expect you to follow through in making and/or allowing the proper changes based on the retrospective.
6- Smile, and crack a jock every once in a while (even if you are bad at it), people who are more skilled at jokes will get the courage to do so later on.
1, 2, 3 are for specific individuals in disagreement
4, 5, 6, are for the team and future "way" to reduce tension in general
In regards to the original question, to reduce tension in the team as a whole, I would start off with the retrospective. To reduce tension between specific individuals in the team, then I would apply 1, 2, then 3
1- If people in the group are in disagreement/tension, then let them work it out.
2- If they are not working it out, then create the right environment to work it out. have the stand-up room available for people to talk things through. If they want more privacy, then they close the door and talk it out.
3- If there is still an issue, then be the mediator. The SM's job is to "clear hurdles" for individuals in a scrum team, not just watch them deal with it. To clear this hurdle, you have to act as a mediator. No need to bring a third party unless you as the SM are in tension with others (but as an SM, I would really hope not). In my opinion, the more people you involve in a tense situation, the more complicated it will be and harder to resolve.
4- Be an example to everyone. As painful as it seems, be the most patient person ever when dealing with such a problem.
5- The best way to avoid tension is to anticipate it. And how do you anticipate it? By getting feedback from the team. I am THE BIGGEST FAN of the retrospective meeting. This 45 min every iteration meeting is a key to relief people stresses in future iterations. Less stresses for individuals in a team will make them happier in the team which makes them more patient and thus less tension. Of course, as a SM I would expect you to follow through in making and/or allowing the proper changes based on the retrospective.
6- Smile, and crack a jock every once in a while (even if you are bad at it), people who are more skilled at jokes will get the courage to do so later on.
1, 2, 3 are for specific individuals in disagreement
4, 5, 6, are for the team and future "way" to reduce tension in general
In regards to the original question, to reduce tension in the team as a whole, I would start off with the retrospective. To reduce tension between specific individuals in the team, then I would apply 1, 2, then 3
Subscribe to:
Posts (Atom)