I won’t wish you a great 2008.
I’ve learned that greatness is not wished nor received.
Greatness is made.
I will make 2008 great.
I trust that you will make 2008 great.
You can always ask for help, like I will ask for help.
|
||||||
|
Dec 31 Make a great 2008And, of course, you will… We were discussing our proposal for a custom software project with the CEO of our (we hoped) future customer. Things went quite smoothly, the proposal included everything he needed, no mind reading necessary. The financial part and the planning were OK. We later found out our proposal was 3-4 times cheaper/faster than our competitor, mainly because on this project we had, for the first time, a real live onsite customer, not a proxy. Everything seemed to be in order. There was just one small remark: “And, of course, you will provide us with extensive written documentation”, he stated. I almost replied “Of course!”. At the last moment, I shut my mouth. Those lullaby words are dangerous! Lullabies put children to sleep. Lullaby words do te same thing to grown ups. “It’s just one small change”, “It’s only 5 minutes work”, “We’ll simply…”,… Hey! Wake up! This entry isn’t finished yet. Enter the mighty WHY? Whenever I don’t know what to say, I just ask Why?*: “Why do you need this documentation?” The CEO answered that they not only wanted to use the software internally, but also wanted to sell this software to other companies in their industry. They were busy hiring some developers who would take over further maintenance and enhancement of the application, based on requests of their future customers. To confirm I understood him correctly, I asked “So, if I understand you correctly, you want your new developers to be able to maintain and extend the software as soon as we hand it over to you at the end of the project?” He agreed “Well, then I’ve got another proposal for you” We knew from experience that the best way to bring a new developer up to speed on our projects was through a combination of a clear metaphor, simple architecture (documenting the few mechanisms used in the system), coding standards, unit tests and pair programming. We proposed that we would provide high level documentation and his developers would pair program with our developers near the end of the project. That would provide a smooth transition from us to them. That would not make the project longer or more expensive. He agreed. Everybody was happy with the project proposal From lullabies to alarm bells Whenever you are confronted with one of those lullaby words, an alarm should go off in your head to wake you up. Lullaby words become alarm bell phrases. Whenever you hear one of those phrases you will be alert. You will think. You will ask further questions to really understand. Stay awake! All’s well that ends well And, did it work? The project worked out very well. Except for one part: the handover to the customer’s developers. You see, everyone was happy with the proposal… except those programmers. They hadn’t been consulted. They didn’t like the technology or the programming language we used. They didn’t like to come to our offices to work. They didn’t like to work in an open workspace, they preferred their private offices. They preferred to work individually, each on their own private part of the application. Our developers didn’t like the situation much either: the customer’s developers always came in late, left early and took long lunches. They made no effort to be part of the team, to learn or to pull their weight. A few lessons learned: pair programming is an effective learning tool IF people want to learn; make sure you consult with all stakeholders before proposing a solution; make sure that you hire the right people and set their expectations correctly if you want your project to succeed. Pair programming is also a great tool during the recruitment process: you see exactly what the candidate is capable of and the candidate has a good view of the team, technology and code that they will be working with. Some time later our customer decided that they didn’t want to be in the software development business. The developers were fired. Would more documentation have helped? (*) Did you ask yourself if “Why?” is the only or best question to ask in this circumstance? If the “just” in the sentence didn’t put you to sleep, you’re well on your way to becoming immune to lullaby words. Grey It’s a cold grey winter Monday. Inside the underground station it’s even colder and greyer than outside. The metro arrives huffing and puffing and hissing. The grey mass piles in. I’m submerged in a sea of sombre suits. A boor with a backpack bumps into my book. A woman tries to stifle a huge yawn and fails. Everybody looks away bored and unhappy. Where are they going? Where would they rather be? Color And then Esbjorn Svensson plays. We’re not in Kansas any more. Suddenly there are colors everywhere. Bright oranges and yellows and reds. A big grin appears on my face. People look at me as if I’m weird. What do they see? I don’t care. This is my stop. I dodge the dodoes to get out. I’m going where I want to be. Dec 15 David Anderson on TrustTrust The xp.be user group meeting was hosted by the Javapolis conference, at the Metropolis cinema complex. The subject was “Trust”. Not about one of my favourite movies, but about “Building a high trust culture in your software engineering organisation”. Trust is hot. Lots of business books about trust have come out these past two years. David Anderson gave a packed room an interesting and useful talk. As one might expect from a creative company providing images, the presentation consisted of large, gorgeous pictures with simple captions. David is an accomplished and relaxed speaker. He enlivens the presentation with humour, stories and anecdotes.
What’s trust got to do with software engineering or business? The Trust Dividend is the elimination of bureaucracy, reduction of transaction costs and elimination of waste. Things just flow; things just work. Trust is a chemical What is trust? Trust, is amongst others, the presence of high levels of Oxytocin in the brain. Oxytocin has other effects too. Trusting does not mean liking. It means that you’re willing to deal with each other without costly command and control, audits, written contracts. A handshake is good enough. We know that we’re true to our word. So, how do you get/build trust? A few tips:
How does trust between organisations or teams work? Trust is held in the individuals you interact with. So, be careful with turnover. Everyone who leaves takes the trust invested in them away with them. High turnover reduces the trust. David illustrated the different levels of trust by the way the planning for releases evolved:
After a reorganisation, other people came to the planning meeting. The trust level dropped. Planning went back from consensus to democracy. It will take time for trust to be rebuilt. What do I do tomorrow? Do you want to work better, faster and get more satisfaction out of it? Increase the trust level in your team. Implement one of the tips tomorrow. Just do it. Invest some trust. Make work like a game and have fun! David will present this talk in Scotland on December 17th. Be there if you’re in the neighbourhood. Recommended! A big thank you to David for combating jetlag by giving an extra presentation in the evening. I hope the Belgian beers helped to get asleep afterwards. Planning the next release A while ago I was responsible for the implementation of the “B” system. The current release was coming to an end. The Customer (in the XP sense) and I had collected a set of stories for the next release. Every two weeks, we had a meeting with user representatives to discuss the current and future system. We would discuss the plan for the upcoming release at the next meeting. Shortly before, I had followed a tutorial by Suzanne Robertson on applying creative techniques to requirements discovery. Whenever I learn something new, I try to apply it with my Make a wish I asked the users to “make a wish” about the system. It could be anything, it could be crazy, it could be impossible to implement, it could be very costly. I didn’t care. I wanted them to tell me what they really wanted. I was met with puzzled stares. Finally, one woman spoke up. I wish… “Well, I wish the behaviour of <this bit of the software> was not so annoying! I do this the whole day, when customers call. I want all the information available immediately, I don’t want to click through!“, she said. “That doesn’t count as a wish, because we’ve already corrected this in the current release. Make another wish.“, we replied. “Thanks. Well… then I wish the system would <do this> for me.“, she added. “That doesn’t count either, this story is already in the plan for the next release. You still have a wish left.” “Okay… then… I wish… the system would <solve this> for me“, she exclaimed. She thought we wouldn’t have thought of this. She was wrong. That story was also in the next release. She thought a bit more and looked at us with a slightly worried look: “Have you been reading my mind, or what?” Mindreading 101 If you have a good Customer or Product Owner, the users feel as if the development team can read their mind. It’s like magic. Like most magic, there is a trick. How did we know she was annoyed with that functionality? Simple: she had told us at the previous meeting. We had a look at how this functionality slowed her down and saw that we could improve her efficiency very easily. So, we decided to add this change to the current release. We had some time left, because we were going a bit faster than planned. How did we know the users needed those other functionalities? Simple: we regularly went to the “Gemba“, to see how users performed their work, to talk to them, to really listen, to really understand, to really help. Genchi Genbutsu. If you know of any out-of-work mind readers, contact me. I know several teams that are looking for a good Customer or Product Owner. Meanwhile, they can already start to really look, really listen, really understand. And I need to get better at stimulating users’ creativity. This was a really crap effort: we didn’t learn anything new. That’s the subject of a future entry. |
||||||
|
Copyright © 2024 Thinking for a Change - All Rights Reserved |
||||||
