Archive for April, 2011

Just as there was a risk with “yes we can”, long term vision might block people block from starting. I call this the perfectionist syndrome. People rather do nothing than doing something wrong.
Well, in reality never taking any decision is worse than taking a wrong decision sometime.
The cure for this syndrome is “Just Do IT” A lot of books about starting your own business (see the biography), tell you the same thing: better start.

Just start doing something,as whatever you do now, it will be wrong anyway!
😉
Ok that might feel bad. Stick with me for a second. If you take for granted that you will be wrong whatever happens, you will feel better if actually, what you do is wrong. (In the sense that, you did expect it to go wrong anyway. )

And if, by fortune, you are right, it will be a bonus and you have all every reason to have started !

The benefit of starting before you think you know what to do, is that your customer will discover what he wants by you showing him what you’ve got. (And you will discover it at the same time.)
yes, just like you, I want my customer to know what she wants before I start. Unfortunatly customers never do. When I show her what I have done. She looks at it, sees something she does not like and then tells me what she needs. Then I make a new version and we start over. After a few versions, we together create something my customer really likes. (This is true even if I am the customer.)

A lot of agilists, react to BDUF, which is the best know part of perfectionism. That is the old model perfectionism, the “Active perfectionism”.
In agile teams I see the same idea popping up: “ I can’t start with a scrum-board as I don’t have the right material/software etc…
The right answer is “Yes you can. Just DO IT.”

Just look at your todo list, GTD cards, backlog, what is blocking you from starting? Really? Are you sure it’s not resistance?
In Do the Work, Steven Pressfield goes over the different reasons of resistance.  Are your blockers really blockers or only resistance?

Look at your list again. Forget what block you and just DO IT.

 

Agile Techniques that support Just Do it

  • Continuous Integration
  • Refactoring
  • Unit testing
  • Daily Standup’s

Books:

Games that teach “Just Do IT”:

Thanks to Jurgen & Oana for reviewing this post.

I seems to run into Improv more and more.
This video reminds me of a great book: your brain on music.

I have lived a few years on welfare.
I had 345 euro per month. When people in my local youth club said they had no more money, they meant “I can’t drink anymore.” They usually went home at that point. When I said I had no money, that meant I could not buy food. I did not go home. I decided at that point that I would not let money define who I was.
According to most people’s standards I was extremely poor. At that time learned the real definition of being rich (although it took a few years to understand it)

Rich people spend less money than they earn.

In my last year on welfare I was able to save 20 euro a month. Although that was less than 10%, according to my definition I was rich.
The first year I worked, I bought a car, television, computer and a house … I did not save any money, I actually had to borrow extra money when someone crashed my car.
Allison: Nice story Yves, what does it have to do with the agile mindset?
Yves: Good question. For me it makes sense to continue to spend money on agile projects if the value they create is more then what we spend to create it.
In that sense you can easily evaluate the risk/reward profile of your project: you know what a sprint costs,  at the demo you look at what the sprint gave you. And  if it was more than you spend, the project is helping you be rich. If not, then you might want to stop asking for features.
Another reason to deliver quickly into production is that you get real money (cash on cash return on investment) and you don’t have to guess the value of what you deliver.
People at Flickr are doing A/B testing out in the open: they see the difference in speed and server load of two options based on real use.
I think Facebook goes even a step further; the features that get the most attention from its users, get the most attention from the developers. By deploying frequently Facebook can learn what is valuable to its users.
I stress this, because I know that companies that want to spend less then they earn have trouble figuring out the value their teams are producing.
The crowd funding initiative Sonic Angel uses the same principles to fund music bands. The bands can go to the studio once they have convinced enough people to invest in them.

Do you want to be rich? Start spending less then what you earn.

Update:
Some of my friends used this idea to have a quality life traveling the world.

Agile practices that support “Spend less then what you earn”:

  • Continuous deployment
  • Emerging Design
  • Refactoring
  • PairProgramming
  • YAGNI

Books:

