|
|
 I spent a nice day at Agile North in Preston, on Sepember 20th. The Agile North group organized this one day Agile conference.
Rob Westgeest and I met at Manchester Airport with Kevin Rutherford, who drove us deftly to Preston, just before the approaching traffic jams.
The conference started with a keynote by Rachel Davies, current chair of the Agile Alliance. The talk told us how Rachel got into agile software development and her advice on moving to agile software development. Her theme was a common one among experienced agile practitioners: it’s about the values and principles. You’ll have to tailor the practices to your own situation. Start with a documented agile methodology, any methodology, the one that seems to fit your environment best. Start delivering and reflecting upon what you do. Adapt the method. And again. Use retrospectives for the reflection part (more about that later).
The first session was a goldfish bowl, organized by Charles Weir (on the left of the picture, seated on the table) about “Dealing with Customers”. Unlike most goldfish bowls I attended, this one was relaxed and featured some interesting discussion and tips on how to work effectively with customers. The audience had a nice mix of experienced people who could tell stories of success and failure, and people new to agile, looking for ways to improve their customer relationships.
The session was not about great ideas and breakthroughs. Most of it were small, simple ideas that everyone could apply, few of them specific to agile development. It does take sustained effort to create and maintain a great customer relationship. And again, the advice was to solve your worst problems (or bottlenecks) and to adapt to local circumstances.
I would have liked to attend the Rails session too, but you can’t be in two places at the same time…
 After lunch, Rob and I organized the “I’m not a bottleneck! I’m a free man!” session. In this two hour session, we first introduce the “5 focusing steps” in a simulation, where the participants are asked to implement a paper boat and hat folding company. The workers got paid in chocolates.
In the second hour, some people come forward with a process that they want to optimize. The other participants act as Theory of Constraints consultants, coached by Rob, Kevin and me.
In the picture, Kevin proudly displays the result of his team: at least one way each to “exploit”, “subordinate to” and “elevate” the bottleneck of the customer. This particular system has a loop in it: software is tested and if it is defective, it is fixed and tested again. If you’re going to map this process to find bottlenecks or make a “value stream map”, it’s easiest if all the loops are unrolled and you get a linear process. How do you unroll the loop? You could take the average situation (e.g. it takes one fix-retest cycle on average); you could take a specific examples (e.g. feature XYZ went through 3 fix-retest cycles); or you can put a fork with probabilities in the diagram (e.g. 80% of all cases do not need retesting, 15% need one fix-retest, 5% need two fix-retest cycles).
The last session of the day was about agile in large organisations. I was quite interested, as I currently work for a largish organisation myself. The presenter didn’t get to finish his story, because there was a rather large amount of push-back and questioning from the audience. I didn’t get the message of the session. I’m still interested in the subject, so I’d like to see the rest of the slides.
Finally, we had a panel, where the audience could ask the “experts” questions. Rob and I had to decide which one of us would be on the panel. Rob lost, so he had to answer all the difficult questions 🙂
Agile North ended with a quick pint at the pub (kindly sponsored by Kevin) and an even quicker drive back to Manchester to catch our flight back to Belgium. All in all, a good conference, nice turnout, well-organized, interesting sessions and discussions with other participants. Thanks to the organizers for inviting us. I’ve enjoyed the conference, hope you have too!
Agile Open. Day Two.
We planned to start day two with a re-planning session: look at the plan we made yesterday and adapt where necessary, based on new information. Raphael then asked the question if we shouldn’t try to go more with the “open space” idea, instead of having planned sessions. We decided to have a planned session in one track (the XP Game) and an unplanned session in the other track.
That meant I got to play an XP Game for the first time, after having hosted so many runs. I discovered I’m crap at inflating and putting knots in balloons. Halfway through the game I had to leave for the next session. This gave my team the opportunity to learn what you do when 1/4 of your team leaves: you reduce your velocity to 3/4 of what you produced in previous releases.
Metrics and Thoughput Accounting
I proposed this session to get some input. Throughput Accounting has basically three important variables, expressed in monetary terms for convenience:
- Throughput = fresh money coming in from sales
- Operating Expense = money going out to keep the company going. Once spent, the money is gone (wages, energy, rent…)
- Investment = money that must be put in to be able to generate value. This is the most tricky category to explain.
Of course, time is also involved. The longer the time it takes to generate throughput, the higher the investment will be. To emphasize the fact, I keep time as a separate variable. All these variables are pretty easy to measure at the company level. We want to align the work we do with an improvement in these company metrics: increase throughput or decrease time, investment or operating expense.
The goal of the session was to find some metrics or indicators at an individual (IT) project level. We brainstormed some potential metrics for each of the 4 throughput accounting variables.
The throughput accounting variables and formulas are very simple. The only problem is that all the variables are interrelated. If you change one component of I, it’s going to have an effect on t, T and OE. And vice versa. You can’t really create a mathematical model of a project, but you can apply systems thinking. The advantage of methodologies with short iterations or releases is that you shorten the feedback loops, thus making it easier to see the result of your action and react in time.
We didn’t come to a conclusion. I’ll have to do some more thinking about it. Expect some throughput accounting posts in the near future…
Henrik MÃ¥rtensson has developed a simulator of a development team to demonstrate some Theory of Constraints concepts. And it’s in ruby too!
He’s written a series on the “Variance Trap“, where he demonstrates the effects of variance on systems throughput, using the “bead game” and the simulator.
There’s a whole series:
- The Variance Trap
- Flow-based prediction of throughput
- Statistical Fluctuations Game, introducing the simulator
- The effect of fluctuation size on completion time
- The effect of iteration size on completion time
Well worth reading!
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
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
|
|
