Before we get started, Dave Nicolette asked if I wouldn’t mind posting some of the discussion that came out of the interviewing talk. We had several people in an open space session discussing how they hire agile people. We all agreed that pair programming was an important part. It seemed like pretty much everyone had some sort of resume and phone screen, and then flew the people out. Thoughtworks puts their candidates through a logic test, and then pairs them in, while we do a short team interview and they spend basically the rest of the day pairing on production code, swapping across some of the teams.
We didn’t go very in-depth into things like benefits, compensation, etc, although I do find that a fascinating topic in the context of an agile team, and hope to talk more about that soon.
Now, on to the conference!
Today was the awaited Agile Leadership summit. It started out with an excellent talk by Tim Lister (of Peopleware fame) about the APLN’s Declaration of Interdependence (DoI). H took each of their points and “translated” them into what he thought it meant. Some key points that came out of it were:
- Don’t adopt techniques. Adapt them. That’s what you are paid to do
- Allow your team members to be leaders of their own domains
- Process is what you don’t do naturally
One thing I happened to notice was that in all the talk about agile organizations wanting to rely on teams instead of individuals, there was still talk of individuals, even in the DoI. Tim brought up the point that people don’t throw out wild ideas, they tend to bring 15 slide PowerPoints with the full solution in hand. I asked if perhaps that was because in our culture we don’t value people who are wrong, and in fact create a culture where people are afraid of the repercussions if they are wrong.
Tim’s talk was followed up by Jim Highsmith. He discussed some aspects of agile leadership. His main theme was that our current performance management systems are hurting agile teams, and that we must change that. He laid out several examples of systems in companies to do this, but perhaps the most interesting was Intel and their Business Value Maturity Model and 17 Standard Measures of Value. Seeing an organization respond to value as the primary goal of the business, rather than things like dates or lines of code, was very interesting.
He also was highly critical of the metric collection policies of many organizations. Metrics, he argued, should only be there to provide employees with self-assesment information to allow them to self-correct. It should also really only be there to give you the next set of questions to ask. So, if you are collecting metrics, ask yourself what the next set of questions you should be asking with those numbers are. If you don’t have any, the metrics may not be providing value for you.
I also loved the quote he put up, “Doubt is not a pleasant state, but certainty is a ridiculous one”. The best part was it tied into Mary Poppendieck’s presentation about the History of Lean that was next on the agenda. One of the comments she made was that standards are expected to be constantly changes, and if they have been around for a while, something is wrong.
In fact, Mary’s talk covered a lot of good points. She gave an introduction to the Lean movement, from interchangable parts on guns through the leader of the Totota Lexus division. Some key points there were:
- “If the learner hasn’t learned, the teacher hasn’t taught”
- Most variation is inherent in the system
- If you have requirements churn, you are specifying too early. If you have code-and-fix, you are testing too late
- 64% of features are never used
One other key point, and one I think our current team is lacking on, is that you can’t fix just a defect. You must take the time to fix the root cause too. I think too many times something caused the bug, and rather than take the time to find out why and correct it – which would make us much faster in the long run, we just correct the immediate problem and continue on. Hopefully we can improve in that aspect.
After Mary’s session, I walked over near OpenSpace and plopped down. Last night I had taken a look at RSpec after the OpenSpace talk on BDD with Dan North. I have to admit that I didn’t like it at first, so I ended up being up till about 3:30 am working on a YAML/DSL based solution that did what I wanted to do. So I decided to work some more on that, since I had already talked to David Chelimsky (he wrote RSpec), and he and I were going to get together later.
So, I decided to put up a sign saying that I wanted a pair on some Ruby code, and 3 people wandered over. Very sharp guys, and we ended up spending about an hour going through some different scenarios and playing with the code. It was great fun, and proof of how great the community is here.
I then wandered over to OpenSpace, where the FIT summit was going on. We all chatted for quite a while about the various problems we had been having, and it seems like they are going to be working to shore back up the FIT/Fitnesse split. A couple of us wandered to the Goooooooogle mixer, and then abot 15 people headed over to Rock Bottom for drinks and dinner. How can you pass up that opportunity, especially with some of the bright people who were there.
David and I then got the chance to sit down with the work I had done earlier, and we discussed what some of the future of RSpec is, and realized that the work I was doing could lead to some interesting things that aren’t the core of RSpec, but fit into the context. It was a great discussion, and I’ll definately be looking more at it (and posting some more on it as soon as I get some of it worked out).
It’s hard to believe tomorrow is already the last day of the conference. Time flies when you are with so many great people. See you tomorrow!
What did Tim Lister say in response to your question about our culture insisting that the first solution should be the perfect final solution?
I see this appearing on multiple layers in our team. Their definition of brainstorming is definitely not brainstorming. The phrase “write one to throw away” initiates what I can only translate as abhoration.
Well, I don’t think what I was referring to was the direction Tim was going with the talk, but I had a couple of people come up to me afterwards and say that they have worked in other cultures and the sense of fear we seem to have here in the states for piping up with ideas isn’t present there.
The problem I see is that for a lot of people it is so ingrained as part of their nature they don’t realize that when they shoot down ideas they possibly prevent further innovative ideas from that person. It’s the reason I take hundreds of photos – sometimes you have to try a few out before you find a real keeper.
Cory, thanks for sharing the comments about interviewing and hiring practices. I agree that bringing a candidate in to pair is a great way to check them out, and to let them check out your organization, too. I tried to get something like that going at our company, but for various reasons it didn’t catch on.
The “culture of fear” issue is interesting. I hadn’t thought of it in that way before. It might be interesting to contact a few colleagues in other countries to ask whether the same thing happens there.