Long term over short term.
The “yes we can” attitude you will also find back in the old cowboy coding teams. Lot’s of start-ups attract “yes we can” people. But that is not enough for being agile. We also need long term thinking.
Long term thinking in agile is best described in the 11th core commitment “Don’t do anything dumb on purpose
Some people have the tendency, when they look for a long term vision, to think about the perfect world. Oh, yeah, it’s nice to envision the perfect world.
Let me tell you about how my partner and I envisioned our future house. 10 years ago, on our holiday we did a “Begin with the end in mind” exercise. It helped to find out what kind of house we wanted. It worked because we did focus on a big vision and not on details. When we bought a house a few months later, the house had everything on our list. We did not even look at the list when selecting the house. We had a clear vision and we had internalized it. Part of why it worked was because it was the second time I had bought a house. (Third time if you count the house my parents bought after I burned down theirs.) I bought my first house alone. I never had discussions about what I wanted. (Who would I have these discussions with?) I forgot about aspects important to me (Being easy to reach was one of them.)
As long term vision for the new house, we focused on things that we would not be able to change later. Things like:
– close to a highway
– close to a train station
– close to a school
We did not focus on having a perfect house. We planned on doing some reconstruction of the house later.
so let’s come back to agile. I see people creating a perfect framework, for the sake of long term vision. Long term vision is not the same as implementing a large framework full of functions you might need in 3 years. In Lean we call this Muda (waste)
We consider it Muda because statistically we know that most of these functions will never be used.  Agilists use YAGNI (You ain’t gonna need it) for this.
On top of that I don’t know which part you are not going to need. I’m no better at predicting the future of your framework than a 16 year old who thinks about his future with a potential partner. Now I know that you are smarter than me. And you might think that everything I wrote about predicting the future is true for Joe developer but not for smart people like you. You are an expert in what you do.
I’m sorry to say that the more you are an expert, the more, it’s true. In his book The black Swan Nicholas Talib  explains why experts are bad at predicting an unpredictable future.
If you can not make a perfect framework, why am I talking about long term vision?
Long term vision is about making it possible that things keep working. For me that means, long term vision is about making it possible to change things later. Today this is typically done by  keeping your code clean, with tests as safety net.
Now personally I don’t mind about dropping a practice, as long as you find other practices that will support the same value of the agile mindset.
If you think that TDD is not working at your company for whatever reason, I’m OK that you drop it. As long as you make sure in another way that your code stays maintainable, and you find another way that tells you when you break things that work now. Then drop TTD.
For now, unit tests, integration tests etc are some of the best ways to guarantee this.
For me, it’s no coincidence that from all the teams I coached, the team that had most (+25.000) tests, was the most predictable in implementing new stuff. Of course your mileage my vary, and actually I’m pretty sure it will. This is how it worked for me at a team I coached. You are different, you need to find your practise to support long term over short term.

Update:Paul Sloane published a blog post with 20 of the Worst Assumptions Made by Experts. If you look at this list, you see that these people are(were) really top experts in their field. Bigger experts then I, and probably you will ever be in our field. And yet these experts made such wrong assumptions. That is why I say we should not make assumptions about the future need of our applications.

Agile practises that support long term over short term
– Unit testing
– TDD
– Continuous integration
– Continuous deployment
– Passionometer
– Scary idea protocol
– Far Vision

