Going quiet
Things will go quiet around here from 5th February until the beginning of March. I'll be away in New Zealand and Australia. I'm not taking the
PowerBook but I'll be taking a few books to read:
Links to this post
Uber agility
Back in December,
Mike Griffiths devised an
Agility Assessment Quiz. I was interested to see the agility-profile for the team I've been coaching recently. We came out as
uber agile. You can see my answers to the questions and read an account of our team practices and successes
here.
In a
later post, Mike reminds us that
merely applying an agile process is not a guarantee of success. There are always trade-offs, and unintended consequences. We must adapt and change accordingly and keep striving to build the best software we can. Referring to our quiz results, he goes on to say,
this is not to say we should discourage passionate implementation of agile methods.I'll add this: Be careful when you're adapting. Always uphold the
values and
use the
principles to guide your application of practices and their adaptation in a given context.
Tags:
adaptation ,
agile values,
agile principles
Links to this post
Change is required to accommodate agility
On Wednesday night Andrew Scotland ran a workshop at the second Agile Practitioners Forum. The event was organised by Les Oliver and
Simon Voice and sponsored by
Radtac and
Connections Recruitment. The venue was the Gun Room aboard the
HMS Belfast.
The topic for exploration was bringing about the change necessary to accommodate the adoption of agile methods. At the heart of introducing agility into any large organisation is a huge amount of cultural, behavioural and organisational change. Andrew hypothesised that sometimes the need for this type of change is the primary driver for the introduction of agile methods and can be more important than the traditional drivers of improved ROI and improved engineering practice.
Andrew provided a brief introduction that charted the
BBC's journey so far, where the introduction of
Scrum (less focused on team behaviours and roles) proved more successful than the introduction of
Extreme Programming (at that time more focused on engineering practice). The result is a prioritisation of the agile values where collaboration comes top.
During the workshop, we will split into 4 groups to brainstorm factors that support change and factors that resist change. We then used a technique called
force-field analysis to indicate the relative strengths of the factors.
To close, Andrew hosted a plenary where each group shared their top 2 supporters and resisters of change which were then discussed by everybody.
The top factors that support change are:
- Empowerment/Authority
- Fashion (agility is trendy so take advantage of that)
- Desire to succeed
- Sponsorship
- Buy-in
- Commercial, business and technical advocates
- Business drivers
The top factors that resist change are:
- Command and control
- Fear
- Politics
- Sick teams
- Silos
- Dogmatism
Here is the
BBC's force-field:
apf-jan2007-1
Originally uploaded by sjb140470.
Tags:
agile,
change,
culture
Links to this post
Finding flow in culture
Mihaly Csikszentmihalyi writes:
Cultures are defensive constructions against chaos, designed to reduce the impact of randomness on experience. They prescribe norms, evolve goals, and build beliefs that help us tackle the challenges of existence. In so doing they must rule out many alternative goals and beliefs, and thereby limit possibilities; but this channeling of attention to a limited set of goals and means is what allows effortless action within self-created boundaries.
When a culture succeeds in evolving a set of goals and rules so compelling and so well matched to the skills of the population, its members are able to experience flow with unusual frequency and intensity.
Flow being what
Tom DeMarco and
Tim Lister describe as a highly productive state of concentration.
The trouble is, without some randomness things move too slowly and ultimately the culture stagnates and people get pickled. Limiting options, ruling out alternatives and imposing artificial constraints won't help you adapt and respond to change more quickly and innovate. And again, the things can stagnate.
With too much randomness it's difficult to retain focus and everything becomes a knee-jerk reaction. It feels like a state of perpetual change and thrashing sets in crippling your ability to get things done. People burn out.
A balance meeds to be found to achieve
flow.
Tags:
culture,
flow
Links to this post
Mission possible
In a recommendation received from my last client I was described as
a man on a mission to change the way the world thinks about [software product] development and teams, and to change the way software serves its purpose. It's true, but for some years now I've had a broader goal. I want to see the end of
command-and-control because I don't believe agility can be achieved in a
command-and-control environment. I believe that a working environment, which empowers people who are prepared to trust, show courage and make commitments, is capable of delivering so much more than an archaic, hierarchical and bureaucratic organisation that cultivates egos and politics. I want to help companies recognise the inherent problems with
command-and-control. I want to help companies realise more benefits by helping them to:
- Flatten hierarchies and dismantle departments organised by role or skill-set, to remove bureaucracy and office politics and eliminate waste.
- Build cross-functional teams responsible for single products rather than spread that responsibility across groups of people taken from different departments.
- Overcome organisational constipation by pushing decision-making down to the coalface.
- Create, nurture and safeguard an open, trusting and empowering environment where everything is kept visible, where people can speak honestly, make commitments, be held accountable and demonstrate the courage to make decisions and take action, fail fast and learn quickly.
- Transform managers into servant-leaders who provide facilitation and let their team/s self-organise and decide how they will get things done.
- Get stuff done in a repeatable manner.
- Have fun.
At the latest
Agile Alliance board meeting members were asked to imagine what they would say if they were opening the Agile 2012 conference. I'm encouraged by the closing statements regarding the future of agile methods made by
Brian Marick in his
imaginary speech to open Agile 2012:
Agility cuts against the grain [of command-and-control]. It's about devolving authority downwards and creating openness and transparency. The Agile Alliance, to some extent, did not try to solve the 'middle manager' problem. We left it to others and that's a bit of a shirking of responsibility. A lot of people out there today who call themselves ScrumMasters still think of themselves as managers, and think of the job of management as command-and-control. We, in the agile world, will never succeed in transforming organisations into better places to work until we deal with command-and-control.
That time has come. We all need to do more to help companies that want to achieve agility move away from
command-and-control and, invariably, change their culture too. Clearly this is not an easy task but it's not one to shy away from either. It will be challenging and there will be failures but that's not enough to stop me trying and persevering. There's too much at stake.
Tags:
command-and-control
Links to this post
My take on 'The Perils of Pair-Programming'
Yesterday I read
Matt Stephen's article about
the perils of pair programming. Let me prefix what I'm going to say with this: Pair-programming isn't for everyone. It's uncomfortable and scary at first. And when you're used to it it's intensive and bloody tiring.
There's a gazillion reasons why people don't like pair-programming. Some people don't like the intensity of pairing. Others can't sustain the rate of interaction and burn out over time. There's no shame here. What is disappointing is that some people feel exposed when they pair, "the other person is constantly watching what I do and judging me!" They never quite grasp the fact that it's not about them. They're not being tested or judged. It gets worse when egos get in the way. Some people think they're a good programmer until pairing reveals that, actually, they ain't as good as they thought they were. And rather than take it on the chin, knuckle down and look to improve their skills by continuing to pair, they recoil and make some exclamation about why pair-programming is wrong. And then there's the variety of personal habits to contend with.
Successful pair programming is as much about effective soft skills as it is about technical skills. Each person engaged in pairing needs to be sensitive to the other person, and listen effectively and read their body language; be able to convey ideas, engage in constructive disagreement, offer alternatives without judgement or condescension and persuade the other person; have the ability to sense when to offer help and be humble enough to ask for it. It's a shame many programmers struggle with these soft skills.
Pair-programming is a social engagement, a conversation, an exchange of ideas between two people working together to solve a problem incrementally. It's both a technical and social learning experience. Having seen pair-programming work (and I do say, it works), I believe that the design cycle of
test-driven development:
test-code-refactor is simply more effective when one person is focused on tactical solutions while the other is continuously framing them strategically within the bigger picture of the system.
Ok I haven't said anything new here, so back to the article.
First, I want to make a general comment about the article. When I read it, I heard a lot about the individual and nothing about the team. I know the article is about pair-programming but the practice needs to be viewed within the broader context of achieving agility. And for me the concept of team is a key part to achieving agility.
Matt starts with:
Pairing with a slower programmer isn't merely frustrating for the more productive programmer: it's slowing him/her down, which in turn is slowing the project down, because s/he isn't getting as much done.
Yes, this can be frustrating for the faster programmer. But, quite frankly, he needs to work through it because he knows it's about what the team has committed to and what the team can achieve collectively. It's not about him nor his productivity. All the metrics being tracked on
burn-up charts relate to the team's delivery of business value. He should see the time spent with the other person as an investment in the team. The other person will hopefully respond and improve over time, and will eventually bring more to the team and become a more effective partner. When a person is not pulling their weight and is not working constructively with the others to improve, an empowered team will demonstrate some form of
self-selection to deal with that person appropriately.
Matt says:
Of course, it isn't the slower programmer's fault. He may be a junior coder, paired up with a senior developer for an hour or two each day in the hope that some of the senior's lifetime-accumulated wisdom and eruditeness may rub off on the little tyke.
What's to say that
lifetime-accumulated wisdom and eruditeness makes a senior programmer a good programmer? Both people engaged in a pair can and will learn from each other. Don't under-estimate the fresh perspectives of an inexperienced programmer.
Matt says:
Preferring to have some peace and quiet to program does not a bad programmer make: in fact, I'll stick my neck out and say that this preference is a good indicator of a damn fine programmer.
I agree with everything up to the colon. Just because someone wants to work on his own does not make him a bad programmer. But wanting to work alone is defintiely not
a good indicator of a damn fine programmer. A bad programmer might also want to work alone and he might be hacking away at pace, but he will still exhibit bad coding habits and make poor design decisions.
Matt says:
It's indisputable that some pairings work better than others... agile aficionados have an answer: pairs must rotate partners frequently, so that ill-matched/inefficient pairs aren't sat together for too long.
My motivation for encouraging frequent pair-swaps is to promote the sharing of knowledge amongst the team, not to avoid or minimise the effect of
ill-matched/inefficient pairs. I'm always interested to observe what happens when a pair involves 2 people with an interesting combination of
myers-briggs types. As a coach you watch for these situations and facilitate appropriately.
Matt says:
But crucially, not everyone likes pair programming. Not everyone is naturally extroverted or a social butterfly that will wither away if he doesn't get to chatter to his colleagues for eight hours a day.
It's not as simple as being extrovert or introvert. I've worked with excellent pair-programmers that are introverted. I think there are deeper personality characteristics at play here. For example, having the courage to show vulnerability, fallibility and imperfection, to make mistakes in front of another. And trusting the other person to help and not ridicule or blame. In a trusting relationship, people will communicate.
Matt asks:
So if many good programmers are not naturally inclined to pair program, how do you find the staff?
What's important is that people are willing to try it for a period of time before dismissing it, and give it a fair shot of working. In my experience, people who fit well into an empowered team working in an open and trusting environment usually take to pair-programming. They remain objective and recognise both the benefits and the drawbacks, and then work to adapt and improve how they employ the practice.
Matt says:
[Pair-programming] certainly requires strong, constantly attentive management.
Management? No! Coaching, yes! For me, if a team is being managed it's in a
command and control environment and is not
empowered. I haven't yet seen a team achieve agility in such an environment.
Matt goes on to say:
Making [pair-programming] mandatory 100% of the time, and expecting a mixed-ability team to sort out their differences in abilities and still be highly productive, is just asking for trouble.
What's asking for trouble is
making people do something. We're back to management.
Command and control elicits compliance to enforced processes. When I work with a team I facilitate a
chartering session in which they decide on the working practices to be used. The team I was working with used pair-programming for all the code destined to hit the subversion repository (and ultimately the production servers). This equated to around 95% of the time they spent programming. When the project started, not everyone had tried pair-programming and some were nervous. But during the
chartering session they all decided that they wanted to try it for 4 weeks. Now they're hooked. The team decides how it wants to employ pair-programming. As the coach, I talk to them about the risks of not doing it and simply ask them not to dismiss it without first trying it.
One final thing. Surely a continuous code review performed in context and privy to the many small design decisions made on route to the solution has got to be more effective and have a greater influence on the quality of the implementation than a code review performed after the solution is attained?
Tags:
pair-programming
Links to this post
