Pairing and Teamwork for The Uninitiated and Resistant

Dear and Gentle Reader,

Attending the local Lean Agile Coffee, the question arose “How can we get a team to start pair even if they all hate the idea”? 

Ever heard this question before? 

I thought so.

Well, I’m going to tell you the answer I gave, and if it’s useful to you, then good.  It’s based on an exercise I tried with one of my teams, and it seemed to be effective.

To begin with, I explained to them how were were going to work in the retrospective, proposed a few ground rules on which we voted for agreement, and got underway.

We spent five minutes brain-dumping onto stickies things that puzzled us or that we felt needed attention.  Then we grouped them leaving us with a small handful of things to consider.

I asked the team to spend five minutes writing down ideas to resolve the puzzles or that would have us make progress, one per sticky. But it had to be in absolute silence, and so, they had to work alone.  I had fun enforcing the silence with comedy shushing and angry-librarian looks.

Next, they were to pair up, the rule being that like could not pair like with like. Dev could not pair with Dev, nor QA with QA.  Now they could spend ten minutes discussing their subjects, even coming up with others if they felt they had time.

Next they had to stand up, pair by pair, and sell their solutions to us.  They had a couple of minutes each.  After their pitch, I asked them to comment on what it was like working alone compared to working with the other person.

Finally, with all the solution up on the board, we grouped them again, dot-voted to select one as an experiment for the next Sprint, and wrapped up with a discussion about what it had been like to decide on this as a team. We did a quick low-to-high line for return on time invested, and the consensus was high.

So, not only did we follow the basic framework for a retrospective (set the stage, gather data, draw conclusions, propose an experiment, retro the retro) but this was also an exercise to have them experience pairing, being bold and open, and working together as a team.  I didn’t need to point out to them what I was doing, they got it.

I’ve had to say to some people before now “You’ll hate it before hand, but you’ll love it afterwards”.  In this case, I didn’t need to be that obvious, they just did the exercise and got it.

It’ll need refreshing to help it stick, so I might look for a variant.

Full disclosure: I pinched the basic idea for this from Thiagi’s Hundred Favorite Games, a phenomenal resource of training games and exercises.  Snag a copy for yourself, it’s pure gold.

Folks at the Lean Agile Coffee liked the sound of this exercise, so I hope that they try it, and bring back reports of their experience.

That is all for now, dear Reader. Go with Agility.

P.S. In looking for a link to Thiagi’s book, I found this link to 350 of his games – free!

Retrospectives

While I’m finishing the wool-gathering for the last post in my Social History/Neuroscience of Agile series, here’s some reflections on the last couple of retrospectives and what’s going on around them

I’m still fairly new to the team. When I joined them, they were halfway through a sprint, and since then we’ve completed three sprints. They’re one of many teams, in a very complex business environment, and the code they’re producing operates as an integration point for the code from several other teams.

The major challenges they’re facing are, in no particular order:

  • Environmental delay
  • Cross-team coordination
  • Starting too much work

Environmental delay

By this I mean the impact of discovering that an environment (say a QA Integration server) is not ready, and it turns out that the infrastructure team have a ten day lead time on building the server. Or an essential service needs to be configured to expect new connections and this has a four week lead time. Or opening a firewall takes four weeks to pass security review.

Why’s this a problem?

Two reasons: first the lead times are not widely publicized or, in some cases, even predictable. This would suggest that the teams involved probably could use a Kanban approach to track their lead time and cycle time and then be able to publicize a more reliable service level.  For instance, “A request to open the firewall typically can be completed within 20 working days 80% of the time.”  An escalation path could be offered as well “Urgent and important requests (i.e. to resolve production outage) can be processed in twelve hours, and must be followed by a risk mitigation review to minimize repetition of the issue”.”

The second problem is that often these lead times are longer than the sprint length. So if work in sprint n reveals a need for an environment change in sprint n+1, tough! You ain’t getting it until sprint n+x, buster! We all know that in the real world, no matter how good our release planning, all the time we discover things only during story grooming. So having environment teams work to reduce their lead time to be less than one sprint’s length would be a major step forward.

Cross-team coordination

Do I need to tell us why this is a problem?  Oh, ok.

So in this case, it’s basically because more than one team is working on the same code base.  Probably not the same code modules, but all the time we see that Team A does x, that break the code for Team B in module y.  Team A’s code is essential, so Team B updates code y to take this into account.  Team C’s code z promptly breaks.  Guess what happens when they fix it.

Oops.  Test Driven Development and Continuous Integration anyone?