Books:
The Seven Habits of Highly Effective People
The art of possibility (Thank you
Books proposed by others:
Mastery: the keys to succes and long term fulfillment (Thank you Dadi Inggolfsson)
Clock of the long Now (Thank you Dale Emery)
The Way of the Bodhisattva: A Translation of the Bodhicharyavatara (Thank you Miles Parker)
Foundation  (Thank you Antoine Vernois)
A la recherch du temp perdu (Thank you Olaf  Lewitz)

All my life, my name gave problems to the people around me.

People either did not know how to write it (H A N O U L L E) or did not know to pronounce it.

This video should help them with saying my name. Thank you Mike Hill (aka @GeePawHill) who’s question, trigger me to create this video.

Everything in our society speeds up:
– speed-yoga
– one minute bed time reading
– even sex is on a stopwatch…
– in a school that removed homework for kids below 13th, grades went UP.

Carl also wrote a book called In praise of slowness.

This video reminded me about my “where to push to stop story”


The title of this TED talk is: ” Laura Trice suggests we all say thank you”. For me she says something more important. She says ask for what you need. Say to your partner you want to hear him/her say thank you for what you give them. Yes the thank you should be sincere, yet it should happen.
Thank you Eric Culus for this link.

 

Thanks to @NetLash for the link

When clients want to go agile, they contact me with how questions:
– How should we do set up a kanban board.
– What tools should we use.
– What agile methodology is best?
– How to do agile estimations?
– How do we start code reviews?
– …
Etc.
These are logical questions for people new to agile. I’m happy they ask them because I see what bothers them. Before I can answer such a question, I need to know why they want to go agile. Or what kind of problem they want to solve when they ask for the best digital kanban board. (This question comes up every x time on the different online media). I have nothing against a nice visual board. (I have friends among all tool suppliers) Having your CFD (or other visual management info)being generated is nice.
Only implementing that without knowing what you want is a waste of time and money. Before I start with such a client, I want to know why they want to go agile. By first figuring out what they want they, I assure that the energy is focused on their biggest problem. Especially with existing teams moving to agile, this is important.
Last year David Hussman starting giving buttons away with his dude’s law: Value = Why over How.
When I first saw it, I instantly ‘got’ the idea. Yes, that should be the focus of agile coaching. David comes from the music industry. New musicians focus on having a nice sound. Professional musicians first think about the mood of the song, the emotion they want to bring across and then work out the sound that fits it.
Now going back with the client that contacted me for the best digital Kanban board. They seem to understand the agile mindset. And yes, the team needs more visibility on their work.

Instead of proposing a digital board, I’m asking them to start with a physical board. I propose they create a burndown chart manually. What I noticed is that teams that do this manually for some time, actually care about a burndown chart. When it is generated for them, they see it as a management tool that they don’t care about. Yes from time to time a team is not interested in it and does not do the effort to update it. This could tell me that they are not interested in keeping their promise of finishing.  (a root cause analysis should be done to find the real root.) When the burndown is generated, the ‘nobody cares about the burndown’ problem is hidden. This is why over how at a deeper level. First figure out what kind of information radiators the team is interested in.

What I noticed is that most people who come with a how question, have not thought long enough about their problem. (Jerry Weinberg says that if don’t have 3 solutions have not thought long enough.)
The same thing can be said if I as a coach start answering how questions, it tells me I have not listened enough. People that have found the why, usually come up with their own answers to the how question.

A few years ago, a women I started coaching was frustrated because I did not gave her direct answers to her how questions. It was very tempting to give in as a coach and give her a solution. I did not. I helped her finding the why behind her questions. I got her connected with another PO in the same company. Although in the beginning they both felt their problems were different, in the end I think their why’s were the same. The hows were different because their teams were not at the same level of maturity.

This whole process goes slower. And some people get frustrated because they expect that this coach will now solve all their problems. I know I do help them solve their problems, only not by giving them a silver bullet or miracle pill. I help them to think and realize they know the solution. Which makes these people quicker independent from me. And thus liberates them from me…

This gives me the option to help other teams == this is long term thinking over short term.

Update: Thank you for Peter Forret to let me use this picture of him.
Update:
Agile practices that support Why over how:

  • Behavior Driven Development
  • Powerfull questions
  • PairProgramming
  • Root Cause analyses
  • Value Stream mapping

Yet another Update : books that learn you about why over how:

Soft Skills Essentials for Software Craftsmen – Mechelen Mini XP Days 2011

Last Friday I did a talk with Pierluigi at Mini XPdays Benelux. We were both honored that our talk was selected among the 12 best sessions of XPDays Benelux 2010. This are the slides we used.
Pierluigi also posted a bibliography.  I have one book to add to that.
A book about Transactional Analyses that I heard my parents propose to tons of people. I’m OK, You’re OK. It was written in a moment that TA became very popular and after that period people took TA less serious. (The book TA Today that Pierluigi advises proves that TA is still valuable today.)
If you want to give us feedback on the session. Please use the improvement protocol