Managing Product Development

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

I’ve been working and speaking with whole bunch of people who want to “go agile.” They are not set up for agile. They have gates for approval. They don’t have teams that projects flow through; they assign people to whatever project whenever. (growl. People are not fungible. growl) They have geographically distributed team bits (I discussed this in Manage It!), not cross-functional teams at each location. They believe in their evaluation systems that reward individuals, not teams. They assign people to many projects and believe multitasking is the answer (!!). The only thing they measure about their projects is the schedule and that’s all senior management is interested in.

In many cases, agile is too far a stretch for these people, unless they are willing to invest heavily in training and coaching for each team and each manager, including some training for senior management. But that doesn’t mean they can’t be more effective.

I suggested a staged delivery lifecycle for several of these clients (and potential clients), as in What Lifecycle? Selecting the Right Model for Your Project. For others, I suggested the iterative-followed-by-incremental lifecycle also in that article. For some other clients, I suggested they use timeboxes for each phase, and try to use continuous integration–those two changes were so foreign that I thought starting there would help everyone realize they had other options.

Each project has many options from which to choose. Lifecycles are the way you arrange your project. The practices are what you do. Anyone can use timeboxes and continuous integration. They are practices that might fit for your project. But using those practices doesn’t mean you’re agile.

I understand that agile is the new buzzword these days. I prefer to be effective, rather than buzzy. If agile doesn’t fit for you, don’t try to force it. Instead, start with what makes you most effective, realizing that effectiveness arises from delivering chunks of business value frequently. If it makes sense to use staged delivery or design to schedule so you can fit the beginning of the project into the way your organization funds projects, then do so. You can timebox feature development and have something that looks a little like “waterscrum”, where you start with waterfall, but move into timeboxes where you deliver completed features in timeboxes. Maybe the best thing you could do is pair people so you don’t have so many specialists (originally published as generalists). Maybe the best thing you could do is prototype some features to test that the architecture actually works.

But I really don’t understand why people don’t find a way of working that makes sense for them, rather than climbing on a bandwagon. Isn’t being more effective what we really need to do?

Tweet This Post

I gave a talk last night at the Software Quality Group of New England about schedule games. During the talk, I explained how serial lifecycles don’t manage technical, schedule, or cost risk, that they increase the duration of the project, that they don’t provide feedback early enough for the project team. One of the attendees asked, “If waterfall or phase-gate lifecycles are so bad, why do senior managers like them?”

Because the serial lifecycles are a simplification of what we do. They make more sense for a product with a physical component, because you do have to do some testing (certainly not all), once the product is built. But, especially for software, where we don’t have to wait until the end to get feedback–and should not wait until the end of the project to get feedback!–serial lifecycles make sense only under certain circumstances. My general rule of thumb is to consider a serial lifecycle only if you have two or three people for no more than 1 month of work. Otherwise, I use a different lifecycle.

But there’s an another, more insidious reason: serial lifecycles work for simple projects. The projects your senior managers worked on were much simpler than the products you’re working on now. With determined, dedicated people, your managers made those projects work. The lifecycle may not have helped them, but they managed to make the project work anyway. But your projects are not the same as your senior managers’ projects back when they were individual contributors or even project managers. Your projects are more complex.

Possible the most seductive reason of all: Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction hat’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by–the first possible, optimistic date.

If you’ve been struggling with how to explain to your managers, first understand your managers’ context. Then, maybe you can have a conversation.

BTW, I offer workshops aimed at people who are struggling with their transition to agile, for teams and project managers, and other folks across the organization.

Tweet This Post

I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it’s not surprising the technical folks didn’t understand the project goals.

But waterfall, with it’s emphases on understanding up front,  helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone’s naive about the entire schedule.

But there’s an even more insidious  assumption in waterfall: that the time to finish the project doesn’t matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff’s perception of quality. And that’s where waterfall lets down the entire project team.

I haven’t worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80’s. But maybe I can’t remember much :-) Granted, I tend to work on or with projects in commercial organizations, so if you’re working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you’re sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

Tweet This Post

I’ve also used Agile life cycles (Scrum with different size timeboxes) in combination on a project.

Here, the developers in the corporate location had a series of features that were big. I did suggest they break the features apart into smaller chunks for ease of estimation and implementation, but they didn’t want to :-) The remote team was responsible for smaller chunks of features, and were having trouble estimating the size of their stories. They decided to move to 2-week timeboxes to reduce what they were trying to estimate.

Tweet This Post

I’ve used another variation on multiple life cycles, especially for larger projects where the project staff or project management didn’t want to or know how to use an agile life cycle. This combination life cycle has two incremental pieces. The developers (the top of the picture) use staged delivery.

