|
|
Finally, success!
Imagine this scenario: your development team has never been able to keep up with customer demand. Or quality was never good enough. Or your users felt that you never really built what they needed.
But, you’re working hard to improve your team. You’ve read the white book, the green book, the purple book… Your bookcase is full with agile books of all colours of the rainbow. You’re solving problem after problem by applying the agile advice.
Your team’s velocity climbs steadily up. Team morale goes up. Your customers are getting happier after each release. You feel you can almost implement your customer’s requirements in real time.
This could be your finest hour. This could be your worst nightmare.
What could possibly go wrong?
Your team is the bottleneck, the constraint. You elevate the constraint by improving the way the development team works. What happens next?
The bottleneck shifts.
Before you know it, your customer can’t give you new stories or write acceptance tests fast enough to keep you supplied with work. You won’t notice it at first, as you chew away the backlog your customer has built up. By the time you notice, your team is starved of work.
Before you know it, your customer can’t handle the flood of new features that you unleash in every release. It didn’t matter before that software distribution wasn’t very fast or that training wasn’t effective. The users didn’t notice that a release was skipped as there were few features per release anyway. The users could learn those few features per release on their own.
You are no longer the bottleneck. Someone else is. And then all hell breaks loose.
Surfacing old problems
As long as the development team was the bottleneck, other teams’ problems didn’t surface. They had no motivation to improve. But now, the spotlight is on them. And they don’t like it. You might even be blamed for causing those problems.
Now that your development team has some spare capacity, the Theory of Constraints tells us you should subordinate to the new constraint, by helping the new bottleneck. But, then you’re faced with two new problems:
- The new bottleneck team probably doesn’t want to be helped. Please do not inflict help on someone who has not asked for it.
- You’re operating out of your knowledge zone. The XP book won’t help you solve sales problems. The Scrum book won’t help you solve customer support problems.
Preparing for failure
If you’re lucky, you aren’t successful yet. You can take action now to avoid or mitigate the problem in the future. Start preparing for the worst now, because you know you will be successful if you keep on doing that agile stuff.
What can you do?
- Try to detect candidate bottlenecks before they arise. Subordinate some of your team’s time to help the bottleneck in waiting to elevate it’s performance. For example, to avoid the problems described above, I like to dedicate someone from the team to follow up a whole release, from stories to production, subordinating to whoever is involved. Once a release nears production, someone else starts working on the next release. Keep the team working at full capacity. Keep the bottleneck under your control.
- Learn a bit more about the other teams’ work. You’re going to need that knowledge to understand their bottleneck and to help them. Stop reading those agile books. Read a book on sales, on marketing, on operations or even on accounting (I can recommend a great book on accounting). You might not need it, the bottleneck might shift elsewhere, but it’s never too late to start working on a more well-rounded education.
- When I said “the XP book won’t help you solve…“, that wasn’t exactly true. The practices aren’t that applicable outside of development work (except for pairing, which seems applicable to most creative work). But the principles have helped me solve problems in areas I didn’t know anything about.
Communication, courage, simplicity, feedback and respect, it’s not just for IT.
Just do it
You know it makes sense. It could happen to you too. Where does your bottleneck want to go today?
Tags: Systems Thinking, agile, Theory of Constraints
In one word: THINK!
Dave Thomas gave an amusing keynote, with a great, clear visual style that’s all the rage in geekland: little text, large fonts and beautiful images. He also had some nice effects: scrolling code, pages that looked as if they fell over. One sentence seemed reluctant to appear. Dave had to encourage it a bit. I’m not a fan of presentation effects (probably because I’m unable to do them well), but these effects worked. Enough about form, on to substance. Dave talked about “Cargo Cults” and “Angry Monkeys”.
Cargo Cult stands for every situation where we blindly copy something, without understanding it, to get some positive effect that we’ve observed. Angry Monkeys stands for every situation where we blindly do something, without understanding it, to avoid a negative effect that we’ve experienced.
 Dave gave several examples of both systemic problems, reflecting his interests and preferences: real object orientation, dynamic typing, agile processes… He could have put up just one slide with, in big friendly letters: “THINK!”. But that wouldn’t have been as much fun.