Both of these problems require collaboration across boundaries, and that’s one area that is being worked on.  Remember this: Scrum is designed to reveal organizational dysfunction.  Taa-daa!

Starting too much work

When does value become real? When we put working features into (paying) customers hands. So we need working features.  They’re working when they are finished, so finishing is a good thing.  Duh, right?

So imagine a team that for one reason or another seems to be “falling behind” (read: their progress is not visible). Their workload increases as they have to keep dealing with the work on hand, and of course, someone up there keeps piling on more.

If the team’s capacity has been reached, and you add in more, it MUST mean that stuff ends up being late.  Adding more cars into traffic slows the traffic. My calendar is full, if you give me something else to do, something I can’t magic up more time, so either it’s not going to happen for a while, or something else is going to be late.  Fact.

Put another way, we want to stop starting and start finishing.

What do I mean?

Try this: Know the names of all the members of your team? Good.

Exercise A

  • Set the timer on your phone for, say, twenty seconds.
  • Start writing their names.
  • When the timer goes, stop writing.
  • Your score is the number of names you wrote completely.

e.g. Abir , Bill, Cameron, Devon, Edw… Ding! That’s a score of 4.

Exercise B

  • Set the timer again, same amount of time.
  • Now, for all their names write the first letter, then the second letter, then the third letter.
  • When the time goes, stop writing.
  • Again, your score is the number of names you wrote completely.
A b i
B i
C a
D e
E d
G r

Oops! Did you even score 1?

That’s what happens when you keep starting and don’t finish.

So, Stop Starting and Start Finishing!

Worst sprint so far, they’d started sixteen stories, and finished one.  They split (ow!) fifteen and didn’t recognize what this was concealing as they pretended that they’d finished all sixteen.  Hmmm….

How did we fix it?

Well we haven’t – yet.

But here, much abbreviated, are the exercises we did for the last two Sprint Retrospectives.  By the way, I always follow the format Set the Stage, Gather Data, Draw Conclusions, Design an Experiment, Retro the Retro. I’m only going to talk here about the middle three exercises.

Sprint N

Gather Data: We had the burn down, that showed we’d done only 35% of what we’d set out to achieve. So then we did a real quick Start Doing, Stop Doing, Keep doing exercise where the team brain-dump onto stickies and put them up on the board under these three headings. (Five mins.)

Then we had the team swarm on the board and group the stickies into related themes, and finally dot vote on the as things they were interested in.

Draw Conclusions: Now I had the team undertake three exercises. First, they had to sit in silence, and write on stickies any ideas that they had about the number one topic. I enforced the silence with librarian-like shushing.  It was kinda fun! Next I had them pair up, and the rule was you couldn’t pair with someone with the same role as you. Then in pairs, they could compare stickies, discuss them, come up with something else if they wished.

Lastly, I had each pair pitch their conclusions to the rest of the team for two minutes. At the end of the two minutes, they were invited to comment on what it had been like to do this alone, and what it had been like to do this in a pair.

By the time each pair had gone, the place was a frenzy of people demanding another go to pitch again, discussions where breaking out all over the place.

In effect, we stepped from being lone guns, through pairing, to working as a team in this one exercise.

To wrap it up, once again, up went the stickies on the board, and we swarmed and grouped them.

Finally, once again, we dot-voted, and we had a topic for consideration for the experiment.  In this case it was Focus on Story Grooming (with a strong hint of Cross-Team Coordination).

We decided that the experiment was to focus on this in the Sprint Planning session, and in the next Story grooming session.

Follow-up

About six days into the sprint, the question was asked in the daily stand-up “Hey, are we tracking our experiment?” We all looked blank, and guilty, as once again the Sprint was off track.

On reflection (Failure Bow time!) I realized that of course we were tracking it.  That’s what the Burn-down chart was doing.  It was showing that we’d sucked at Story Grooming!  We’d been adding tasks up the wazoo!

Sprint N+1

This time, to gather data, I displayed the burn-down.  We’d done much better, but there’d been some gaming of the numbers still, and stories were all getting finished at the last minute.

So here’s the exercise we did.

Gather Data: I had them stand in two rows, pairs facing each other.  The instructions were A interviews B “Tell me two things that you think we should pay attention to” and write them down.  Then B interviews A with the same questions.  When we’re all done, the person on the end of row A runs round to the other end and all the A’s move along one spot.  Then we repeat the interviews.  We do this until you meet your original partner again.

This actually took something, it was fascinating seeing the guys struggle to understand what I was asking them to do.  They hated it to begin with!

Oh, and one of the guys was on a video link, so one of us was interviewing a laptop!

