Managing Product Development

I’ve been working with teams who want to move to agile. Some people on their teams are in another location, where the salaries are cheaper.

It’s difficult to get agile started with a geographically distributed team. If everyone’s distributed, it’s easier than if just some people–especially if they are all one function, such as developers or testers–are. Or, if the people on the team know what it’s like to work in a highly collaborative environment, it’s ok, but not as good as when everyone is all together in one location.

The problem is that many managers have confused wage cost with project labor cost. Wage cost is a part of run rate, what it costs to keep the project alive for a week at at time. Yes, cheaper salaries will reduce the project run rate.

The problem is: what happens if the geographically distributed project takes longer to deliver the project? My experience says that all the geographically distributed projects I’ve met take longer to complete. The lack of being all in one place made a particular team take longer to deliver running, tested features. Here’s an annotated value stream map that represents this organization’s delays:

Wage cost is certainly lower in some parts of the world. But the only measure of productivity is running, tested features. If your project team takes longer to complete features, then you have a larger project cost.

Before everyone gets so excited about bits and pieces of remote team members, ask yourself, “Are we building in delays that will cause us to take longer to complete running, tested features? What will those delays cost us?” Now you can start to look at wage and project cost and make decisions that will make sense for your team–whether that means moving to agile or not.

Tweet This Post

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

Last week, when I was on vacation, my most recent Stickyminds column went up. I somehow expected more comments. Maybe other people were on vacation, too?

Tweet This Post

One of the problems many people encounter when moving to agile is that they (literally) cannot imagine iterations shorter than 4 weeks.

I rarely recommend an iteration as long as 4 weeks now, and if people insist on 3 weeks, suggest they find the root cause for the reason their iteration needs to be so long. “Our builds take too long” or “our testing takes too long” are the most common problems I’ve heard. If you know what causes you to need more time, you can make a conscious decision about what to do. Do you want to address that technical debt now? or later? Every time your iteration needs to be long, it’s because you have technical debt of some sort. You can choose not to address that debt now–but be conscious of that debt.

There was a question about the length of iterations on the scrumdevelopment list. Ron Jeffries said that he and Chet regularly paired in 2-hour iterations. With our teleclass, Gil and I often pair for an hour or two. We decide in advance how long to pair for, so we timebox our time, and then we do the work.. We have daily standups where we replan what we’re doing for the day.

Does it make sense for you to have one-day or shorter iterations? It depends on who your customer is and when you can get feedback. But why not consider how short your iterations could be, and remove the obstacles to those shorter iterations? Your project will thank you.

Tweet This Post

I’ve been working with Gil Broza on our teleclass series, Prevent Your Agile Titanic, both on marketing it and on its content. And it never fails, we have questions for each other almost every day. Sometimes I’m developing something and it looks “funny.” So I ask for review. Sometimes, as with the content, we discuss and one writes, and then we switch.

Pairing seems natural to us. We hadn’t paired before this venture, and that doesn’t matter. We are both ready to pair, which helps. Neither of us have egos that get in the way of the outcome: a great series of classes.

Tweet This Post

Erik Gfesser posted a lovely review of Manage Your Project Portfolio. Thanks, Erik!

Tweet This Post

I wrote a little article about Barriers to Agility in the most recent version of PragPub, the online magazine from the Pragmatic Bookshelf. There’s a bunch of other good articles in there, too. Andy Lester has a great article about speaking as a way to practice interviewing, a bunch of comments/thoughts/rants about the iPad, and much more. Take a look!

Tweet This Post

I just returned from Tokyo, where I keynoted at JaSST, the Japan Symposium on Software Testing. 10 years ago, when they started the conference, maybe it was just about testing, but now it’s evolved to be about quality in the organization.

Some highlights from my trip:

• Everyone (and everything) I met appeared quite orderly. Everything had a place and everything was in its place. I saw this at the lost-luggage counter, in the hotel, and at the conference.
• I was pleasantly surprised that the subway ticket machines had an “English” button so I could buy my ticket and know what I was doing. The maps were in English as well as Japanese, so I could know in advance what my trip would be and which stop to get off at. I had a little trouble with which track, but that’s probably because I was jet-lagged.
• I was pleasantly surprised to see evidence that the simultaneous interpretation for my keynote worked fairly well. I could tell because people laughed when they were supposed to :-)
• For the tutorial, I did not allow enough time for the consecutive interpretation or for the questions about agile, so I needed another 20 minutes, which I did not have :-(
• I was a little concerned that when the panel prepared for the questions, I thought we might be boring. Nope, we were thought-provoking and funny.
• My Japanese hosts were amazingly solicitous and helpful for my entire experience: to/from the airport, to/from the conference, to/from sessions at the conference

I had a blast. I hope I have an opportunity to return to Japan. Now, all I have to do is get enough sleep so I’m awake during the day…

Tweet This Post

I’ve been busy the last couple of weeks, first preparing and then delivering the teleclass, 3 Crucial Factors for Preventing Your Agile Titanic. If you missed the call, you can still sign up for the replay. If you like what you heard on the replay, join us for the whole series of calls, starting Feb 8, 2010, and  sign up now.

Yesterday, I also did a webinar with Donna Reed, Selecting and Managing the Best Lifecycle for your Project, Team & Solution. Long title, good content :-)

And, the great folks at Dzone posted my video made during the Agile 2009 conference where I spoke about managing the Agile 2009 conference, where I think agile is going, especially for management.

Tweet This Post

Wow! I can hardly believe how many people have signed up for the brand-new free teleclass, “3 Crucial Factors For Preventing Your Agile Titanic” that Gil Broza and I will be teaching next week!

I guess we struck a nerve with many people who want (or need) to get Agile going, and who don’t have other expert help lined up.

Go here when you’re ready to reserve your seat.

On this call you’ll learn:

• The 5 characteristics of your first Agile project that you must get right (but most people don’t consider).
• What to expect if the first project is already selected and it doesn’t exhibit all 5 characteristics —and how to avoid disaster.
• How to choose a winning team: one that can effectively leverage Agile to deliver the project and extract useful lessons for subsequent Agile roll-outs. (Hint: That’s not necessarily the people who happen to know the codebase or be available this minute.)
• What to do if the team is already selected and you’re not sure it’s the right place and time for all of them.
• How to turn this group of individuals into an Agile team. Unfortunately, many people think that just by referring to them as “Agile team” or “Scrum team” and putting them in the same room, they will self-organize and collaborate. Nope, it doesn’t work that way.

Go here to reserve your spot in this complimentary teleclass.

If you have questions, do email me.

Tweet This Post