|
|
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? |
Sessions are gushing in for XP Day Benelux 2005. There’s still a little time left to send in your session proposal.
We’re now organizing them on the session review site. Session reviews start in a few days.
Session reviews for XP Days Benelux are unlike most other conferences’ reviews, they’re more akin to an “Open space” process. The review process as we use it now, was first applied by Vera Peeters as Workshop Chair for XP 2005. It goes something like this:
- Session proposals are collected on a wiki. Session organizers get access to this site.
- Each session organizer is expected to review 3 sessions, distributing reviews in such a way that each session is reviewed by 3 reviewers. You are not allowed to review your own session.
- A first round of reviews is held
- Session organizers can update their proposals, based on the feedback they receive from their reviewers.
- A second round of reviews is held, after which the final session evaluation is given.
We apply ideas from Oscar Nierstrasz’ Identify the Champion pattern language (specifically the Make Champions Explicit pattern): a reviewer scores the proposal using the following categories:
- A: Good proposal. I will champion it.
- B: OK proposal, but I will not champion it.
- C: Weak proposal, though I will not fight strongly against it.
- D: Serious problems. I will argue to reject this proposal.
A set of acceptance criteria has been established beforehand. Session reviewers evaluate how well the session meets the criteria.
This process uses several agile components:
- All work is done in an “Open Workspace”, a wiki where reviewers and session organizers can exchange ideas and “overhear” each other’s conversations.
- The process is completely open: everyone sees what you write, you see what everyone writes. Organizers and reviewers can communicate (through the wiki or offline) about the sessions, to ask questions, clarify unclear elements…
- The review process is not confrontational, but cooperative: reviewer and organizer work together to come to the best possible session.
- The process is iterative: session organizers can improve their proposals based on the feedback of their reviewers and their new insights. There are two rounds of reviews, and there are plenty of opportunities for small, incremental improvements to the proposals as questions and reviews come in. Your session proposal doens’t have to be perfect first time, there’s room for improvement.
- There is a constant reflection (Hansei) and improvement (Kaizen) of the review process, by suggestions from participants and in a retrospective at the end of the process.
- Acceptance criteria are defined beforehand, a “customer” (here: the reviewer) determines if the criteria have been met sufficiently.
- Maybe not “agile” per se, but important for me: the process only uses “low-tech” technology: a wiki, email and a simple web form to submit proposals. Nothing too complex or restrictive, just enough structure to enable participants to collaborate effectively; not so much to stifle their creativity and communication.
Don’t forget to send in your session proposal for the XP Days Benelux 2005 conference on 17-18 November 2005 in Rotterdam, The Netherlands.
The Call for Sessions closes on July 11th.
I’m just about ready to send in my session proposal. Are you?
I’m still (slowly) adding stuff to the Theory of Constraints series on my site.
There are 5 focusing steps:
Okay, that’s really 6 steps.
Is that the end of it? At the XP2005 session on the Theory of Constraints we discussed a further step when the “5 Focusing Steps” run out of steam.
More about Step 6 tomorrow.
And then I’ll write up the results of the Toyota Way session at XP2005
It’s more than a week since I’ve come back from XP2005 and I’ve just about recuperated. That’s the sign of a good conference: exhausting but rewarding.
Hubert Baumeister has a great series of pictures of the conference
I co-hosted 3 sessions:
Fortunately, there was some time left to attend two great workshops:
- The Coder’s Dojo workshop by Laurent Bossavit and Emmanuel Gaillot. In this workshop we explored two ideas that the Paris XP group have been experimenting with for the past half year:
- Coding Kata: a programming task is given and prepared for the next session. During the session, the programmer presents how they arrived at the solution, starting from scratch. The presentation must obey the following rules:
- It must be performed in the given time
- The programming task must be solved
- Everyone in the audience must be able to understand all steps taken
- Randori: each participant in turn makes the code pass a failing test and then writes a failing test for the next participant. That was a lot of fun! We learned a lot about taking small steps and TDD when the process stalled because we were trying to take too big a step.
- The Agile Contracts by Mary and Tom Poppendieck where we presented and discussed ways of writing contracts that promote cooperation and work well with Agile software development principles.
There were lots of other interesting workshops I wanted to attend, but unfortunately one can only be in one place at one time… More on those later.
Some interesting keynotes by Jutta Eckstein, Kent Beck and especially John Favaro. More on those later…
|
