Wednesday, August 6, 2008

New workshop format: Goldtaking


Today we tried out a new format for workshops; I'd like to call it "GoldTaking". We got great feedback on it.

It works in the following way:

Pre-requisites
1. The group starts off by having a quick standup where everyone suggest one topic to discuss. These topics are being listed on a board/big notebook.

2. Everyone goes up to the board and make a single mark on one or two topics they like to discuss.

3. Depending on how many people are attending, the organizers choose a number of topics to discuss and make up groups for them based on number of markings. Since everyone can mark two topics, we easily filter the topics. If they could only select one, they are more likely to only mark the one they came up with in the beginning.

The actual "Goldtaking":

For each group we have a notepad and a pen and select a note taker to begin with. Whenever that note taker wants to make a statement or ask a question, she passes the notepad and pen clockwise, thus making the person sitting next to her the new note taker.

This has some interesting effects; one that we experienced is that very often someone is likely to "take over" the discussion. After some time they are bound to become the new note taker, thus giving the word to the others.

Another thing that this accomplishes is that when we gather the books afterwards, we have an excellent document for making reports or post-documents of the discussion.

Everyone is free to take their own notes when they are not the official note taker, this means that if they really want to take notes on everything; they can either fill in their notes whenever they pass the notepad (after making the statement/question) or they can borrow the notebook afterwards and copy from it (the missing bits will be written by them self!).

The reason for the name "GoldTaking" is that this is inspired from Gold Fish Bowl-discussions and that the result document may be worth its weight in gold.

Sunday, August 3, 2008

The good life of Agile

When I started doing Agile projects and coaching in around 2000/2001 it was hard work getting management to agree or even discuss the topic of Agile. Whenever we wanted to do an agile project, we had to be very stealthy. We had to fly under the radar of upper management and sometimes even project management. Management usually told me "we can see how this works for small projects, but in the enterprise world we have to go for waterfall"

In the later years, this has changed a lot. These days you can't start a project without deciding "how agile it will be" first. In a coaching session the other day one manager told me "I can see how this works for enterprise projects, but will it work for small ones as well?"