But by the time were were done, it had turned fun and noisy! They loved it.

They we went to the board, of course, and started to cluster the stickies.

Draw Conclusions: This was simply a brainstorming exercise.  I quietly left to go to the restroom, and by the time I’d got back, they were working on this on the whiteboard themselves.

The Experiment: We had realized that we tended not to create a decent support structure for our experiments.  So as we came up with the things we wanted to do, we simply recorded them in Story format in Rally (not an endorsement, good though Rally is, it’s just the tool we happen to have).

This ensures that the stories will be sized and included in the upcoming Sprints.

Next Sprint

At the start of the Sprint Planning, I’m going to have the guys use the “Write your team’s names” exercise.  It’ll only take a couple of minutes, and may have them get what’s going on with taking on too much work and trying to start it all.

But what about…?

Did any of this progress towards solving the Environment Delay and Cross-Team Coordination issues? Not directly, but it’s looking to me like the team are getting very quickly more skillful at undertaking the kind of exercises and using the kind of thinking that has people collaborate to produce solutions.

I’ll blow more about this as we progress.

Ah, yes, Mindset.

So, last time, I blathered on about The History of the World in Three Minutes. The most important point, and I hope this was clear, was the the Industrial Revolution gave us (us = The West) a two-tiered education system. The Obedient Unskilled and the Proud Professional, to paraphrase.

Tender reader, strap yourself in, we have another point to make.  There is an excellent book, Mindset Carol Dweck (Random House, 2006). Carol Dweck is a psychologist who’s been researching her subject for many years. Read the book, but in summary, she proposes that there are essentially two mindsets.

The first, the “fixed” mindset, is best exemplified by say, a great tennis player. This guys knows he’s the best. He cannot lose. If a game doesn’t go his way, it’s not due to a failing of his, oh no. His shoelace broke, there was a reflection glinting in his eye, the line judge was asleep.  But him lose? No, impossible.

You here it in corporate speak “We only employ superstars!” You hear it in parents thinking they are encouraging their kids “We only want you to be the best you can be.”

The problem is that if someone is the best, and identifies that way, then any failing at all is a failure of Self. Which makes is impossible to either admit to failure, or even take on anything where failure is a glaring option. Or even a very subtle option.

It’s not even always about being the best.  It might be simply about being what you are.  Your test scores show that’ you’re a C in math.  So you know that you’re only so-so at math. “I couldn’t never do that job, it needs too much math, and I’m meh at math.”

What’s the second mindset? You probably guessed it, it’s the “learning” or “growth” mindset. This guy might not have won today, but he learned something and maybe he’ll win in the future. This girl got a C in math, but she’d like to get a B next time so she’s going to study.

[Stop Press! At this point, I interrupted my writing to attend the East Bay Agilistry Meetup where Dr Ahmed Sidky gave a talk titled ”The Agile Mindset: The Key To Being Agile Not Just Doing Agile”. He had some fabulous slides on Carol Dweck’s work, and there was much nodding and agreement going on!]

In light of Ahmed’s talk, and I’m hoping that he’ll be sharing the deck, we can cut to the chase.

The fixed mindset fears failure, as it’s a failure of Self. The growth mindset embraces failure as a learning opportunity. The fixed mindset reaches for certainty and tries to resist or control change. The growth mindset acknowledges uncertainty and embraces change as opportunity. The fixed mindset hates looking bad or stupid, the growth mindset just doesn’t care about that.

If you’re reaching ahead to seeing that the “old school” way of doing things equates to the fixed mindset and agility equates to the growth mindset, yep, we’re getting there, and we’ll bang that gong with a vengeance shortly.

But first I want to cover the why of the mindsets. Why do people think that way?  We’re not born with a built-in mindset.

John Taylor Gatto has written at length on the problems of Western schooling. He documents the history of the decisions and actions taken to implement methods of schooling specifically designed to support the Industrial Revolution. To summarize, two streams were required. One would produce unskilled obedient laborers and soldiers to do the hard physical work and be cannon-fodder, the other would produce highly self-invested professionals who would manage the others and provide the technical problem solving, all to benefit the owners of the industrial means of production.

The thing is, it worked incredibly well. The Industrial Revolution was the driving force behind the explosive growth of the 19th and 20th centuries. Never mind the politics, never mind the Dickensian and Orwellian aspects, all the benefits of modern life that drive our society today came from the industrial revolution.

But think of that second tier, the professionals.  Their work is knowledge work. As Ahmed so nicely put it, we keep working while the cost of the change we’re undertaking is assessed as being less than the value that change provides. And knowledge workers are all about driving down the cost of change. And as they focus on this, what comes right behind it? Technology!

