|
|
This previous blog entry exhorted you to go out and talk to your friendly neighbourhood business person.
What will you talk about? A good place to start is to discuss the cost and value of what you’re doing. One of the most powerful tools of XP is “The Planning Game”. You sit down with your customer(s) and decide which features you’re going to implement in the next release. To do this you need:
- Index cards with a “story” each. The card contains a brief description of a feature, just enough to remind developers and customers of the important points of the feature, which they have discussed before and both understand.
- Each card contains an estimate of the required effort to implement the story. Different teams use different units for their estimates: mandays, hours, “ideal days”, gummibears… I just use a scale from 1-6 “story points“
The index cards are easy to lay out on a big table, you get an good overview, it’s easy to move them around. The aim of the game is to define an implementation plan that will generate the highest possible value with the least cost. How do we do this? We already know the cost (albeit in “points”. What’s that in the “real world”?). What is the value of a story? Well, that’s a question for the business people to answer.
Business people have to estimate the potential business value they can gain by putting this story into production use. How do they do that? I use a very simple process, the same one I use to estimate the cost of the story:
- Sort all stories from low to high value, by taking them one by one and comparing them with the stories that have already been sorted.
- When all stories have been sorted, check if the ordering seems correct.
- Give the lowest value story 1 point. Give the highest value story 5-6 points (or whatever maximum you set on value estimations). Don’t use a range that’s too big:
- It might give an impression of precision where there is none
- If some stories are really worth 100 times more than others, why are you wasting time on those stories with ludicrously low value?
- Group the remaining stories in groups with roughly equal value and give them values between 1 and 5. Each story now has an estimated “business value point“.
- Done!
And now planning becomes very easy… Just pick the stories with a good value/cost ratio.
How long does that take? I just did one for a 2-month release with 4 developers and about 30 stories. Estimating costs took two sessions of almost an hour. Estimating value and planning the release took a little over an hour. Let’s say 3-4 hours to estimate and plan a 2-month release. YMMV.
It doesn’t cost a lot of effort to estimate your stories’ business value, but it has some interesting advantages:
- Planning becomes a lot easier
- It makes everybody think hard about the value of each story.
- Some features turn out of to have little or no value. Why should we waste our precious time on them?
- Some features turn out to have a lot more value than technical people would expect.
- Tracking value sends a powerful positive message: we are adding value to the organisation. IT is not a bottomless pit where you pour resources in. IT is a system that generates value for a given investment.
- It clearly delineates the responsibilities of developers and business people
- The developers are responsible for keeping the cost of the stories low
- The business people are responsible for finding and selecting high value stories
- You will know it’s time to stop the project when the added value of the next release is low.
 This is the output of the second group. The “bottleneck” of this system is easy to spot: everything has to go through 2 people. The stacks of work in front of each person indicates how much work in progress accumulates in front of each resource.
Click to enlarge the image
(picture courtesy of Marc Evers)
Some remarks
The goal of the system is to “add functionality” to an existing system. This functionality creates value only when it’s delivered to the customer. But that seems to take an inordinately long time, as the snoozing customer would indicate.
The bottleneck is the Development Manager (DM), with the Project Manager (PM) as bottleneck-in-waiting. All the work has to go through these two people. In the case of the Development Manager, all work goes through them several times: the DM carefully prepares and assigns the work to the developers, helps them design and develop and then the work has to come back for review(s).
How can we improve this situation?
- Currently, the PM explains the required functionalities to the DM. The DM then explains the functionalities to the developers. We could exploit the DM by having the PM explain the functionalities to the DM and developers at the same time. This could help break the “barrier” which now exists between business and development.
- If a few developers have more experience, they could subordinate to the DM by helping other developers and reviewing their code.
- We could elevate the constraint by hiring someone else to take on some of the duties of the DM or by training the most experienced developer(s) to take on some of the DM work.
However, these interventions might not be easy. It’s a stressful, difficult job, being the bottleneck. But it also make one very important. Having to delegate some of the work might be seen as “not being up to my job” or reduce the bottleneck’s importance.
The “barrier” in the system could be caused by the DM wanting to “shield” the team from the rest of the organisation. This way, the DM controls everything that goes in and out of the team. Some of the TOC interventions might reduce the amount of control the DM has. This too might be a touchy subject.
I do have a question about this diagram. How does the software get from the developers to the end user? We saw that the code goes back to the DM, for review. What happens next? Is there a Q/A procedure? Does the software get packaged, distributed or installed?
It’s not every day one gets called a freak.
But it’s all in a good cause, including the bullying 🙂
But then, being called a “dude” more than makes up for that. When I grow up, I want to pursue the “Dudist Way”. But first, I have to finish the “Toyota Way“.
But seriously… We need to make an effort to be taken more seriously. All that “freaky”, extreme, surfer-dude stuff is great to attract the “innovators”, the people who are attracted to new, shiny toys. But that phase is over, as Jutta Eckstein said at XP2005.
So, who do we approach now?
- Project Managers? Yes, but only the ones who have a problem. Those “who don’t have problems” don’t need us, they’re doing fine. Do you know a project manager who has difficulties ascertaining the true state of their project? Who has trouble meeting their deadlines? Who has quality or morale problems? Brittle software? Requirements shifting like sand dunes? Talk to them. Ask them “what’s your worst problem?” See if you can find a potential solution and try it out.
- IT Managers? Most of those that I meet don’t have any problems. Well, except customers… If we didn’t have those, life would be great. Yes, but the dole pay sucks.
- IT Architects? They’re too busy inventing Rube Goldberg contraptions in their ivory towers to have problems. No problem, no sale.
- Marketing Managers? Yes. Talk to them and ask them what they would wish from IT. A way to really steer the content of the software, without spending countless hours listening to technical mumbo-jumbo? A way for customer feedback to be translated quickly in changes to the product? Being able to see and show running, stable systems almost from day one of the project? Who knows, you might be able to grant them one wish…
- Sales Managers? Yes. Talk to them and ask them what they would wish from IT. Being able to know when the software will be released and what features will be in it, so that they can make reliable promises to their customers? A way to delight their customers by responding rapidly to their wishes and frustrations? Create value by early delivery? Having confidence in the consistent quality of the system? Who knows, you might be able to grant them one wish…
- Finance Managers? Yes. Talk to them and ask them what they would wish from IT. Would they like to make regular small IT investment decisions instead of pouring sacks of money into mega-projects that (might) deliver a long time in the future? Would they like more insight in the state of the project to make their investment decisions? Would they like to see the system delivered earlier, so that they earn (part of the) value sooner? Would they like better insight in the costs and value generated by projects? Who knows, you might be able to grant them one wish…
- Human Resource Managers? Yes. Talk to them and ask them what they would wish from IT. A way to keep people motivated and working at their best? A way to build and sustain high-performing teams? Who knows, you might be able to grant them one wish…
- The CEO? Yes. Talk to them and ask them what they would wish from IT. A way to have IT strategy and execution integrated with the rest of the company’s functions? Integrated and clear investment plans that show how IT delivers value to the company? Reliable execution of the company’s plans? Having a clear insight into the real state of each project and being able to react when new information is gained? An organisation that keeps improving? Who knows, you might be able to grant them one wish…
Do you want an agile business? Agile Software development is not enough.
 |
