Rosario : Missing the mark for Agile Development?

The next release of Visual Studio Team System is called Rosario and I've been attending many technical and marketing sessions on it.

From the marketing buzz it seems to me that Microsoft wants to target the Agile Enterprises with this release.

I am currently working in an organization with over 100 projects being run in about 10 different locations at any given time. For our setup we are planning to do the following:

- VS2008 with Resharper 4.0 for development
- CruiseControl for buildcontrol
- NANT and MSBuild for actual builds
- Nunit for unit-testing
- Watin for gui-testing
- Perforce as source control and branch management
- JIRA with GreenHopper for planning and change management
- A homebrew and really simple application for doing dependency management (simple UI, generates simple copy-batch scripts that are checked into source control)
- A simple homebrew configuration generator (text replace based on a template and hieratical delta files). Works with all kinds of text files (like web.config, stored procedures and so on)
- Server side MSI generation for deployment with simple batch-files.

Please note that all homebrew parts have been discussed in detail with other software vendors like Microsoft and we were not able to find a better "off the shelf"-solution.

When looking at this list I can't help but thinking: What can Rosario provide to this story?
I guess that having everything integrated within one tool is good on a conceptual level, but will it actually help the performance of the teams in an enterprise world? For every part of our developer story we provide simple implementations and we make sure that everything is easy for everyone to find. We focus on KISS all the way (KISS = Keep It Simple and Stupid).

This brings me to my main concern with Rosario: Which parts of this story can it do better? As of now, it seems that Rosario will provide a lot of non-core features, but it will not provide much with higher real value than my current story. For every part of the story, I can't help but thinking that we will loose flexibility and important core features if we move to Rosario. Rosario mainly solves problems I didn't know I had.

The point of this post? Please prove me wrong in my assumptions. It might save us a lot of time and money. I will be very happy even if you can prove me wrong in parts of this story, as long as the focus is enterprise (real) agile development.

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.

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.

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?

http://submissions.agile2008.org/node/388

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

http://submissions.agile2008.org/node/380

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

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...

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 :-)