Technology is all about finding more and more ways of enabling cheap change. So what do we get behind the Industrial Revolution, but a Technological Revolution!  Taa-daa!

But the thing is that the way the professionals had been taught to think was industrial.  It was about production lines, it was about nailing certainty, and ensuring that the means of production was predictable and completely controlled. The workers could be commanded “Do this, and do it thus, and keep doing it” and all would work.

Whoops. All this quest for certainty produced the technological revolution that brought with it the means for innovation that brought with it… uncertainty! Change! Yikes!

And the poor old professionals, still being churned out by the University System, a great machine that grinds exceedingly slow and exceedingly small (and at HUGE expense), the poor old professionals are still being taught to invest highly in their Qualification (ooh!) and still being taught to prepare for a career (a what?) and still being taught to believe in The Plan.

I’m going to pause, and find a dark corner, and give myself a quick rub-down with a damp copy of Oz Magazine from 1968, and wait until I calm down before I continue.

Up next… well, team, what do you think we’ll be talking about next…?

The History of Work in Three Minutes Flat

Humans as humans have been around for roughly 200,000 years. Some of the first are still waiting in line at the DMV.

It took that long to get to around 1 billion of us. That’ a pretty low population density, and anthropology suggests that there really was no such thing as “work” until agriculture started around 8,000 to 5,000 years ago.

Huh? Well, let’s start by defining “work” as I use the term here.  I don’t mean simply the plain dictionary definition “Activity involving mental or physical effort done in order to achieve a purpose or result.” I mean work that is done to produce a surplus, so that surplus can be used in some form of exchange to fulfill needs outside the result or immediate purpose of the work.

So when agriculture started, work was farming, which produced a surplus. This surplus had to be administered, and that in turn led to mathematics. How to divide this pile of grain amongst the people, and retain some for the administrators? It needed some simple sums, and that got math underway.

Fast forward, at least in the West, through Greek and Roman civilization, then into the Dark Ages. Want to know about command and control? Think feudalism and suddenly your boss might not look so bad!Daily Scrum?

For the next few thousand years, the majority of work took place in the field. Then back in the 18th century someone noticed that a boiling kettle rattles its lid, and bingo, the Industrial Revolution! (I know, there was more to it than that, but hey, three minutes.)

With that, the center of production moved to the factory.  Dad, and often Mom, and often Junior, were stuck in the factory for umpteen hours a day.

I’m not going to go into the dehumanizing effects in detail, I’m not going to touch on the dawn of socialism that sprouted from studies of the dismal conditions in the factories. But we need to note that it was dehumanizing, and I will be researching and qualifying this assertion. The point is that we did not evolve to work in factories. (Obedience ended up taking a bashing in due course. Russian Revolution anyone? French? American?)

Back to the plot. The smart money didn’t just go into the factories. The Prussians came up with an education system that graded pupils for likely job training. Roughly, they were looking for one stream who’s major requirement was that they should be obedient. They would do as they were told in the factories, and they would charge into the face of the enemies guns when ordered.

The other main stream was that of the professional. The professional could manage the obedient and solve the difficult problems. Accountants, engineers, lawyers, and so on, and the education was designed to have these people be very highly invested in their qualification. It was self-defining. I can’t prove it, but I’d guess that the social exchange that includes “So, what do you do?” “Oh, I’m a blah-blah” comes from this. The question is about doing the reply is about being. Remember this point.

It worked like a charm, and the benefits of the Industrial Revolution propelled us up to the 7 billion people on the planet today.

Taylorism (aka Scientific Management)) standardized work.  For Science! The humble worker was measured and quantified and became a fungible unit of production.  Moreover, Management became a profession. Who knew? “Swap them around, it doesn’t matter, I’m qualified to command them, the system will still work!”

And it did. Very well. (Never mind the squalor, feel the width!)

Well, here we are today.  The biggest outcome of the Industrial Revolution is Technology. The biggest outcome of Technology is Information. We no longer have a primarily industrial economy, we have an Information Economy.

We have an Information Economy.

But we have an Industrial Education…

In the next exciting episode, we’re going to discuss mindset and how simple it can be to transform what’s possible with a slight change in language. What’s that go to do with this week? Read on and you’ll see…

Forthcoming attractions!

Ok, I’ve been nudged back into blogging action by my recent contact with the Agile community in the Bay Area (San Francisco if you’re looking at a globe).

Here are the topics I’m thinking about and will be writing about in the coming weeks:

  • Neuroscience, agility, facilitation, and the besieged middle manager.
  • Social history, tea kettles, short-term problem solving and long-term problems.
  • AQAL once I understand more than how to spell it

