|
|
 I’ve been away at a “Mastering the Requirements Process” course led by Suzanne Robertson of the Atlantic Systems Guild.
I’m looking for a method/process/techniques to gather (or “trawl for” as Suzanne calls it) requirements, to integrate with my customer’s existing process. The “Volere” tools seem quite suitable, especially the techniques to define the context, goal and business events. I often see teams jump directly into defining the product, “what will the system do?”. Before thinking about what, you have to know why.
What is the context and goal of the business in your current project? Do you know? Have you asked? Is success of the project defined as how close you come to the business goal?
What could happen if you don’t have the answers to these questions?
Your product scope might become too large. Feature upon feature gets added to the product. On what basis? How can you decide if this feature should be in or out of the project? How can you prioritize requirement, unless you have some way of guessing how much they contribute to the business goal?
People might disagree about whether the project is succesful. There is a danger with saying “a good product is one that conforms to requirements.”. What kind of requirements? Product requirements? What good is a product that does everything we agreed it would do, unless the product requirements are linked to business requirements. Have you ever been in a project where the customer was dissatisfied, even though you implemented all the requirements? Maybe you misunderstood each other. Maybe you had a different definition of success.
Start asking those business questions today. That means you have to understand the lingo. At least ask “why?” a lot…
In a previous post, I urged you to go out and learn a bit more about non-IT stuff, so that you can talk to the rest of the company. I don’t usually follow my own advice, but this time I have: I’ve bought a few new business books.
 This week I have mostly been reading “Competitive Advantage”. Competitive advantage is a management classic by Michael Porter. It was recommended by John Favaro during his XP2005 keynote.
In the book, Porter dissects the activities of a company in a “Value Chain”. He analyzes how companies can gain and sustain a competitive advantage. A company can either have a “differentiation” or a “cost” strategy.
The book is a 2004 edition, but I was disappointed to see that it’s essentially the 1985 version. And it shows. I haven’t read the whole thing yet, but there are only a few vague references to “methods used by Japanese companies”. For example, if we want to respond to the customer faster, Porter recommends to increase inventory or to get surplus capacity. Ouch! What about reducing inventory, increasing inventory turns, removing waste, establishing flow, reducing cycle time, building quality in…?
 I’m also reading Bill Waddel and Norm Bodek’s “Rebirth of American Industry“. This one is more fun and easier to read than Competitive Strategy. In the book, Bill and Norm describe the history of (car) manufacturing. From the Lean early Ford, over Sloan and Dupont’s definitely not Lean GM and back to Lean Toyota.
Their main point is this: Sloan and Dupont created a management and accounting system at GM that essentially goes against Lean, as it considers inventory an asset and labor a liability. The strengths of the early Ford and current Toyota production system is that they focus on cash flow and empower their employees to continuously improve production processes. The Toyota Production System didn’t spring fully formed from the (brilliant) minds of Taichi Ohno or Shigeo Shingo. They evolved gradually, by solving problem after problem.
The GM management and accounting practices went on to become the de facto methods in American industry. As everyone was doing it, nobody really noticed the inefficiencies in the system. Until the Japanese arrived…
I believe the same is true in software development: there’s something structurally wrong in management and accounting (measurement) of IT projects. These lead us to work in large batches (have to keep those analysts busy!), to count work in progress as value and to have long cycle times. Agile, like Lean, will always be limited to implementing a few easy technical tools that don’t require us to change the way we work (unit tests, continuous builds, refactorings), unless we can change the way we manage and measure. And if the want to do that, we have to speak the lingo. Back to Porter…
We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium.
Early registration for Agile Open 2006 ended on Friday. As usual when you set deadlines, a lot of registrations came in on the last day. Student Syndrome at work. Or is it the “Decide at the latest responsible moment” Lean principle at work?
We’ve now got 24 early registrations, that’s as many as the total number of participants last year. For the organizers, that means we’re in the “good scenario”.
Before every event, like the XP Days Benelux, we perform “scenario planning”. We explore different alternatives and decide what we would do in each scenario. We always have at least 3 different scenarios: “bad” , “normal” and “good”. As time goes by, we compare reality with our scenarios and see which one fits best. Of course, we adapt as new information emerges. We also keep a risk list, so that we know how to react when something bad happens. Both of these practices help us to organize an event without too much stress.
Why not try some scenario planning on your next project? Try to imagine a scenario where everything goes wrong; picture another scenario where everything goes well. How will you react when the different events happen? A scenario is not a prediction, a scenario helps you to recognize important events early and to be ready to react appropriately. Of course, you keep updating your scenarios and risk list as you get more information.
If you want to attend Agile Open, don’t wait too long to register, as there are only 16 places left.
p.s. What’s that “A princess arrives…” risk about? During the second XP Day, we heard the day before the conference that a Belgian princess would attend another event in the same location. Due to security reasons, we couldn’t have one of the rooms we had booked. Unfortunately, the replacement room we were offered, was quite far away from the other rooms. In the end things got resolved and we got all the rooms we had booked.Lesson learned: even if you do risk analysis beforehand, stuff will happen. From now on, the Princess is always on our risk list: both Belgium and The Netherlands have princesses. The Princess risk stands for any event where we can’t get the rooms we booked. We’re prepared for that. What new bad stuff will happen this year? Stay tuned…
Tags: agile, Agile Open, Open Space
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
|
