Managing Product Development

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

I have a question for you:  Have you come across team whose first attempt at Agile adoption resulted in conflicts, pain, or just fell short of expectations?

I’ve met plenty of teams like that. I’ve heard statements like “nobody knew what they were doing”, “management still dictated an impossible deadline” and “those sprints became small death marches”. The most common blanket statement is “we tried it, it didn’t work.”

I’ve been coaching and training for years, helping people avoid just this sort of mess AND do Agile really well. But not everyone has access to an experienced coach, and many competent do-it-yourselfers get into trouble. Agile adoption is hard!

All this is about to change. On January 20th, my colleague Gil Broza and I will be teaching a free teleclass:

“3 Crucial Factors For Preventing Your Agile Titanic”

This is our way of helping you get Agile off on the right foot–and all you have to do is be on the phone. No need for approval, sign-off, expenses, or convincing anyone.

On this call you’ll learn:

1. The 5 characteristics of your first Agile project that you must get right (but most people don’t consider).
2. What to expect if the first project is already selected and it doesn’t exhibit all 5 characteristics —and how to avoid disaster.
3. 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.)
4. 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.
5. 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.

Click here to reserve your spot right now.

This call is right for you if:

• You recently started an Agile effort, you’re thinking about it, or you’re planning to very soon. Perhaps you’ve been given a mandate: “Go Agile in 2010.”
• You have some basic training in Agile. You may have taken a course, read a book, been to conferences–whatever your experience, you have more than passing knowledge of the Agile principles, values and practices. Doesn’t matter whether that’s Scrum, XP or something else.
• You and your team will feel the consequences if agile fails to live up to other people’s expectations. Also, your project has or will have a team of some significant size, meaning that your organization is actually investing in the project.
• Professional Agile guidance has not been secured (for whatever reason). You or your team don’t have access to an expert who can look at your situation and offer practical ideas to guide you.
• Agile is among your personal objectives for the year. Yes, this is a terrible idea, and you may not have control over that.
• You are experimenting with Agile, and want to give it a real shot at working in your organization.

To sign up for the call click here.

Do you have colleagues and friends embarking on their maiden Agile voyage? Feel free to forward this to them — and remember to reserve your spot here first!

Tweet This Post