Any one of these could morph into a PhD or a Tome of Significance if I’m not careful. Hands up everyone that thinks I’m careful…

Right then.

Oh, the team will find that too hard….

<rant>

I need to blow off a little steam.

There’s a habit that I see around me all too often.  We propose a process improvement, and it requires the use of a tool, something like filling in and updating issue tracker tickets.

And we’re told by the manager of a team that their team will find this too hard.  Wait… what?

Programming is hard.  Driving is hard.  Cooking is hard.  Bringing up children is hard.  Does this manager think that his people – while regularly asking them to do the impossible – are incapable of of filling out and updating an issue tracker?  But that’s easy!

What is going on here?  What motivates people to keep demanding success while setting people up to fail?

Ok, I know that humans are designed to identify problems.  It’s what we do.  I know that the emergent design of evolution built us to survive by spotting the problem before it spots and eats us.  So what will it take to upgrade that problem-spotting mechanism to operate beyond the immediate problem into an assessment of longer term value?  We don’t live in a life-threatening environment for the most part any more.

So what can we do to help people see past problems to benefits?

</rant>

<discuss>

Well, maybe this is yet another example of the need to ask questions, not offer solutions.  I’m seeing more and more the wisdom of hardly ever offering a solution until enough questions have been asked for the consumer of the solution to have already said out loud that they need it.  If that’s not done, then the solution can be seen as something to be assessed as new information, and what do we do with that?  We see it as a problem!

Have I answered my own question?

Let’s try it.

Me, what do you see as the problem here?

“Well, I see managers who don’t believe that their people can do simple things.”

What else?

“Well, it makes me mad!”

Why’s that?

“I’m offering them a solution to their problems!”

Ok.  But do they see them as problems?

“Sure, they’re complaining the whole time!”

Have they asked you to provide a fix?

“Um… kinda…”

Have you asked them if they see this as a problem?  And if they see it as an important problem?

“Um… not exactly…”

Right then.  Could it be that since you’ve not asked them, then they’re not thinking about a need for a solution, so when you offer it to them they just see it as another problem?

“Hmmmph.  Good point.  So the manager saying it’s ‘hard’ is code for ‘Don’t bring me another problem’.  Right.  Got it.”

</discuss>

<act>

Ask first.

</act>

Calendar scheduling versus to-do scheduling. “Clock time” versus “event time”.

David Allen (the Getting Things Done guy) discusses lists versus calendars in his latest email/blog post.

This relates to a point raised in a book I’ve just finished reading  Wait: The Art and Science of Delay by Frank Partnoy.

Calendar time, “clock time”, is a relatively recent development in the history of humanity.  Trying to fit our tasks into scheduled time is always a problem, as we’ll never know if we’ve scheduled the right amount of time until we’ve completed the task.  Partnoy argues that getting work done by scheduling with clock time is all about efficiency, the desire to use every second in an approved manner.  This idea came about thanks to Taylorism, still a huge influence on management and project thinking.  Clock time is derived, Partnoy tell us, from Babylonian mathematics being in base 60 and the lunar month occurring twelve times in a solar cycle.  it has nothing to do with governing our schedule in reality other than marking how much time has passed.  Using clock time to organize our list of things to do seems odd when we realize this.  We could just as easily have ten hours in a day as twenty four.  If the moon was slightly different in size, we might have fifteen months in the year.  Using clock time is obvious, as it’s there, but it has no inherent ability to actually define our real world obligations.

Contrast this with “event time”.  Event time is, for example, “after lunch” or “when I’ve finished this”, or “tomorrow evening at sunset”, or “when Bill comes to visit next”.  Or “when I’ve finished this” I say again!

GTD’s approach recovers a focus on event time with the concept of “next actions”.  For each project – something that requires more than one step to complete – you determine the next action.  Once you’ve determined your list of next actions, you do them.  You fit them into you day around actions that have to be taken at specific times, such as meetings.

This is also a concept addressed in an agile approach.  We handle “clock time” in Scrum sprints or by measuring Kanban cycle time.  We acknowledge the inability to know ahead of time exactly home much clock time we need for a specific task using a variety of techniques.  Size-based estimation, team-based capacity that averages individual capacity, velocity, limiting WIP, all speak to this.

And then we do the work using event time.  When this is “done done” we’ll move onto the next thing.

Anyhow, once again, it turns out that social history proves to be a great source for understanding and improving our methodologies.  As one of my coaches says “Read.  You won’t live long enough to get it all unless you read!”  Indeed.