21319Re: [scrumdevelopment] Re: Self organization. How?
- May 2, 2007
The topic addressed (#1) was whether experience influences the process of self-organization, but perhaps the most interesting (and real) topic behind the question is how experience influences the group's work output.
With scrum it is all about the team. Group processes are paramount. But as dev teams go, work experience is essential for good work output, IMHO. In some cases perhaps the work output of a trained yet inexperienced well-formed dev team may output similar work output of another very experienced but ill-formed dev team. But this is just speculation - I don't have any specific data in this regard.
Fortunately, facilitating self-organization in principle falls into the same topic mulled over in countless times past, which I've observed touched on somewhat in the scrum master training I attended (kudos to Ken and Mike).
So I think there are three concurrent processes involved in bringing scrum into the organization a scrum master must deal with.
1. The dev team achieving competence in and a paradigm shift of how to do software the scrum way (methods) - this includes the SM (key here being paradigm shift).
2. The dev team's process of self-organizing (the criticality of team formation is punctuated in scrum over traditional I think).
3. Fitting a square scrum team and project into an organization's round hole (no hidden puns intended).
At least this is what I'm dealing with.
Mark----- Original Message -----From: Mark GraybillSent: Wednesday, May 02, 2007 8:59 AMSubject: Re: [scrumdevelopment] Re: Self organization. How?
1: Yes with caveats.
2: Suffering in this regard is ubiquitous, but examine why do scrum?
1: Caveats: You need to understand what sort of influence and how you are using the answer, but also all the other individual and group variables involved. Work and life experience (or lack thereof) for one individual can not only equip them or cripple them in the self-organizing process, but it also can catalyze or hinder how others participate.
We all suffer from the desire to neatly package things into something simple and generalized; unfortunately reality is often too complicated for our packaging needs. The endeavor of packaging people is perhaps one of the most common examples of such a dilemma.
There are so many variables behind each individual that can influence their participation in the self-organizing process to isolate just one of them (such as experience level) for a generalized conclusion, although there may be those experienced with teams who might disagree. My question to them is how well have they detected and minimized their biases and the influence of their biases on their conclusions, because the global literature related to this topic says otherwise. But mostly, few are trained on and aware of all the involved variables.
I'm not trying to pick on anyone but to prove a point. Team members can be all experienced or all inexperienced - or some mix, but their individual make-ups impose the most significant factor that can contribute or detract from the process of self-organization. I know what you're thinking - you dont want to hear that - management wants cookie-cutter and operationalized ways to control their world and this just throws a monkey wrench into their tidy managerial cogs. However, there is some hope in the fact there can be group variables that can have an overriding effect, such as good leadership, bad leadership or no leadership (to over-generalize) , that can be capitalized on.
2: Such is my lot in life at present. The two world views can be so incompatible, and though you might have some success with an analogy (e.g. control a team of English majors to write the next best selling novel), the fact remains those in upper management often do not understand the essence of software development and the essence of people as operating in their world. If they did, a paradigm shift would be much easier for them.
I've found two things certain: I must buffer the incompatible agendas and formats, and I must convince upper management to trust me. Just as a scrum master (project manager, team lead, whatever) must learn how to trust their team to make mistakes and expect mistakes in the process of them coming together, I think we have to convince upper management to trust us.
So there's my two cents worth. :)
Mark----- Original Message -----From: Peter HundermarkSent: Wednesday, May 02, 2007 5:17 AMSubject: [scrumdevelopment] Re: Self organization. How?
--- In scrumdevelopment@ yahoogroups. com, Nicholas Cancelliere
<nickaustin74@ ...> wrote:
> What makes senior developers any more effective at self-
This question is troubling me too. We have been using Scrum for a few
months now and senior management continues not to trust teams to self-
organise. Perhaps more accurately they do not trust that the delivery
of a self-organised team is optimised.
So I hear statements like: "If I created a team comprising only
experienced people, they would self-organise to do the work
efficiently, but I don't think an inexperienced (or mixed) team can
do this. We must retain a Project Leader role [within the team] who
will tell the team what to do when they fail to self-organise. " Even
good PO's appear to be be frustrated by their inability to direct the
team [via a single point of contact - the PL]. The SM is seen as a
feminine/motherhood role lacking in 'fatherly' qualities.
Ken [Schwaber] often says you can take a cr*p team and in a month
they'll deliver you cr*p (my paraphrase), but this does not directly
address the perceived leadership vacuum propagated by Scrum.
So my questions are (I think):
1. Does work (and life) experience influence a team's ability to self-
2. How does one accommodate an organisation' s anxiety about the
perceived loss of control that Scrum brings about.
- << Previous post in topic Next post in topic >>