Time to abandon what has failed
More and more software will be behind schedule, over budget, underpowered, and of poor quality - and there's nothing we can do about it. - Bruce Webster, Byte Magazine 1996
What's surprising - astonishing, in fact - is that many software engineers believe that software quality is not improving. If anything, they say, it's getting worse. It's as if the cars Detroit produced in 2002 were less reliable than those built in 1992.
- MIT Enterprise Technology Review, June 17 2002
The
mass production paradigm has failed the software industry. The improvements to cost-effectiveness and the reduction in inefficiencies by focusing on methodologies, processes and tools have not materialised.
The characteristics of mass production include repeatability, large infrastructure, organisational gigantism, efficiency, and techno-centrism. Repeatability relies on the interchangeability of parts, including workers.
Division of labour fragmented worker occupations into specialised jobs so that a worker could be replaced with a new worker of the same description, in theory, preventing production from slowing down. A large infrastructure with more capacity grows from the pursuit of
economies of scale and allows the amortisation of production costs across production volume to provide greater return on capital investments. But a large infrastructure requires a large organization to operate it and this costs more. The best way to reclaim these costs is to keep people continually busy and, in software development, the best way to keep them busy is to have them multi-tasking across lots of projects. Efficiency means keeping the infrastructure operating constantly under full load with the machinery and workers perpetually busy. But the focus on efficiency means there is little tolerance for stopping to correct systemic problems that permit or cause defects. The obsession with efficiency leads to centralisation and departmentalization based on roles and a dependence on after-the-fact detection, remediation and acceptance. It pays lip-service to improving quality and reducing defects. The cost of rework and the loss of flexibility in being able to respond to customers and the marketplace is significant. In their quest to maximize efficiency, organisations adopt more infrastructure and tools but it's really using technology for technology's sake. The software industry likes to look to bigger, faster, more complicated tools as way to meet schedules.
If a little medicine doesn't make the patient better, keep increasing the dosage until it does. The strategies of mass production, which aim to contain chaos through task and worker specialisation, process standardisation, hierarchical structure, and command-and-control management simply don't work. But old habits die hard.
Tags:
mass production,
efficiency,
centralisation
Links to this post
Inconspicuous leadership
A leader is most effective when people barely know he exists.
When his work is done and his aim fulfilled, they will say: 'We did it ourselves.'
- Lao Tzu
Tags:
leadership
Links to this post
Collaborate more to achieve hustle
Our team has been together now for about 15 weeks and things are going well. We've got a
sustainable pace that's delivering value every week, our Product Owner and Product Sponsor are both happy, and everyone is having fun. So what's bugging me?
Well, it's 2 things. First, I've been sensing that there is additional capacity in the team that we haven't been able to tap into. And second, we've not been able to sustain our
hustle for anything longer than a few days, perhaps a week. Reassuringly, over the last few iterations, the team has become aware of our inability to sustain hustle and in the last retrospective the team described its overall performance as pedestrian. That's a harsh word to describe an experienced agile team but its use demonstrates that the team isn't satisfied with its current pace and supports the idea that there is more to be had.
Can we tap into the additional capacity I think is there by sustaining hustle? I think so and I believe the key is more intensive collaboration because it creates a buzz. We've already seen improved collaboration by
slicing stories more. This has created more frequent opportunities to obtain feedback from testers, the Product Owner, and the customer. It generates more conversations. We've also got our new
bullpen layout removing the physical obstacles presented by pods of desks. This has given us the space to huddle and have
timeouts, it allows people to move freely throughout the team area with chairs whizzing across the floor, and it facilitates conversation and
osmotic communication. But I feel the big win will come if we pair more promiscuously. In his paper on
promiscuous pairing,
Arlo Belshee reported:
Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels - and allow someone else to take over for his weaknesses.
Each of our practices provided the team with more flexibility and better communications. More creative ideas were formed, and each idea was automatically disseminated to the entire team by the end of the day. Each person was expected to continuously learn what was happening and contribute in a very short amount of time. Working on this team often felt like drinking from a fire hose, but it was empowering.
The data shows that we were more productive the more promiscuous we were - as long as we remained with each partner long enough to exchange knowledge. What they don't show is that we also had a lot more fun. It took the team a little time to adjust to the more rapid pace, but working with that team was a career high point for every person involved.
I know promiscuous pairing will generate a buzz, I've experienced it with a previous team. But it will also consume energy. Ron Jeffries
wondered whether hustle was sustainable citing success and rest as the key regenerators of the energy required for hustle. I believe we can sustain hustle if we continue our strategy for
energized working, and we're already achieving success every week by delivering what the Product Owner prioritises. But, because we have 3 more weeks before we go live, visibility of success is restricted to the
showcases and a demonstration environment (which is treated like a production environment). Somehow this diminishes the feeling of success (especially when you achieve it week in, week out). When we're live we'll be able to deploy to production every week and users will see a flow of new functionality. That's real success and that ought to help us sustain hustle too.
Tags:
hustle,
collaboration,
energized work,
pair-programming
Links to this post
From humble beginnings
It's only taken 4 months! It's been an excruciatingly painful process and having to deal with furniture police and a
jobsworth here and there has required persistence and the patience of a saint.
But look at all that space in the middle for people to huddle and have conversations. It was worth the fight and worth the wait.
Tags:
bullpen,
planning board
Links to this post
What's The Prime Directive really about?
An interesting conversation surfaced on
InfoQ that
questioned the Retrospective Prime Directive. I've paraphrased a lot of it here.
The
Prime Directive says:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
But we've all thought it - what about those people who aren't doing their best, who aren't pulling their weight, those people who are, from your perspective, being deliberately obstructive? Such people do exist although many would argue, that in their own way, they are trying to do their best. It's important that we recognise that our observations are subjective and are influenced by our prejudices.
The retrospective is about the collective retelling of a story for the purpose of learning and it's difficult to learn when people are blaming each other. It's much easier to influence someone or learn from them if you haven't written them off. The retrospective is not the place to conduct performance reviews on individuals. Keep that for
one-to-ones. The Prime Directive asks us to suspend all of our suspicions and judgments about others for the short time that we are in the retrospective allowing our brains to focus elsewhere so that the team might just learn something.
Tags:
retrospective,
prime directive
Links to this post
