We don t have a PO yet, it s our major issue. We have interested parties, but no one willing and able to do the full PO role. I am the scrum master, a noviceMessage 1 of 2 , Mar 23, 2012View SourceWe don't have a PO yet, it's our major issue. We have interested parties, but no one willing and able to do the full PO role. I am the scrum master, a novice one.The team has a lot of autonomy, there isn't much command and control history here. The team has had a lot of freedom and latitude. We are hoping scrum will tie to getting user visible features done and avoid endless technology development.
Thanks for the book recommendations. We are probably right between forming and storming!-Philip
On Fri, Mar 23, 2012 at 1:13 PM, James Holbrook <james.holbrook1@...> wrote:
I also live in Winchester.
People by nature do not like change, chaos or giving up control.
My questions to you is Has a Product Owner been Identified? Has a scrum master been identified?
If not these rolls have not been identified and given authority you will stay in the command and control model.
Here is some team forming stages as described by Bruce Tuckman see below.
• Bruce Tuckman developed a 5-stage model of team development.
• 1. Forming: The group comes together and gets to initially know one other and form as a group.
• 2. Storming: A chaotic vying for leadership and tailoring of group processes
• 3. Norming: Eventually agreement is reached on how the group operates (norming)
• 4. Performing: The group practices its craft and becomes effective in meeting its objectives.
• 5. Adjourning: The process of "un-forming" the group, that is, letting go of the group structure and moving on.
Some more good books are Agile Project Management with scrum by Ken Schwaber, Collaboration Explained by Jean Tabaka, and Coaching Agile Teams by Lyssa Adkins.
Keep questioning and be a good Agile evangelist.
Maybe a face to face support group might help.
James Holbrook, CSM
Just signed up to the list. My name is Philip Winston I live in Winchester, VA about a hour west of Washington DC. I'm on a 5 person distributed team trying to implement scrum. We are in the 3d graphics / military simulation space. We are on an existing project which has been around for a number of years. For several years it was not agile at all, in the last year they instituted some elements of scrum and it was marginally successful. I joined this year and we're trying to do scrum "for real" now for a number of reasons.
I personally am new to scrum. I've read some books and attended a one day course by Clinton Keith at GDC a few weeks ago. But other than that I am green.
I have a question. For our first sprint planning meeting we kind of went around the room and each developer identified high priority tasks they could productively work on. As in, developer A is mainly the Foo System person, so he picks off 10 days worth a Foo System tasks. Now developer B is the Bar System guy, so we find 10 days worth of Bar System tasks.
This seemed wrong, it didn't feel like we ever really had a sprint goal as a team, instead we were just loading up individuals with their own individual tasks. With this method I feel like the team velocity isn't going to be that important. Instead what we are likely to do is look at individual velocities, because that would guide us during the next round of planning. If developer A averages 8 estimated days of work during the 10 day sprint, then load up 8 estimated days . If developer B averages only 4 estimated days, no problem, give him 4 estimated days. To each his own, just schedule everyone separately.
My question is, is this individualized planning wrong? If so how can we avoid it, given that developers really do have areas of expertise / specialization.