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.

No comments: