|
|
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 😉
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.
Tomorrow is the deadline to send in a proposal for the XP Days Benelux 2005 conference on 17-18 November 2005 in Rotterdam.
As usual, lots of the session proposals came in today. And I expect even more tomorrow. Typical “Student Syndrome”. Most students start to study when exams are frighteningly close
I’m not immune: I haven’t sent in my proposals yet, I’ll do it tomorrow. There’s always tomorrow…
Luckily, we took this into account in our planning: session proposal deadline is July 11th. Session reviews start on July 15th. This gives us a bit of time to deal with the glut of proposals coming in.
How do you deal with Student Syndrome in your project?
|
|