There is only one practice
What came out of this keynote tied in with what Norm Kerth told us: perform regular retrospectives to improve your team, your practices, your process(es) and your process-changing process.
Hansei. Kaizen.
Evolution at work
Some of what Dave said resonated with Richard Dawkins‘ writing on evolution:
- You can’t capture everything in a taxonomy. There are no species; no classes. There are only individuals with sets of genes; objects with state and behaviour. Some of those individuals/objects are so similar that you can lump them together, but you’ll always encounter Duck-billed Platypuses.
- Evolution is a powerful tool. Luckily for us, we don’t have to wait millenia, we can guide evolution. Sometimes, we even succeed in improving the system, as we learn more. But, in the end, it’s always the world that decides if we are fit enough to pass on our genes.
During the train journey back to London, Duncan Pierce suggested that agile metrics should measure the “fitness criterion” of our process.
Tags: Systems Thinking, agile, SPA 2006
Tuesday
Norm Kerth’s keynote looking back on 5 years of Retrospectives wasn’t surprising if you read the book or performed retrospectives. Many (most?) people in the audience have done or want to do retrospectives. Norm gave a great overview of Retrospectives and the results he and other retrospective facilitators have achieved. Performing retrospectives is good for the health of your team, the results of your project and your career. A simple and effective way to improve your process is the only thing you really need in your process. Everything else you need, will be introduced if and when you need.
An interesting and fun session about Product Managers. In the workshop we looked back at experiences with Product Managers. From these experiences, we determined what a product manager needs to do and what qualities we’re looking for. It is a very difficult job, juggling all those (possibly conflicting) demands.
Clarke Ching just wrote a blog entry about a book on “Agile Product Development”. Maybe worth checking out.
After a nice walk in very windy St Neots, off to Richard Mitchell’s session on modeling with views. Instead of making one big domain model, Richard creates smaller models, specifically for one (type of) domain specialist. He can then combine them in one, consistent model.
We talked a bit more about the theory of constraints and its application in software development. And then it’s time for the traditional last evening diversion. This year we had a wine and cheese tasting. Most people seemed to prefer the wine to last year’s Belgian beer. Apparently, Geuze Lambic is an acquired taste…
Wednesday
First, get some work done: handle registrations for Agile Open. If you want to attend, don’t wait to long to register, because we limit the number of participants to 40.
I’m looking forward to Dave Thomas’ keynote. “Cargo Cults and Angry Monkeys” sounds very interesting.
Read more at http://www.spaconference.org/cgi-bin/wiki.pl
Tags: Systems Thinking, agile, SPA 2006, Theory of Constraints, Thinking Processes
Sunday
Attended a workshop on Use Cases. The audience contained both use case users and sceptics, which resulted in some heated discussion. Not unusual for an SPA session. I did get some useful ideas to apply at work.
The day ended with a barbecue and drinks sponsored by Cincom, who valiantly keep on making, selling and using Smalltalk. One day, when I grow up, I want to do a real Smalltalk project again.
Monday
Marc Evers and I hosted the “Thinking for a Change” session this morning. The session went well: 3 out of 4 participants were able to find the root cause of their problem AND come up with some useful things to do about it. The problems were quite diverse:
- a software development coach having trouble communicating and working with the managers of the team
- having a good balance between home life and work
- how to reduce the spiraling costs of change in an application
- a business struggling to find enough money to survive the next few months, until their product is out.
In the evening we did a “Birds of a Feather” session on evaporating clouds. Again, two very different cases. One of them got to a start of a conclusion; the other managed to uncover a whole set of assumptions. To really resolve it, both parties would need to go through the exercise, to get a better understanding of the other party’s position, reasoning and assumptions.
In the bar, after dinner and drinks, I joined another group making a Current Reality Tree and a Future Reality Tree. Today was a Thinking Processes day.
Tags: Systems Thinking, agile, SPA 2006, Theory of Constraints, Thinking Processes
I’ve finally got Jerry Weinberg‘s new book “Weinberg on Writing“.
It’s a thin book and it contains lots of examples and exercises. So far, I found it very easy to read, like all Jerry’s books (with the exception of “Introduction to General Systems Thinking“).
Jerry consistently uses the metaphor of building something out of “fieldstones”. Before you can build, you have to go out and find yourself some fieldstones. You must select the right stones and not be afraid to reject lots of stones.
Hopefully, I will learn to write a bit better. You be the judge…
|
|
