Friday, March 21, 2008

Where have all the liars gone?

Back when I was doing project work in the traditional waterfall way, I noticed liars all around. Developers lied about the status of their work (more or less deliberately) to the project manager, the customer lied to the project manager about how much functionality they really needed in order to use the product. The salesmen lied to the customer about how quickly the team would deliver.

It was lies all around and we where so used to it that we started to make daily routines to cope with the effect of lies . For this reason, all estimates would for example be padded with a fixed percentage and in all contracts you would find legal statements that would punish the parties if they was caught lying. It was a cruel environment to work in. We even lied about the process we used, what we said we would do in a sales meeting was often quite different from what we actually did when we started to feel the pressure of delivering.

The other day I was thinking about how long it was since the last time I felt the need to lie to the customer or the project manager (err,sorry, SCRUM master). When thinking about it, I can't remember the last time it happened. It must have been in one of the projects I mention in my pending post "Dealing with psychopaths".

After years of studying body language and speech patterns, I consider my self somewhat able to figure out when someone is lying to me. Since I started working with only Agile teams or at least teams and customers that want to be agile, I can not recall a single time when I noticed that someone was lying to me. This can of course mean that the liars evolved or that I've simply become more ignorant. But, if that aren't the case; Neither me nor the people around me are lying on a daily basis anymore. Of course, as you might understand, this post is about lies in the professional environment, I haven't noticed the same decline of lies in my private life.

One of the things I have noticed over the last years, is that the people I encounter are more capable in the job than they used to be in the times of the DotCom'ers. I have worked with a lot of different companies the last years, so either I have been very lucky or the entire industry has improved. It seems that people that are good at what they do, lie less often about the results.

Working Agile makes it easier for people to share knowledge. When working in a pair I am sure that there isn't a single day when I haven't learned something new. Other people tell me that this is their experience with working in pairs as well. So, our skills are improving every day. The novice is bound to become a master over time.

Another aspect of this is what you feel about your work. My experience with Agile practises is that we tend to focus on the good things, we focus on being proud of what we do. Why would you lie about something you are proud of doing? Yes, there is of course false proudness, and people that make up successes in order to have something to be proud of, but that is something very different. Agile teams are proud of measurable results.

In the Agile way of doing projects, customers are a real part of the team. It makes it very hard for the developers and scrum master to lie to them. They get to listen in on what is actually happening every single day. It is much easier to lie in a quarterly meeting, than it is on a daily basis. There is no room for the customers to lie about the most important part, priority. You might have heard the number one customer lie "everything is important, we can't do without anything". They are asked to do the prioritization often and they are directly responsible for the outcome. If the outcome isn't what they needed, they can have another go some weeks later. No one will tell them "you can't have this", they will hear "what would you like us to do first?". Tasks and features that doesn't matter just disappears by them selves. No big deal . Literally; no big deal, only small partial deals. No need for them to lie.

So, where have all the lairs gone? The lying people are still there, even in Agile teams. But it is simply too hard for them to lie and they gain too little from doing it.

Whenever it becomes easier to lie than to be honest and the immediate gains of lying is high enough, they will be back.

If you miss the times of deception and lies, please feel free to put more formalities and team separation into your process. And make sure to have lots of fixed price projects. The liars will be back before you know it.

Let's try to stay honest for a while, it feels much better than the alternative, don't you agree?

Wednesday, March 19, 2008

Can this last?

I have been wanting to create a blog for quite some time, but never gotten around to do it until now. I really have no clue as to how my blogging-schedule will be, I guess you just have to wait and see.

Since this is my first post, I would like to start out by sharing some toughts on the waterfall approach and start my ramble on Agile practies.

Yes, we all know that it is a bad idea to do waterfall and it almost never works out. In discussions with others, one of the top reasons for failure is that you make most important decissions at the absolut worst point of time. The beginning of a project is a bad time for important descission basicly becouse this is when you have the least amount of usefull information. I do not count guestimates and detailed plans mixed with the never failing optimistic feeling the stakeholders have at the beginning as "usefull".

So, if all is bad about waterfall, why are there some waterfall projects that actually deliver on their promises?

I think that we have to have a look at ourselfs in order to figure that out. Think about your last project that went really well. What was it that made it so good? When I ask this question, the answer given is very often something along the lines of "It was just the right mix of people and we worked together as a team". Remember the good feeling of working with skilled people? The warming feeling of showing up to work and know that your team enjoyed having you there as much as you enjoyed being there?

Those are the kinds of projects that very often are remembered as a success, regardless of the proccesses around. If you analyse what it is all about, I am quite sure that one of the key things you will find is COMMUNICATION.

Yes, the act of sharing and getting usefull information in a way that you best recive it. How we humans do this, is very different from person to person and from situation to situation . So simple, but yet so complex. (Some stakeholders still think that yelling at the devs is a good way of communicating)

One of the top 10 questions I get when I host Agile-sessions for non-agile teams is always "How can we get started?".

So far, the best answer I have found is to start by improving the quality of your communication. Start by doing the little things that really matter, like standups and make sure that team is situated together. Make sure that the teams thinks about communication. Think about how your documents communicate and try to figure out if there is anything you can do to make communication easier with your coworkers. Do not forget one of the most important communications we do, think about how your code communicates what it is (supposed to be) doing.

I think that the main reason why we see more successful projects with Agile is that it deals with communication by default, rather than being something that require extraordinary people that in their nature make way for good communication. Those kind of people are not very often found in the developer part of the industry, so if you are able to rig a project with only those kinds of people; I belive that you can witness the odd success of a waterfall project.

So, if you have read so far, I have a list of challenges for you:

1. Get hold of one coworker that you feel that you do not communicate well with. Ask him or her if they would like to improve on this and see if you can come up with some concrete ways to achive this. (Grownups can actually do stuff like that!)

2. Find one of your old documents with more than 10 pages, that you felt was very important at the time you wrote it. Try to figure out how many people actually have gotten something usefull from it. Please leave me a message if you can find any project related document where you can prove that the entire document has been helpfull for more than 2 people.

3. Have a look at some recent code you wrote, are you telling a pice of the story with your code? Or is your code a set of language specific ramblings?

Good luck, we will see if this will last.