Posts
(This blog was inspired by the forward that Tim Lister wrote for Mike Cohn’s newly published work, Succeeding With Agile – Software Development Using Scrum. Look for my review of the book in a future post)
Those who know me well know two things about me:
1. I LOVE to tell a good story (and I might tell you the same one 5 or 6 times, so watch out);
2. I believe in the analogy, the allegory, and the axiom: basically, that we can find parallels, symbolism, and truths about one area of our lives in an entirely different area.
So with that said, let me tell you a good story that I promise to conclude with an analogy, an allegory, and an axiom!
As a high school sophomore, I went on a school-sponsored canoe expedition (just like the old French voyageurs) in Quetico Provincial Park in Ontario, Canada. This was no ordinary camping trip. It was 6 days, 12 people (3 per canoe), with no powered vehicles (air, land, or water) allowed, no buildings, no power lines, no roads…no sign of civilization. Each person had a 75 lb. backpack with personal items, tent, cooking equipment, and food…everything we needed (but NOT, for sure, everything we wanted, or thought we needed). We had to lay out our personal items before we left and the guide went through and eliminated what he felt we wouldn’t need. And everything we packed in, we had to pack out. No garbage cans.
A great mentor of mine from my high school was supposed to go up and chaperone. He had been a guide up there on several expeditions. He ended up being unable to go, but he gave me this great waterproof guide’s map of Quetico…with all the campsites he’d used in the past marked on it. I was also the most experienced outdoorsmen among the students, so I was set!
On the first day of the trip, our guide Steve decided to keep things light for us, let us get our feet wet (literally!). That first day was a series of small lakes and short (100-200 yards) portages – which, if you’re not familiar, involves beaching the canoe, unloading everything, and carrying all the gear: three packs, paddles, and canoe – over land to the next lake. Our group had never done anything together before…we were just kids from the same school. But we quickly had to learn how to make it work. We had no big guidebook, no real prior experience, and only Steve to answer our questions. That first day seemed rough, but we made it through and looking back, it was REALLY the easiest.
I started off in Steve’s canoe, and by the 2nd or 3rd day, it was clear to him I was more advanced than the others. He took me aside and asked me to command one of the canoes. That sounded great! I’m in! Then the bad news: I would get the canoe with the substitute chaperone. UGH! See, the substitute was the least outdoors-y teacher in the school. He was a canoe leader, and was doing poorly. He didn’t know what he was doing and, to make matters worse, he’d developed a bad attitude about the trip. He was miserable and was making others miserable. I’d be replacing him as canoe leader and he’d be in my canoe! Uncomfortable! I decided to say yes anyways, and off we went. My “favorite” comment he had one day, while canoeing across this beautiful lake, was “I HATE this G** D*** G**-FORSAKEN PLACE!” My answer was a wry “really? I think it’s pretty amazing.” I had to keep things light. Of course, with my trusty guide’s map, I knew exactly where we’d camp every night. But I was wrong…my map was a little old, and Steve had to keep correcting me: this site had a rockslide and was no good, or that site was too bear-infested.
The days went on, the lakes Steve took us across got larger, the portages longer…a half-mile, then the granddaddy one mile portage. I’m proud to say I carried TWO packs over that portage – one strapped in back and one in front – and I only stopped to rest once (a feat that I promise I can’t recreate today). But the teams got tighter, and as we became more experienced, we were able to go farther, produce more.
There were dangers along the way to be sure. One team member got a leach on his leg. One narrow passage between lakes, with faster water, that most people were portaging around, we paddled through. On Elizabeth Lake, there were reports of bears in the area. We had to paddle our food packs out to a tiny island in the middle of the lake and leave them there overnight so the bears wouldn’t be drawn into our site.
We pulled into base camp on day six, 10 grungy-but-seasoned kids, one great guide, and one still-cranky chaperone. That night, we had a little bonfire to relax and review with Steve. “Do you realize what you boys accomplished?” Steve said. “You just traveled 110 miles in six days, with nothing but yourselves and each other to rely on. You overcame challenges, you adapted to adversity, and you’re changed forever for the better because of it.” And he was right, on all counts.
So, do you see the analogy, the allegory, and the axiom? Let me spell it out:
Analogy: Agile software development is a wilderness canoe trip. We start out small to learn, and increment up to bigger and bigger challenges. We adapt to changing circumstances and use the varied talents of our cross-functional team to reach the goal.
Allegory: The expedition is the project, the canoe is a Scrum Team, the whole group is a Scrum of Scrums, the bears and leaches are impediments. Steve was a Product Owner. The chaperone was a discordant team member. The old map is a stale project plan. Sorting through our things before beginning is removing waste and technical debt from our process. The bonfire was a retrospective.
Axiom: Agile, folks, is what we already do in everyday life, certainly on a wilderness canoe trip. So if Agile principles made a potentially life and death trip something fantastic to enjoy and remember forever, what do you think chances are that they can improve our work developing software?
Note: Every word of the story is true. And I bet that chaperone is still cranky about the outdoors today.
As always, I welcome your comments.
Thursday, November 12, 2009
Tuesday, November 3, 2009
The Psychology of the Sign Off
“Make sure you get the Sign Off.”
That’s a common mantra among managers in any business. The sign off is sometimes pursued and valued like it’s some kind of ancient idol. (The opening scene from Raiders of the Lost Ark comes to mind.) It’s taken for granted that it’s a necessary part of the processes we use to produce product. But what does the sign off really mean? When you get that signature on the document (or give yours), what is the sign off saying and what are the expectations of both parties going forward?
Webster’s online dictionary defines “sign off” as follows:
“to approve or acknowledge something by or as if by a signature <sign off on a memo>”
Hey, that sounds pretty innocuous. I showed you something, or did something for you, and you’re just signing a piece of paper that says you saw it, or I did it. But of course, the benign nature of that thought belies the social complexities and implications of what that signature really means.
On one level, it’s an issue of trust. Why do you need my signature? Isn’t it enough that I told you verbally that its fine? If we worked in a world of implicit trust, that might be OK. But if you’re the one looking for that signature from a manager or client, and heard that question, what are the chances you would respond “yes, sure, it’s fine?” I say the chances are slim and none. If you could take it on verbal approval, then chances are:
1. The decision or deliverable in question is very minor,
2. Your organization is extremely small (and likely with a very flat organizational hierarchy), and/or
3. You really DO work in an organization with a model of implicit trust (this is rare if (2) is not true).
So if we don’t trust each other enough to take everything on verbal approval, the question is why? What are we afraid is going to happen if something goes wrong?
In THAT question lies the core issue. It’s not what happens when everything goes well…when the product is delivered on time, on budget, free of defects. At that point, everyone is happy, and someone throws a party. Maybe the only person unhappy with the lack of formal sign offs in that situation is the person whose job it is to make sure all the boxes were checked for process’ sake.
But when things DO go wrong – major defects make it into production (“QA is the problem”), business owners or customers report that product features aren’t what they wanted (“Requirements are the problem”) or delivery is very late or well over budget (“OK, who did it?”) – THAT is when the true nature of the formal sign off shows. That’s when fingers get pointed and people dive for cover…behind the sign off.
I submit that at its core, the formal sign off serves mainly as an abdication of responsibility for a deliverable, or transference of that responsibility to the signatory.
This is why people are so apprehensive to sign off. Because at worst, by signing, the signatory puts him/her self on the hook for the deliverable on which they’ve just signed off. They’ve accepted responsibility for something they’ve likely had no hand in producing, but for which they have to answer. And when things go wrong, they'll be left holding the bag. This is an issue of the culture of the process.
Imagine a large river being fed by several small streams. At the point where each stream feeds into the main river, there’s a lock. Water flows from each stream into the main river, but once it’s contributed a certain amount, the lock closes. When a storm hits at the mouth of the river, and water is pushed back upstream, the locks are closed and the streams are protected, but the main river (and its surrounding banks) is devastated. This is a metaphor for the classic sign off when things go wrong, and the real tragedy is that in this model, nobody is responsible for the successful delivery of the product (except maybe the last signatory). Everyone else has plausible deniability. If I’m contributing to the product, and something goes wrong because of my work, but you signed off on it, I can make a great case that I’m not responsible because you accepted both my product and the responsibility when you signed off.
Now, contrast this with the model we use in Agile, specifically Scrum. We take a cross functional team, combine that with a business Product Owner and a Scrum Master, and emphasize that together they are the team, together they are collectively responsible for the successful delivery (or failure) of the product. We move away from the silo mentality that fosters people protecting their camp (or stream) at the expense of the product. We move to putting the product first, by ensuring that the product owner is prioritizing the product backlog to ensure we’re working on the items with the highest business value first, in every iteration. And we emphasize continuous, open communication on the team.
Don’t misunderstand me. I’m not saying that Agile or Scrum is some magic bullet to avoid the contentious atmosphere that the traditional sign off can foster. Is it possible to poison an Agile development effort by sticking to the old psychology of the sign off? Absolutely. What I am saying is that it provides a framework more conducive to making the culture change that is necessary to change that atmosphere. It’s not in our nature and it’s not easy…it takes a willingness by the parties involved to give up the protection of the sign off, and sign up for shared success or failure. Implement this culture shift in your team or organization, however, and trust and a shared sense of ownership of the product will cement the team together, stronger than the sum of its parts.
That’s a common mantra among managers in any business. The sign off is sometimes pursued and valued like it’s some kind of ancient idol. (The opening scene from Raiders of the Lost Ark comes to mind.) It’s taken for granted that it’s a necessary part of the processes we use to produce product. But what does the sign off really mean? When you get that signature on the document (or give yours), what is the sign off saying and what are the expectations of both parties going forward?
Webster’s online dictionary defines “sign off” as follows:
“to approve or acknowledge something by or as if by a signature <sign off on a memo>”
Hey, that sounds pretty innocuous. I showed you something, or did something for you, and you’re just signing a piece of paper that says you saw it, or I did it. But of course, the benign nature of that thought belies the social complexities and implications of what that signature really means.
On one level, it’s an issue of trust. Why do you need my signature? Isn’t it enough that I told you verbally that its fine? If we worked in a world of implicit trust, that might be OK. But if you’re the one looking for that signature from a manager or client, and heard that question, what are the chances you would respond “yes, sure, it’s fine?” I say the chances are slim and none. If you could take it on verbal approval, then chances are:
1. The decision or deliverable in question is very minor,
2. Your organization is extremely small (and likely with a very flat organizational hierarchy), and/or
3. You really DO work in an organization with a model of implicit trust (this is rare if (2) is not true).
So if we don’t trust each other enough to take everything on verbal approval, the question is why? What are we afraid is going to happen if something goes wrong?
In THAT question lies the core issue. It’s not what happens when everything goes well…when the product is delivered on time, on budget, free of defects. At that point, everyone is happy, and someone throws a party. Maybe the only person unhappy with the lack of formal sign offs in that situation is the person whose job it is to make sure all the boxes were checked for process’ sake.
But when things DO go wrong – major defects make it into production (“QA is the problem”), business owners or customers report that product features aren’t what they wanted (“Requirements are the problem”) or delivery is very late or well over budget (“OK, who did it?”) – THAT is when the true nature of the formal sign off shows. That’s when fingers get pointed and people dive for cover…behind the sign off.
I submit that at its core, the formal sign off serves mainly as an abdication of responsibility for a deliverable, or transference of that responsibility to the signatory.
This is why people are so apprehensive to sign off. Because at worst, by signing, the signatory puts him/her self on the hook for the deliverable on which they’ve just signed off. They’ve accepted responsibility for something they’ve likely had no hand in producing, but for which they have to answer. And when things go wrong, they'll be left holding the bag. This is an issue of the culture of the process.
Imagine a large river being fed by several small streams. At the point where each stream feeds into the main river, there’s a lock. Water flows from each stream into the main river, but once it’s contributed a certain amount, the lock closes. When a storm hits at the mouth of the river, and water is pushed back upstream, the locks are closed and the streams are protected, but the main river (and its surrounding banks) is devastated. This is a metaphor for the classic sign off when things go wrong, and the real tragedy is that in this model, nobody is responsible for the successful delivery of the product (except maybe the last signatory). Everyone else has plausible deniability. If I’m contributing to the product, and something goes wrong because of my work, but you signed off on it, I can make a great case that I’m not responsible because you accepted both my product and the responsibility when you signed off.
Now, contrast this with the model we use in Agile, specifically Scrum. We take a cross functional team, combine that with a business Product Owner and a Scrum Master, and emphasize that together they are the team, together they are collectively responsible for the successful delivery (or failure) of the product. We move away from the silo mentality that fosters people protecting their camp (or stream) at the expense of the product. We move to putting the product first, by ensuring that the product owner is prioritizing the product backlog to ensure we’re working on the items with the highest business value first, in every iteration. And we emphasize continuous, open communication on the team.
Don’t misunderstand me. I’m not saying that Agile or Scrum is some magic bullet to avoid the contentious atmosphere that the traditional sign off can foster. Is it possible to poison an Agile development effort by sticking to the old psychology of the sign off? Absolutely. What I am saying is that it provides a framework more conducive to making the culture change that is necessary to change that atmosphere. It’s not in our nature and it’s not easy…it takes a willingness by the parties involved to give up the protection of the sign off, and sign up for shared success or failure. Implement this culture shift in your team or organization, however, and trust and a shared sense of ownership of the product will cement the team together, stronger than the sum of its parts.
As always, I welcome your comments.
Subscribe to:
Posts (Atom)