Re: [scrumdevelopment] Command and control to start
- -----BEGIN PGP SIGNED MESSAGE-----
Cory Foy wrote:
| Joakim Karlsson wrote:
|> On Sat, Aug 2, 2008 at 10:00 PM, Alan Dayley <alandd@...>
|>> The more I write and think about this, the more I think retrospectives
|>> are the next thing to introduce.
|> I agree. I might even go as far as to say that retrospectives is the
|> practice to start with if you don't take the big bang approach.
| That's what I did. Second day on the job. It was vital for baselining
| what the heck was going on:
| It paid off tremendously, because the team immediately realized that
| things weren't as they thought. /Everyone/ learned something in that
| meeting. And I was able to pull it off in about 3 hours.
I ran into an unexpected and strong resistance to a 1 hour meeting
introducing the framework last week. I still have strong resistance to
even the < 15 minute daily team meeting and statements that "I already
know how to do the work. I don't need training." A 1 hour meeting of
any kind is difficult to schedule, even if the end result would be a
It is an impediment of surprisingly large proportions, discovered when
attempting the above mentioned intro meeting. This is the main reason I
have not yet pushed a retrospective.
Management wants Scrum. The team wants results and if Scrum gets them
there, that's fine with them. But, none of them "get it" yet and change
is hard. The only other two people that "get it" in the company are the
executive sponsor and one other new CSM who is currently doing a project
of one person, himself.
I must say, this has been a very interesting process of "people
watching" so far. It's amazing to see the team, and myself, go through
this process. Proof that Scrum is about people, not technology!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
- Not sure if this will help but I have often found that people are
less than enthusiastic about changing the way they work using an
approach suggested by someone else - whether it be Scrum or any other
In all circumstances I have tried to identify that person's goals -
what they are truly trying to acheive in thier work, and what
motivates them - and then help them to see how the new working
practices can help them acheive those goals. If I can do this (and it
is often difficult), then it always helps.
--- In firstname.lastname@example.org, Alan Dayley <alandd@...>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Writing about this topic in my Scrum adoption journal, I seem to
> arrived at a conclusion that should work for me. However, thegreat and
> MUCH more experienced minds here can help solidify my confidence.If I
> may indulge, let me describe my thought train.attempted to
> Our Scrum adoption is going slowly but positively. I have
> teach the team about Scrum and agile principles to allow them toselect
> which pieces they want to adopt as we go. This has worked well withour
> starting adoption of minimizing team effort interruptions andmeeting
> interruptions.anything more.
> But we have stopped adopting and the team has not asked for
> They only have a single, one-hour presentation on the Scrum
> and some written materials in their knowledge bank. I am confidentthat
> they either don't know what to ask for or don't see the practicalvalue
> of specific practices.in the
> We still very much have a Team Lead providing command and control
> most positive way possible. (Another place where a self-directedteam
> is not yet realized.) The Lead has stated two things the pushed meto
> my conclusion, paraphrasing: "We don't need training. We alreadyknow
> how to get the job done," and "Just tell us a practice to do andwe'll
> do it."the
> Overcoming the lack of desire to receive instruction is a slightly
> different topic that I'll choose to ignore at present. Focusing on
> second point, I did not want "command and control" the team in theirScrum in
> adoption of Scrum.
> Then I remembered an question and answer exchange during ScrumMaster
> training. The question was "What is the usual way to introduce
> an organization?" Trainer Michael described a two-day kick offgoing
> through introduction, exercises, creating a real backlog, sprintlearning a
> planning and go.
> And it hit me. The described introduction process is "command and
> control," of a sort. And that makes sense to me now. When
> new technique, the student must be told what to do and the reallearning
> is in the doing. Especially when learning Scrum, the learning, andpick
> proving value, is definitely in the doing.
> I know, based on team desires and management reluctance to surrender
> time for training, a multi-hour "immersion" or an attempt to change
> everything all at once will not work in my situation. But, I think,
> based on the Team Lead's desire to be told and an initial
> "teacher/student" relationship, it safe for me as ScrumMaster to
> practices that the team can learn by doing. Command in the most
> self-directed team manner possible.
> Any thoughts or insights for me about my thinking here?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----