Go out and talk to the business people in your organisation.Which wish will you grant? |
I’ve got a few pages online about the Theory of Constraints session at XP2005. I’ll add some more, as Marc Evers has sent me some great pictures with the participants’ posters.
The session had two parts: a simulation that we use to let participants experience the Theory of Constraints and the 5 focusing steps; and a workshop where participants had to apply their Theory of Constraints knowledge.
The participants worked in small groups. One per group played the “customer”, whose system we wanted to understand and optimize. The others played the role of TOC consultants, applying the focusing steps to help their customer improve their throughput. I’ll put the three group’s posters online, with a discussion of the system and results. It was very rewarding to see how quickly everybody managed to apply these ideas and come up with some fresh approaches to problems the “customers” had been struggling with.
But that’s not what this entry is about. This entry is to announce the start of a new series to describes the results of the “Toyota Way” session at XP 2005 and Agile Open.
There! Now it’s announced to the world, I can’t not write it up. No more “Student syndrome”, exam’s up! 😉
Oh no! Right again…
Only a few session proposals had arrived a few days ago. Lots and lots and lots of proposals came in the day of the deadline. Student Syndrome in action. I sent in my proposals an hour or two before the deadline. Useful things, those arbitrary deadlines 🙂
Some people needed a little coercion before proposing a session. Hosting a session at a conference can be a bit scary the first time. The next times it’s still scary, but at least you know that you’ll survive… I hope that reassures all those who proposed their first session.
A community such as the “Agile community” or the “XP Days community” needs to spend time finding new people, new ideas, fresh blood. There is a danger that many of the sessions at the various XP Days (e.g. in the UK and in Germany) are given by a small group of “Usual Suspects”. And many attendees will be familiar faces too.
On the one hand, this is great: it’s always nice to meet these people from all over the world, to discuss the things we’re passionate about or have a drink and a chat. I feel as if we’re pulling eachother up by our bootstraps.
On the other hand, we risk becoming a “closed club” discussing weird, “touchy feely”, “arty farty”, “namby pamby” stuff like Systems Thinking, Cynefin, Appreciative Inquiry, Congruence, Theory of Constraints. “How will this help me write better software tomorrow?“.
That is one of the challenges the program committee for XP Day faces: how to create a program out of those many great session proposals, that satisfies the needs of both beginning, intermediate and advanced attendees? Each one with their own unique preferences, environment they work in, challenges they face, answers they seek.
In a workshop on “Communities of Practice (CoPs) at SPA2005, we discussed a few patterns for creating, sustaining and growing communities. One of these patterns (note to self and Laurent: we must write these up somewhere), is called “CoPs Pull You In“.
If a community is to thrive it needs an influx of new ideas, new people. And yet, a thriving community can seem “closed” and “unapproachable” from the outside, because those inside have developed their own rituals, protocols, language and trust. Therefore, CoPs need to “pull in” new people. “Pull In” can be understood in two senses:
- People inside the CoP need to make a conscious effort to help people outside understand what the CoP does, how it works. They need to assist people who want to enter the CoP, to introduce them to others, to show them how things work. We see this in (session proposal) writing, where people act as “shepherds” to help newcomers. Or we can assign a “buddy” to a new hire to make the entry into the organisation smooth and productive.
- There must be something in a CoP that is attractive to the newcomers. A strong “attractor” that pulls people into the core. As someone at the workshop noted: “one can’t be pushed into a CoP that one doesn’t find attractive“
How do you help people get “pulled” into the community? I do it by bullying people into sending in session proposals 😉
|
