Author Archives: Steffan Surdek

Agile planning in real life – IBM DeveloperWorks

Back in January of this year, I started writing an article on the basic of agile planning. I was originally writing this as educational material for my team but felt it could be something publishable… So, for your reading enjoyment, you can find it on DeveloperWorks by clicking here.

There are some differences between what I wrote and what they published so eventually, I’ll put up the original version of the article on this site.

Doing the right things for the right reasons

I decided to write about one of my core values in business tonight. I’ve lead different teams in the course of my career and I try to live off the following motto: “People on the team need to be doing the right things for the right reasons?”. I’ve explained this principle a few times to different people over the years and it’s always a challenge for me to explain it clearly.

Read more ...

Thoughts from Jan 29th Agile Montreal Meeting

As per the suggestion of my manager to expand my horizons outside IBM for networking, I decided to drop by the Jan. 29th meeting of the Agile Montreal user group. It was my first visit with the group and I was pleasantly surprised to see 20-30 people there. The meeting presentation was about how to manage relationships with your customers and the presenter did a nice job of keeping us all both entertained and on our toes… 😉

During the presentation, a couple of questions came out from the crowd that stuck with me. So I decided to wait after the meeting to have a chat with those people and see if I could provide them some guidance. The first of these questions was:

How do I handle a customer that comes to me with all of his requirements up front even though I want to work iteratively with them. They don’t seem to get it.

For the sake of the discussion, let’s assume a two week sprint or iteration. The best answer that I can provide for this is to tell the customer the following: “Mr. Customer, it’s really great that you’ve invested all this effort in your requirements. If you look at your list of items, what is the most important thing I can work on for you in the next two weeks. We can talk about the other stuff as we move along in our project and you can refine your requirements as we go, but right now, what could I do for the next two weeks that would make you a happy customer.”

Once the customer starts giving you priorities, ensure you don’t accept more work than you can do in those two weeks, then go off and do it. In two weeks, show them what you’ve done and ask them what are the next most important things for them. You will start building trust with your customer. One of the reason that customers sometimes refuse to prioritize is that they feel they will not get whatever is at the bottom of the list. Yes, that can happen and it surely does. But if you are always working on the most important things to them, some of the things at the bottom of the list will eventually make it to the top or will simply drop off if there’s no need for it.

The important thing is really to build the trust between you and your customer. Show them you are willing to let them decide what is important, then execute the work. If you don’t execute in time, then you will not gain any traction with you iterative approach. So be sure you know what you are committing yourself to doing. The other important point to reinforce is that you are doing just-in-time development for them. The work you are committing to will meet their immediate requirements. Customers think they know what they want but if you spend six months in development before they see anything, you may end up with your customer telling you that you built something nice, but it does not meet their real requirements. So by having these two week checkpoints with reviews, they may find their design evolve in ways they did not originally expect.

The second question that came up was pertaining to user stories. Actually, after speaking with the person, I realized that she was confusing use cases with user stories. There not quite the same.

Should we identify all the user stories before we do the prioritization?

A few things here that I’d answer for this. If you are really talking about user stories, you may want to flush out all the top level user stories with your customer, then ask the development team to do a high level estimate using story points to get an idea of the relative complexity of the features one versus another. This should allow the customer to do some initial prioritization of the stories and this also give you a product backlog to start working with. Once the initial prioritization is done, you can work with your customer to break down the epics into smaller user stories representing units of work that can be contained in 2-3 days.

I gave the person some examples of how I use a combination of user stories and use cases in order to better explain designs to the development teams that I work with. I also gave her some references for Allistair Cockburn for use cases and use case templates and suggested she read Mike Cohn’s book “User Stories Applied for Agile Software Development”.

All in all, a good night. I’m probably going to skip the next meeting as it’s a bit too close to this one and the presentation is of less interest to me.

Challenges of Distributed Development

This is an article I submitted back in the summer of 2007 for publication in DDJ magazine on the challenges teams meet when doing Globally Distributed Development. They took the nibbles that were interesting to them and turned it into a sidebar article in the August 2007 issue. This is the full version of the article I submitted. I originally wrote this in the mindset of being the master team. I’ve been working remotely with a team for the last year, it would be interesting to revisit this topic from my new point of view.

Read more ...

Challenges of Distributed Development (DDJ published version)

This article is the stripped down version of an article I submitted for the August 2007 issue of Dr. Dobbs Journal.  I had submitted a full article but they had already selected the one they wanted to publish for their issue.  They liked what I submitted though and decided to publish part of it as a sidebar to the article on globalized distributed development.  This is the first article I ever got published anywhere.  One day, I will publish the full version on this website.

Read more ...