The testers, on the bottom of the picture, use design to schedule. This way they keep up with testing as much as the life cycle will allow, and if they are forced to finish the project early, they have “finished” all the testing to date. They don’t have partial bits of tests–they know what they’ve done and have not yet done.

Tweet This Post

I’m not a purist. I use whatever tools make sense for the context I’m in, and when it comes to organizing projects, I use whatever life cycles–in whatever combination–make sense to me. In response to a mailing list query, here are ways I’ve used life cycles for a few projects.

Let’s assume you’re collaborating with another organization. You would like to define an architecture sooner rather than later. You’re nervous about an architecture that emerges from implementing some features–you want a little more planning than that.

So you decide to prototype the architecture for a little while in the project (an iterative life cycle), and then move into implementing by feature (incremental life cycle). I’ve used this combination life cycle with and without timeboxes.

Is this a perfect life cycle? Nope. But it beats the uncertainty of a waterfall.

Tweet This Post

I’ve been thinking about how to manage the project portfolio, and I just realized why so many project portfolio efforts fail.

There are three kinds of cycles the project portfolio managers need to manage:

• Project cycles: when the project could release something
• Planning cycles: how often the management team assesses the project portfolio
• Business cycles: when customers want something new

To actually manage the portfolio, the project cycles have to be less than (or equal to) the planning cycles. The planning cycles have to be less than (or equal to) the business cycles (unless you don’t care if you only react to customer requests instead of planning for them). Sometimes, you do want to react to customer requests (have a customer request trigger a planning cycle), but once you have a relatively mature product, the customer requests don’t always align with your product roadmap.

To be most flexible, the Agile lifecycles shine for managing the project portfolio. If you can’t manage an Agile lifecycle, use an incremental lifecycle. You’ll have more flexibility on when to end the project–which means you can actually manage the project portfolio.

Tweet This Post

In Integrity is the Most Important Requirement in a Manager, I talked about integrity as a requirement for a manager. With the current Patriots scandal, I’m wondering what Belichick was thinking.

I don’t claim to know everything about football. I enjoy watching the games. I enjoy seeing a team come together, which is what the Patriots have done over the last few years. I am surprised that videotaping the other coaches is against NFL policy. (Oh, come on, when cameras can be hidden in glasses–which will happen in a few years–how is the NFL going to catch people taping the other team?) But it is against NFL policy, at least for now.

I asked Mark, who Knows All Things Football, at least in our house, about the taping. He said, “Everyone’s doing it.” The idealistic part of me says, “Maybe.” The cynical part of me says, “Figures.”

But even if everyone else is doing it, it’s not right. Not according to the current rules.

I’m trying to remember a time when I thought that going against the rules in a cheating way was appropriate. Then I remembered something I do all the time. I encourage my clients and colleagues to do work in an iterative/incremental way even on a supposed serial lifecycle. I tell people they don’t have to explain everything about their work to their management–that all they have to do is deliver results. (Which they can’t do in a serial lifecycle, but can in an iterative/incremental lifecycle.)

I’d like to think I’m doing something different from Belichick. I’m not telling people to spy on another group without their knowledge, and use the new-found information against them. I am telling people to “lie” by omission. (I’d never thought that was lying until now.)

Up until today, I thought that the ends–a successful project–justified the means. Now I’m not so sure. Part of me says that the project team are the experts and they should be in charge of their work process. That same part is sure the management team who insists on a serial lifecycle either doesn’t understand what they want, or doesn’t realize that artifacts are no guarantee of a working product. But the other part of me is wondering if I shouldn’t insist that project teams–who work in a way their managers don’t understand and deliberately keep that information from management–should tell their management what they’re doing.

I’m curious what you think. Are there times when the project ends justify the means? Where do you draw the line?

Labels: integrity, lifecycle, management

Tweet This Post

Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes:

• Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT organization, the functional owners sometimes perform these roles. (I think more IT organizations need sponsors who plan more than one release out for the product’s evolution.)
• Product lifecycle management: The plans, by release (project), of what the product will become and a rough guess (or wish) for when that release will occur.
• Lifecycle: The choice of how a project manager organizes the project. It may be serial (waterfall or phase-gate), iterative (evolutionary delivery or spiral), incremental (staged delivery), or agile (Scrum, Feature-Driven Development). See here for a comparison of different types of lifecycles.
• Project management: The activities in initiating, planning, steering, and closing a project (one release of the product lifecycle management)

Let me know if you have more terms you’d like here. And, I have every confidence you’ll let me know if you disagree :-)

Tweet This Post