- Posted by dan on April 4, 2011
Have you ever had that moment, when you think. "This would be better if they just let us get on with it". I know that sounds egotistical, but it got me thinking,
Who are the lunatics?
The lunatics would normally be the non-senior management people, but actually when you think about it, are not the management team the lunatics. When Jack Nicholson joined the asylum to get out of prison, he was in charge of all his faculties. Much like most people are when they join a new company. But over time we seem to get into the routine of the company. In the film everythings structured around the hospital routine, something that Nicholson rebels against, he wants more autonomy. Modern management techniques advocate this, Scrum, XP etc all place a high value on teams becoming self managing.
But often that's only within amongst the team itself, the company as a whole still works on a command and control structure. Does this go far enough?
Command and Control
The military are the canonical example of command and control. Generals sit in planning rooms, pushing model planes along a room sized map, carefully planning how the war is to proceed. They're being constantly updated about what's going on from the front line. But as things become ever more time sensitive this just doesn't scale.
So there's an ever prevalent push to get enough strategic information to the frontlines so that they're able to make decisions to better achieve the objectives set by those incharge.
Scrum and agile practices are increasingly doing the same but hey often seem to leave out or not fully explain the reasoning why it's thought that we go in a particar direction. There's not necessarily a "we need to win this battle, to control the south and win the war" message along with the battle instructions.
From a training course I was on recently, it became clear that setting a vision was of absolute importance. Scrum has visions it is an important part of the methodology but I still feel that it's often overlooked, or sidelined by the more practical needs of sizing and sprint planning.
Vision
Often we get visions that are focussed on the specifics of the sprint in hand.
But is this lacking? Would it be worth getting teams more involved in deciding what features should be added and coming up with products that are needed. Middle management have a better view of the broad strategic aims.
The team have experience with day to day products and services. Teams always seem to have ideas for products that can make things better, but they lack the knowledge of the high level strategy to make their ideas relevant to the higher level strategies. Middle management are best placed to see these opportunities but can they be to focussed on making the higher level plans a reality?
We end up with tablet manufacturers that end up producing tablets that address feature omissions of their competitors. But forgetting to produce tablets which people actually need. Will the honeycomb tablets make a dent in Ipad sales? Or is it just a "me to" product. Do they need rear cameras at all? Would of it been better to build in Kinect like cameras in the front of the device and put loads of effort into software that can well represent you regardless of what angle you hold your tablet?
What's the problem
Teams it seems are quite often presented with solutions and not problems. You might have inceptions and backlogs to discuss how, you're tablets going to work and what features it should contains, but we're constantly talking about the "tablet" solution and not the underlying problem.
The evolution of a strategy
Is the problem with strategies, that they'll often go through filters. The president might ask for technologies input as to what direction they company should head in. Then the Dilbert sketch below slowly unfolds. Whereby, the president see's ultimately a bullet point of recommendation and thefore favours the cool "tablet" computer seen in a 30 second CNN report.
At this point, we have to ask ourselves, are the lunatics running the asylum?. Or is the system just letting us down. Would we be better off by, deciding on a problem to solve, and setting a vision around this and have the strategies emerge out of this?
- Posted by dan on March 5, 2011
About a week after I wrote a pairing blog post, a work colleague from another team invited me as a guest to heir teams meeting to discuss pairing. He hadn't read my post but had heard about the multiple keyboard thing and thought I might be interested.
The team I sat Phoenix, are a hybrid between my company and
ThoughtWorks, who we've got in helping us.
ThoughtWorks have a wealth of experience with XP practices so naturally we're trying to learn all we can.
What does it feel like when pairings going really well
People said they felt like they'd learned something. Others added they also liked when they felt they'd taught something.
What kept happening though was a divergence into talking about TDD, people really seemed to enjoy and find value in the art of testing.
I saw my characterisations come somewhat to life and some of the team described that for two talkative people they could waste time discussing the best way to solve a particular problem or how to write a test for it.
Does this mean, that to pair program ideally you should be doing TDD? It was almost implied or is it because we're relatively new to TDD. I could conclude prehaps prematurely that to feel like you're doing pair programming really well you have to do TDD.
Pair Rotation
When it came to pair rotation, they rotated daily, which I considered the better way forward, but they were finding it hard to context switch on such a regular basis and felt it slowed the process down.
This is an interesting dilemma, people probably have different perceptions of why rotating is important, the company probably is interested is the so-called buss-ability factor. Whereby if someone tragically is injured by a bus, then work can continue because enough other people have shared knowledge about the work that they can continue. My team tend to rotate the pairs after each story and we were going to try rotating at the end of each day. Now I'm not so sure.
In favour of frequent rotation is more people see the code, more ideas and discussion arrise and hopefully a better solution emerges, or prehaps people just sit there try to focus on the new problem whilst daydreaming about the one they've just come from.
Shared accounts
We don't as of yet have pairing user accounts, apparently there's security issues around this. Though as was pointed out; sharing passwords is an inherently less secure option.
I'm thinking shared accounts are a great idea and one key part of these accounts for me is that they don't have outlook.
Have you ever noticed if you turn off outlook or email, you can get more done. Yes I'm pointing out the obvious. I'm trying to urge the team into a no interruption window. Phoenix already do.
I'm hoping a clear 2 - 3 hour window in the morning after the daily standup will enable us to get all the important things done in the morning.
Desk Arrangement
Desks always seem an issue, I've talked about this in my post about the
Team Room, people were huddled in the corner of a L-shaped desk, which isn't really ideal, but getting all new desks is an expensive proposition. I think they're going to try moving the machines into a better position but there's only so much you can do. Our desk arrangement isn't really that far off
Martin Fowler's UPOD arrangement the desks not being straight seems to be the main problem.
I suggested the multiple keyboards technique as it gives you a little more space to breathe. Someone mentioned Pairing Gum might be necessary for some people, which is alway a nice consideration :)