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

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

I’ve been working with several management teams recently. They realize they need to change how they are organized in order to really make the agile teams even more productive.

For example, what good is a functional manager? If functional managers don’t need to assign tasks and check on how the work is going (the team does this), the functional manager needs to build a trusting relationship with people, and provide career development. The manager sets the mission/purpose of the group. The manager needs to see when the team (or teams) need more people, and to start and lead the hiring process. The functional manager may act in what I think a technical lead role is: to help uncover other ways of working, whether that is specifics (extend the design this way, test that way) or to coach the person into recognizing where to look for help. And, the big decision that managers make: which project to work on now. (Of course, there is also strategic planning, customer visits, etc.)

Project managers/Scrum Masters/whomever is charged with protecting the team’s process can’t do this work. Managers need to do this management work. But should there be development and test managers anymore? I think not.

Now, I can’t tell if my background is coloring my opinion here (of course it is, JR!). I was a development manager and a test manager at the first and mid-levels. I ran several departments, both in product companies and in IT. When I was a manager, first of development, we didn’t have professional testers. We did our own testing. We were ok at it, because we tested each other’s pieces of the product. As a test manager, I knew what the developers were going through, because I’d been a developer and a development manager. And, because I focused the test group on discovering more information (that’s the mission/purpose thing at work), the testers’ information became ever-more-valuable to the developers. I was a better manager because I understood what was going on between development and testing. By that time, I also understood the writers, even though I had not been a writer or managed writers. When I managed an entire engineering group of 80 or so people, I found that the bulk of my work was helping the functional managers understand the pressures on the other managers so they could work in a way that made sense for the entire organization.

In a technical agile organization, everyone is organized into cross-functional teams who deliver working chunks of functionality every few weeks. If the teams don’t have specialists, why should the managers be specialists? Isn’t that an outmoded way of thinking?

I should explain that Mary Poppendieck probably disagrees with me. We were talking about the role of the matrixed functional manager on an agile team while we were in Vancouver at Much Ado About Agile. I’ve been thinking since then, and working with my clients. I still disagree that the functional manager needs to provide specific-to-the-function technical leadership. I agree that coaching is necessary, but that doesn’t require a test manager for testers or a development manager for developers. It requires a true manager who can coach and help find the answers.

If we are asking the technical staff to be better at a wider variety of tasks, we need to ask managers the same thing.

Tweet This Post

Dave and Bob have great comments on my post, Might Three Backlogs Be Better Than One?. Dave is describing situations where management is making reasonable decisions, not incurring management debt, and by extension, technical debt. Bob and I have experience with significant management debt. (Take a look at Musings About Management Debt for more information about what I mean by management debt.)

Let me provide a little more perspective on these situations. The clients range from large systems of up to a million lines of code (but still software-in-the-small) to software-in-the-large systems of 14, 15, 16 million lines of code. These systems have been in existence for more than 5 or 6 years. They are the flagship, and sometimes only, product that creates revenue. In each case, management is fairly new. The product owner players are new. Many of the technical people are new.

No one knows enough to make good decisions. Yes, they should have one backlog, and they don’t know how to prune the defect list. When you’re talking about more than a few thousand defects, the number is just too big. When your builds take longer than one day, when you have no automated tests, when you’re using a configuration management system from the ’70s (ok, not quite that bad, but close), and you don’t know how to break down the work into small chunks, it’s all overwhelming. Oh, and don’t forget the customers breathing down your neck for not just the defects you need to fix yesterday, but the features the sales people promised tomorrow.

One VP told me he could not make the decisions. He was concerned about who he needed (“do I need all of Engineering??”) and the time to rank into one backlog (“We’ll be here all day and we won’t be able to trade off against features and defects”).

He’s inherited a situation not of his making. He knows that if he can get people to start working in an agile way, they could make progress and finish some work. That would make their decision-making easier. But he has no roadmaps for feature sets for the product to see into the short-term or long-term future. He doesn’t know how many of the 1000’s of defects are still valid. (He thinks more than he wants.) Everybody is nervous. No one feels as if he or she can make a decision alone. The notion of a product owner as a “single, wringable neck” (do I credit Mike Dwyer or someone else with that phrase?) is not something they are ready for. They wanted a committee. I did manage to talk them into a committee of 2: one technical person and one marketing person. That technical person is the erstwhile project manager and the marketing person is talking himself into being a product owner.

I don’t claim these folks are agile. I don’t think they would either. They are working in timeboxed iterations. They are trying to finish valuable chunks of work in those timeboxes. They are struggling with how to make their decisions.

One thing I know about decisions is that the smaller the decision, the easier it is to make it. When you have to make tons of decisions that last forever, it’s really difficult, especially if you think you don’t know enough. At first, they all thought their technical debt was too huge to make inroads. But when I explained how to break down their technical debt into user stories, and that they didn’t have to tackle everything at once, that if they could just get the build to take less than a day they would already be ahead of the game. They didn’t need to stop developing features or fixing problems to address their technical debt.

As we see more people who have used a phased approach to development for years, and have not had tremendous success move to agile approaches, we will see people who may not be ready for real agile, but are ready (desperate?) to try something else that will provide value. We need to help them move from their previous insufficient decision-making to decision-making that will work. I do like baby steps. (See  Small Steps Are Good; Be Careful What You Call Those Steps).

I do worry about the issue of three backlogs. In the face of no decisions, I still think it’s better to make some decisions even if the outcome of those decisions is not one backog. Maybe other people have had better results nudging decision-free organizations to decisions faster than I have. I do think that the visibility of the different kinds of work can help people out of their defeatist attitude of “We have so much to do, we can never finish it.” One of these clients is actually pruning their defect list this week. The reason they can do that is because they took one story off the technical debt list, finished it, made so much more progress in just two weeks that the person-who-might-be-called-the-product-owner-but-is-resisting-the-role asked if they could finish a few defects in the next iteration, and how many did they really have anyway? They have bought themselves room to breathe.

Agile–real agile–is about making decisions based on business value, and delivering valuable chunks of work in a small timebox. If you have an organization that can’t decide on business value, you are in trouble. If you have better ideas, I’d love to hear them.

Tweet This Post

I’ve been working with several clients on their transition to agile approaches to their projects. They all have a common state:

• Many features to implement
• Huge technical debt
• Many defects

They want to get a handle on all the work they have to do. I suggested they consider three backlogs, making sure that for a given iteration, they consciously choose what they want from each backlog so that an iteration has only one backlog, all agreed to by the product owner. That is, they bucket the work by features, technical debt, and defects. Rank each of those buckets. Now, for each iteration, the product owner chooses from the lists. I recommend looking at the #1 slot in each bucket. Which of these three is the real #1 for this iteration? That goes on the iteration’s backlog. Now, the next one from that bucket pops up and you only have three things to compare again.

One of the problems each of these organizations has is that their technical debt and defects were invisible to the decision-makers. Now the technical staff and the project managers have a list that is is visible to the product owner/customer. None of the work is secret–it’s all out in the open. They can discuss, poke, prod, ask, and negotiate to a reasonable conclusion.

It’s too early to tell if this will work for them. But the value of the three backlogs is that they can look across all the potential work in the organization and make a conscious choice for now. That choice doesn’t have to be permanent. Because they are working in backlogs, they have a shot at making decisions and adapting their choices later.

Tweet This Post