« February 2007 | Main | April 2007 »
March 27, 2007
Resistance and Perception
From George Dinwiddie (interesting blog, BTW) on the ScrumDevelopment list comes this great article: Resistance as a Resource by Dale H. Emery.
From the article:
You gather your courage, call people together, and make your proposal. From your right, Charlie says, "But we tried that before, and it didn't work." To your left, Pam says, "But we've never done that before." Right in front of you, Lee says, "But that's no different form what we're doing now." From the back of the room, you hear a rising chorus of, "But we don't have time!"You don't really have to imagine this scene, do you? You've lived it. Perhaps you're living it right now. You're getting resistance. Now what do you do?
Posted by Mishkin Berteig at 03:56 AM | |
March 25, 2007
Factual Errors - And an Interesting Scrum Criticism
An interesting article called Credibility Crisis is worth while reading. I would like to point out two factual errors. Despite the errors, the author's concerns are well-taken. Here are the errors:
1) The average price per CSM is much less than US$1500. Your "conservative estimate" is not conservative at all. For quite some time, the average was less than $1000 in fact. As a scrum trainer, I know that the people that I have certified have averaged about US$750. I suspect this is true for most of the trainers, and it accounts for volume discounts when doing training in a corporate setting, doing pro-bono training, doing training in countries with lower costs and training that is done by CSTs that are employees of large companies such as Microsoft and British Telecom where the "industry" sees no revenue.
2) "Well planned marketing" Ha!!! That's a good one! There has been exactly one advertisement issued by the ScrumAlliance (in Dr. Dobbs Journal), and all other advertising and promotion is done hodge-podge by the individual CSTs or the companies they work for. The only coordination point is the web site where all the CSTs are required to list their public courses. Ken Schwaber and Mike Cohn, as the most well-read authors in the Scrum community get a large bulk of the _interest_ in the training (I'm not sure what their actual numbers are for # of CSMs).
Those two errors undermine the author's argument in the article, but don't completely invalidate it.
Posted by Mishkin Berteig at 05:52 PM | |
March 22, 2007
Agile Job Web Site
It's new! It's exciting! It's the new Agile Job Finder web site! Search for agile jobs, register and post your jobs! Fun for everyone!
Posted by Mishkin Berteig at 11:00 PM | |
March 10, 2007
Pay and Performance
Jeffrey Pfeffer Testifies to Congress About Evidence-Based Practices. Here's a good couple excerpts (thanks Esther!):
"The idea that financial incentives are the way to solve organizational
performance and service problems is one of the most dangerous "half-truths"
of management. The evidence for widespread dissatisfaction with such pay
plans is pervasive. Both employee and company survey data suggest that the
likelihood of success is low and the odds of problems and dissatisfaction
are high.""Although the list of high commitment or high performance work practices
differs slightly among authors and studies, most such lists include: a)
sustained investment in training and development, including job rotation,
both formal and on-the-job training, and a tendency to promote from within
as a consequence of the successful internal development of skill and people;
b) an egalitarian culture in which formal status distinctions are
downplayed, salary differences across levels are less than in the general
economy, and in which people feel as if their contributions are important
and valued; c) delegation of decision making responsibility so that skilled
and developed people can actually use their gifts and skills to make real
decisions; d) high pay to reduce turnover and attract the best people,
coupled with rewards that share organizational success with its members; and
e) employment security and a policy of mutual commitment, so that the
workforce does not fear for the outcomes of events over which it has no
control and instead, feels reciprocally committed to the employer."
Posted by Mishkin Berteig at 12:04 PM | |
March 06, 2007
Agile Blog Started
A new blog has been started called "Agile & Business" by agile coach Joe Little. I have worked with Joe and I believe that he has excellent insight into human nature and the application of agile methods. The first few articles he has written are an excellent starting point including a look at metaphors we use in Scrum (chickens, pigs and dogs), and a look at the idea of business value.
Posted by Mishkin Berteig at 10:25 PM | |
March 05, 2007
A Better Iteration Structure
In my coaching work, I have often been asked a question about the planning process for iterations, that until just a few days ago, I would actually brush off!!! I didn't even realize I was doing this, it is only in retrospect that I see this. This question is simple: "how does a team plan for the improvement efforts that come out of the retrospective when they are supposed to be working at maximum velocity when implementing tasks directly related to the items in the work queue?" Or, more simply, "we don't have time for process improvements."
The source of the problem shows up in the normal* structure of an iteration. This structure is as follows:
Step 1: set a goal by selecting work from the top of the work queue.
Step 2: plan the execution of that work by doing a task breakdown and task-level estimation.
Step 3: do the work according to the tasks (this is the bulk of the time in the iteration).
Step 4: do a demo to review the work - use this demo to adjust the work queue if necessary.
Step 5: do a retrospective to review the "how" and come up with action items to make the work more effective next iteration.
Since iterations follow one after another, this structure when rolled up can be re-written in the following manner:
Action (step 3)
Reflection, Learning (step 4)
Reflection, Learning, Planning (step 5)
Planning (step 1 and 2)
Now if we look at the purpose of the steps in comparison to the type of learning activity taking place, we see that there is a big disconnect between the planning that happens in step 5 (the retrospective) and the planning that happens in steps 1 and 2 at the start of the next iteration. Not only that, but reflection and learning are separated into "what" and "how" so are done twice for each iteration.
Frankly, this causes a lot of confusion: I see it in my coaching when teams try to accommodate the two types of planning, and I see it in my training when I teach the structure of the iteration.
So what is to be done? Simplify the structure of the iteration. Instead of thinking of the iteration as a linear block of time that starts with step 1 and ends with step 5, think of it as a cycle that is dominated by Action, and punctuated regularly by Reflection, Learning and Planning. Now, instead of four separate meetings, there is a single meeting every iteration that combines the wrap-up of the previous iteration with the start of the next. Let's call this the Iteration Transition Meeting or the RLP Meeting or the Adapt Meeting... (suggestions welcome!)
The agenda for this meeting is very simple and contains the essential elements that exist in the "old" style. It starts with Reflection where the facts of the Action are examined: what did we build? how did we build it? how did we feel about what we built? etc. This moves fairly quickly to the Learning component where we try to understand what the facts are telling us: what went well? what needs improvement? what insights can we glean? what new questions are open to us? and of course, what did we learn? Now we are prepared to treat Planning holistically, with no "hidden" activities. We examine our Work Queue, re-arrange it, put new items on it, etc. and do our normal task breakdown and estimation. The difference this time is that both direct business tasks and process improvement tasks are included in the same planning activity. This makes task level (commitment) velocity more truthful!
I will admit that this is not something that I have tried yet. I have seen it done accidentally when people start to ignore the action items from the retrospective in the old iteration structure and instead include them in the task planning. When it happened, I thought it was "messy" because it broke the separation between "what" and "how" oriented activities. Now I think that this might be the best way to do things.
Anyone out there willing to give this a try? If so, I would love to spend some time with you working on it - helping, experimenting, and learning from it.
I should mention a couple important points that didn't fit in the above narrative. First, this insight happened as a result of discussions over the past week with my father, Garry Berteig who is using agile methods and the learning circle in his classroom environment. Second, Garry has been doing what I just described in his classroom environment; the main difference is that Garry provides a great deal of the Planning to his students by way of the progression of assignments/activities.
One other cool thing: I'm in Frankfurt as I write this on my way to Chennai to deliver a three-day Agile Project Management / ScrumMaster Certification course. I haven't done international travel since I went to Beijing last summer, and this is the first time I am going outside of North America for work! Fun!
* Normal here means Scrum and XP for the most part. Lean doesn't have this structure and as for other agile methods, I don't know them well enough to say if this is normal or not.
Posted by Mishkin Berteig at 04:16 AM | |
March 02, 2007
Travel and Trust
I don't usually talk too much about personal stories here - I try focus on agile methods pretty directly. However, the last two days have been interesting enough that I want to share them, and a lesson from the experience.
About six weeks ago, I started making arrangements to do an in-house ScrumMaster Certification course for a good client of mine. These types of courses are always interesting because it is possible to go into the details relating to a specific organization. As well, because I have worked with these people before, I knew that they would have great, challenging questions.
I was supposed to depart yesterday on a short flight to get to their location. The weather forecast included a substantial snow storm for the day. I decided to make a change to my booking to go on an earlier flight in the hopes that I would get out before the storm. Unfortunately, about 30 minutes before I was to get into a taxi, the airline called to say that the flight was canceled and that I was re-booked on a flight for this morning. Since my course was to start this morning quite early, this was a bit of a problem.
I called my airline and found an alternative flight that would leave late in the afternoon (yesterday), get to an airport about 90 minutes drive from my client, and which was not canceled or delayed. I hopped in a taxi, got to the airport, checked in, went through customs (Canada to the US), went through security, hung out in the frequent flyer lounge, took the shuttle to the terminal, waited about five minutes and then found out that this flight, and all others for the rest of the day were canceled. (I then had to find my way back home which was extremely difficult with all the cancellations; getting a taxi was a two hour wait, so I decided to take public transit. The cost of getting to the airport was 40 minutes and 80 dollars. The cost of getting home was 240 minutes and 3 dollars!)
I called my client to let them know that I would have to arrive in the morning on the original re-booked flight. If I was lucky, I would end up at my client's site around 9:30am and be able to get the class started before 10am.
My flight this morning was scheduled to depart at 6:20am. Since I am a fair distance from the airport, this meant leaving my house at 4:20am and waking up at 3:55am (shower, brush teeth, dress, check email); thankfully, I didn't have to unpack/repack.
Before I left, I checked to see if the flight was still a "go" and it looked okay. I got to the airport to do my check-in. The automated check-in terminal told me to see an airline agent. Oh oh! I waited in line for 30 minutes only to find out that again my flight was canceled. The ticket agent was happy to try help out, but because of the weather (freezing rain), most other flights were also canceled and the earliest I might be able to get to my destination was about 3:30pm... if flights resumed in the afternoon. Definitely a problem!
I didn't put up a big fuss - no point really. So I made my way back home.
The end result: I called my client on the phone, explained the situation. He was quite understanding and we are going to re-schedule hopefully for later this month.
The lesson? He didn't have to be nice. He could have said something to the effect of "we had an agreement and you didn't deliver... it's all off, I'll find another vendor." And the fact is, he may still do that if we can't find a suitable date... but he's giving me the chance and that is important for both of us.
It builds trust, it is collaborative rather than contractual. And it's great that two people in two organizations who are doing agile are willing to put the principles into practice even outside of software development.
Posted by Mishkin Berteig at 02:58 PM | |