This question almost gave me goose bumps (ok, I'm crazy, you know this by now).

After all the years of hard work, I think we are at a point where we are changing the way software is actually being created.
Not only changing the way we wish software was being created.

This might have to do with the fact that we have proven ourselves over and over. We have been put to so many tests and hard questions that we have a lot of refined and well thought answers, stories and experience reports that we can tackle any challenge.

Since April, I've been doing sessions in London, Florida, Seattle, Limerick/Ireland, Shanghai and several cities in Norway (and I am currently in Toronto, waiting to do two more). All of them have gotten a good review and I still get a real kick of being on stage.

I feel like I'm in the right place at the right time. I am sure most of you other Agile Coaches out there feel the same way.

Life is good.

Tuesday, July 29, 2008

Speaking at Agile 2008 - Toronto, Canada


Next week I am going to host two sessions on Agile 2008 together with Lars Arne Skår.

Here are the sessions:

How to support a collaborative atmosphere in distributed projects?


Exposing the “devils” within - Agile taboos and other hurdles in a large organization



We did the second one at XP2008 in Ireland some months ago and I will blog the result of both of them soon.

Monday, July 7, 2008

Airport Check In - Local Chinese Style

When leaving from a small local airport in Shanghai (about the size of our national airport in Norway...) this morning, I got into a rather bizarre situation. When reaching the check-in counter I was promptly dismissed (after standing in line with my fligh number over it, for quite some time). I was told to go to another counter on the other side of the hall. This was an interesting counter, not only because it had 4 employees sitting in a 2 Square meter space. It was interesting in the way it had about 20 angry screaming Chinese people around it. In the midst of the highly aggressive and high pitch screaming crowd (AHPSC), here I was trying to get a boarding pass. After a while I managed to navigate close to the counter and explain that I was sent from the counter on the other side, and that all I really wanted to do was to check in and get my boarding pass. After some more commotion from the AHPSC I finally got my boarding pass. Or at least I got the boarding pass for the first destination. I was told that I had to check in at Beijing for the rest of the way.

The reason?

A colleague of mine told m e that their software only has two fields for destinations... If you have more than 2 destinations you can't check in all the way. I would not be suprised if this piece of sofware was created using a waterfall approach...

Friday, June 6, 2008

Can You Please Stop Screwing Up?

Is it ok to screw up code? Is it ok to create architecture that is so complex that no one can use it?Is it ok that people do stuff that they know is bad? Is it ok that some people go ahead and do something entirely different from what they agreed on?

When being asked these questions, most developers answer something like "no, it is not ok". But when it happens to us, what do we do? Are we making sure that the person responsible for the screw up get to know about the effect what they have done? Or are we just ignoring it and hoping it will not happen again?


STEP UP AND LET PEOPLE HEAR IT WHEN THEY SCREW UP!


Be rational, be polite, but make sure that your point gets through. Do not confuse telling people about what they have done wrong with punishment. Punishment does not help, enlightenment does.

In professional software development, it is way too expensive to ignore screw up's. And it is even more expensive to accept them over time.

Would a professional football team accept it if their goalkeeper kept letting goals in because he was occupied with something else every time the ball get close?

Would it be ok for a professional race driver to constantly ignore the map reader, making every race a crash?

We are professional developers, act like it.

Are Microsoft Developers Missing Out On Agile?

The last couple of years I've been speaking more and more on multiple platform conferences (like the annual XP-seminars), rather than pure Microsoft conferences. It is getting clear to me that it does not matter if you choose .NET or Java as your development platform, from a technical comparison point of view.

For several years now, MS has caught up on the technical stuff. In my opinion, we (MS developers) have a small advantage over the Java guys. I guess a Java guys will say the opposite. It's all based on where you have your expertise.

One thing that seems strange tough, is that it seems like that Java developers have a more clear view on Agile. The evolution of Agile tools happen in the Java community and after a while, it is being ported to .NET.

Why is this?

My guess is the following: The Java guys are used to invent stuff by them self. They do not have a large company providing them with all they need. That might have lead them to be more innovation. On the other hand, the .NET-developers can always rely on the fact that if something is good, MS will implement it in a couple of years. Just have a look and unit testing and server side build. This might have lead to the MS developers becoming lazy. In most cases, lazy is good for enterprise development. Use stuff that you can buy, rather than build it your self is usually a good idea.

But, when it comes to the values of Agile, it becomes a problem. This week I've been at the Teched Developers USA. I've spent a lot of time discussing with different developers and I am a bit startled over how many say they are doing Agile, when they are really doing smart waterfall with some added tooling. I've noticed the same for quite a while now.

I finally think I know why. Let me try to explain what I mean in an overly simplified way:

Java Developers get the ideas of Agile based on evolving needs in their process and create the tools to support it.

Microsoft developers get a tool from Microsoft (like unit testing) and fit that into their process and try to decipher the reasoning for it afterwards.

The examples are many, like a feature I really enjoy in Visual Studio: The Visual Class Diagram Designer. This is just great as it gives you a really good, live updated, view of your class and you can actually do refactoring from here. In Rosario the support for this will be even better.

But the usage of it comes from Microsoft saying "we have this great tool for you, would you like to use it?" instead of the developers saying "We need a better way to view our classes, who will create a view?"

Does this make sense? Or have I completed my journey to lunacy?

Generally I think that Microsoft tools have a very high quality and I will not be changing platform anytime soon. But I will advice the ones of you that are MS developers to start looking a bit outside of what is given to you. Participate more on general development discussions, rather than technical discussions. I know it has given me a much better insight into building high quality software.

If we as Microsoft Developers are going to be able to compete and even win over the Java Devs, we need to take this serious.

We must be the guys with the best ideas; we must be the driving factor behind professional development. Regardless of technology.

We did it for SOA, now let's do it for Agile :-)

Thursday, April 17, 2008

Are you Agile?


"Can you define Agile?" is one of the top questions I get, I do not have a good answer for that.

But I do think I have some good pointers for "What is not Agile":

- If you haven't read the Agile Manifesto, you are probably loosing out on the real basis of Agile.

- If you plan all your iterations at once and lay them out in the beginning of the project, you are not Agile.

- If you plan by using hours as your only way to messure the speed of the team, you are not in a Agile Project.





- If you do not have automated tests, it is really hard to be Agile.




- If you focus more on letting people work from home, than to focus on co-locations and productivity; You are not Agile.


- If you have a non-coding architect, a customer that only the project manager are allowed to talk to, a DBA that only shows up for status meetings and testers in another location; You are not Agile.

- If you are spending more than 10% of your month documenting what you have done in a document that "no-one" will read; You are not Agile.

Whenever I get into a discussion with "Non-Agile"-Agile people, I find it hard not to make the discussion look like a religous debate, based on small insignificant details.

I guess this has to do with the fact that even if Agile is simple, it takes a long time to understand. It took me over 6 years to really understand why storypoints is a better for estimation than hours.

I am a firm beliver that the use of realistic estimation (not hours), direct contact with the customer, a focus on refactoring often and just providing the documents that provide actual value isn't small insignificant details. I actually belive that those among the other well known techniques are crucial for getting the most out of an Agile Proccess. If you just pick and choose, you might end up with a proccess more suitable for hackers than for professional software developers. No, I am not saying that you need to follow the book from A-Z on order to be Agile. All I am saying is that for every part you toss out the window, you should think about what you are loosing and subsitute with something else that gives the same value.





Bonuspoint : If your proccess has the letters R-U-P in it, you are NOT doing Agile :-)

Tuesday, April 15, 2008

Staying out of the spot light

This years MVP summit is somewhat different than the ones before, one of the key differences is that the first day is set up for Open Spaces. All MVPs are asked to submit sessions, and a few are picked out to do Open Spaces. Since I am doing so many sessions on other conferences this year, I decided not to submit anything.


My plan was to just enjoy the summit, without getting in the spot light. In the opening keynote we where informed that one of the MVP's, Toni Savage, couldn't come to the summit. This lead to an Open Space called "Project Management From Beginning To End" to not have a host. "Would anyone like to host this session" was the question from the stage. Again, I thought to my self, "I will not seek the spot light, I will only enjoy this as a participant".


Two hours later I was hosting the session.

Luckily the participants where really great and we got some very good discussions. After the session I continued the discussion with some of the participants and I actually manged to explain and get real understanding of the value of storypoints in less than five minutes.


Anyone that can top that?


I am now going to enjoy the rest of the summit, without getting into the spot light. I promise.

Friday, April 11, 2008

Next Week: MVP Summit (Seattle)


I am going to the MVP Summit for the forth time next week, and this time I am more excited than ever. After almost a year of few important releases (not betas or CTPS, real stuff that we can use in 100 Million Dollars projects) to us developers, Microsoft now has many cool things in the pipeline or just released. Hopefully we will do a real deepdive into technologies like Silverlight and get clear answers of what we can expect the next years. Another development I have been following is the Team System, which might be good news for us that are running really large scale Agile projects. Specifically I hope they have even better stories when it comes to ECI.

I am also looking towards meeting my fellow MVP's, most of us only meet at the Summit,PDC's or Teched's.
(Sorry about the spelling in this post, my spellcheck has died for some reason...)

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.