Frankly, a good way to couteract inappropriate documentation is to price each deliverable, and require that it not add more than n% to the overhead cost of a project. Of course, we need some kind of standard for reasonable percentages for overhead costs. I have to admit that I have not seen any analyses of cuch things.

Hank Mayers

This is a common problem we PM’s face.

I second Greg in saying PUSH BACK….don’t be afraid to ask the PMO if you can remove a doc from the backpack….tell them why….and as long as it isn’t a compliancy doc – they usually say ‘ok’.

I’d add a 3rd option: Only fillout parts of docs that apply to your project. just say “not applicable” or write the absolutely “what is needed”. Don’t write a disseration. Write for your audience – which is typically auditors.

Donna Reed
The Agilista PM
PMI Agile Community of Practice Rep

If a company is going to adopt Agile as a whole – I absolutely agree that a “core team” approach is the way to go. Leveraging a “coach” that can mentor you through the process, modeling how it should work. What better way to learn than get dirty and starting “doing it yourself”.

I especially like the Socratic approach you mention of discussing and debating along the way for teams and the company to “truly engaged” in the education process you describe in your book. Especially when make sure the core team is made up of people like your own company – then the discussions and debates will be “real to your own company” & possibly help the adoption by the more difficult non-collaborative types. I have found that when I involve the people that fight you the most in the process, making them part of the solution – then they help promote the improvements that Agile can bring much easier. You might have some heated discussions, but if you work through it – the end results are amazing.

So if an “Agile coach” is critical to this working – how do you suggest those companies that want to move to an Agile model find a “good” coach – one that can help them onsite and even remotely after you get going?

Your book goes into this in more detail – so I highly recommend it to people investigating Agile.

DONNA REED
PMI Agile Community of Practice Rep for So. Calif
MY BLOG: http://www.DonnaAReed.com
EMAIL: donna@DonnaAReed.com

The biggest problem was that the other sub teams scapegoat’ed the yellow sub team.

A lot of people came to me, complaining about the yellow team or complaining about team members but never talked about these issues in person.

I assembled everyone in a meeting room and told them I did not like that.

I told them that people came to me instead of talking to eachother.

And I wanted to them to bring it out on the table. I asked them to stay polite and to talk about the things they did not like, not about the persons.

And when someone talked about them not to take it personally.

When they talked about a persons that was not there. (Old team members) I asked them to concentrate on the persons who where present.

When they talked about a person present. I aksed them to talk directly to them.

(Not: I don’t like what Joppe did. But: Joppe, I don’t like it when you did this.)

During this first hour a lot of frustration was broughed up.

Surprisingly a lot was about project management.
There was some reorganisation a few months ago.
Let me state what I understand happened.

* The person that had my place before, asked the team to come up with idea’s for the reorg.
* That did not work out completely. è they did not have a solution
* After a while he and his/my boss took a decision

Basically the team was not ready to be a self-organizing team. Because the boss did take a decision they were even less a self-organising team afterwards.

And a week or so later while the boss was on Holiday One person created his own team. Both changes created frustration.

The persons that created his own teamtold the team during the meeting it was The boss idea. The boss was not present but told me afterwards that that was a lie.

Some more frustration was vented about stuff in the team.

So I then asked them split up for 30 minutes in groups of 4 people.

At least people from 2 of the sub teams, if possible from 3 or 4 teams.

We came back to another meeting room 30 minutes later.

Before everyone was there my boss & me did some explaination about scrum and agile as an answer to some questions.

(I also pointed them to a presentation that we cancelled that same day because of these problems.)

They did not have much answers except that we had to dismantle the yellow team.

Something I agreed to because I wanted to protect the Yellow team members from being burned completely. (They also started to have a reputation outside our team)

Nobody had an idea how to do it. Actually they wanted me and my boss to recreate new teams.

I did not wanted to do that as they had just said in the previous meeting they did not like the boss taking these decisions.

Then I heard myself saying: I have a scary and crazy idea.

I’m not sure if it is going to work, but I have something I would like you to try to create new teams.

We will rearrange the room. Move the tables to the side.

The next 20 minutes I want you to move around in the room to group yourself in 3 groups.

You move around until you think that the new division is the way you currently think our team should work.

A discussion started about what should be the rules for this division. I stopped the discussion and I said that it was impossible to have an agreement for these rules. It was much better that people moved around until they felt happy about the result. I asked them to really focus on their gut feeling.

The idea behind it is that your body knows these things a lot earlier then your brain does. (Not sure how I explained this).

And before we started I added one more constraint: they were not allowed to talk during these 20 minutes.

They started of very slow. I could not really see groups it was more like lines. So I asked to from really circles.

Then the movement really started.

After about 10 minutes the movement was over.

So I asked them, are we happy with this. (I felt they were not)

One person told me he was not but he could not change it. I told him he could move and maybe other people would also move around

I told them to move again.

Not much happened.

After a while I asked the question again.

The same person said; I’m still unhappy but I cant help it

I told him he could move 1 person by taking his shoulders and move him. He moved one person. I thoughed he did not put him to one team. My boss thinks he did. A lot of movement after that. (People left the new team of the moved person.) After a while we had almost the same teams as before the change.

We talked again.

Someone said that for him the biggest problem was that 4 or 5 core member of the Yellow team were back together.

So the original problem stayed.

It was kind of hard for the yellow team, which I found not fair as everyone moved, so it was not just these members who where responsible. Which I said.

I had the feeling they would get out of it. (I don’t think I had another solution ) so I told them we would try again and everyone could think about that constraint.

I also told them that my boss and I could come up with a solution but that it would be always less then the solution they would come up with.

I told them that because some people already said why don’t you decide. I did not want to decide as they just complained in the previous meeting that they did not wanted us to do that. So I told them that I refused that.

I told them that the IQ of 40 people was way higher then mine or my boss. We first had a small toilet break, where they could talk.

(5 minutes became 10)

And then we redid a walking around.

And sometimes later we ended up with 3 teams.
In total it took them between 90 and 120 minutes.

They still had a small discussion about the fact that one of the teams had no French persons. (Which was one of the rules they tried to create befor ethye started to move around) and actually other team members said this was not suc a big deal as the two other teams had all languages.

The creation of the team was a compromise. A compromise created by the team.

Unfortunately 3 people were not present.

The energy level the next day was incredible.

A lot more people do take responsibility.

For me it was the start of the self-organizing of the team.

The next day I also heard that the story was already told all around the post and that I’m starting to become famous. Not sure if that was good or bad.

Personally achieving this was one of the highlights of my life.

A few years ago a small government department came to me with an interesting problem. They needed a new core system and the project absolutely had to be an outstanding success. They had tried to build this system twice before and failed, but this time the very existence of the department hinged on being able to create this new system.

The key to solving this problem was of course to control risk, and to this end I recommended that we develop the system using extreme-programming (XP). XP insists that we deliver something of value to the business every two weeks — in this project that meant that two-week’s work was the most that could be lost if something went horribly wrong. Management really liked the idea of frequently and incrementally delivering value, and it was easy to explain to them (thanks to the brilliant work of Kent Beck who explained it so well to me).

Once they understood XP, the management team really bought into the concepts behind the agile approach to software development, and understood that ultimately people are responsible for delivering systems. They realised that the environment in which they put the development team would greatly affect their ability to deliver the system. So, they asked me to design the ‘perfect’ software development lab. The question caught me off guard, so I sketched out a design on a whiteboard. They liked it so much they invested about $100k building it.

They pulled down a couple of walls to enlarge a space on the top floor with a nice view of wooded hill. They had a round table built, with space for five pairs of developers each with two large screens. They built a long ‘war’ table, put in variable halogen lighting, smart whiteboards, a couple of projectors, and bought Herman Miller Aeron chairs. The breakout area had nice red-leather couches and a good coffee machine. Around the edges of the room were workstations for peripheral staff.

Once the lab was ready our attention turned to selecting ‘users’ to work with the development team providing stories and expert business knowledge. We brought in the assistant heads of each of the five business units in the department to work with us full time as the ‘user’ group. These brilliant people were 100% behind us and were constantly pushing us onwards. They took each iteration’s release back to their departments to socialise, so that as the releases rolled out, nobody was surprised by their content. This also gave a chance for the lower-ranking staff to have input into the process.

We had at our disposal the entire organisation and its staff. We could walk the floors and talk to anyone we liked. We regularly had open discussions on the direction the development was going and we would always be happy to have visitors to the war-room coming up to tell us about how they were using a new feature in an unexpected way, or how they’d find something really useful if only it worked in a certain way.

Combining the business knowledge of the user group mixed with the development team allowed us to synthesize a new way of achieving the department’s underlying mission. The approach is radical and has attracted academic interest from around the world.

The commitment to the human side of the project paid off handsomely. The project was a huge success and made the front page of the local computer press three times. The system we built is still being examined by experts the world over for it’s innovative solutions. And, the strength of the system can be seen in the fact that it can be used in domains other than the one for which it was originally intended.

The tools we used were the right tools for the job. More important however were our processes, which helped us actively reduce risks and constantly maintain visible progress which in turn helped safeguard the future of the organisation. Our process also helped us see clearly to the heart of the problem — people were our strength and only through them could we become successful.

People over process over tools!

Bryan
1