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.

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?

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.

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.

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.

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.

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.

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.

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 :-)

In response to my most recent Pragmatic Manager (about shortening project startup times), a colleague wrote: “I am working on a lifecycle definition team in my department and finally convinced the team that Agile Development was a Methodology using an Iterative Model lifecycle.” My colleague has neatly described the methdology (the practices) and the lifecycle (agile). A lot of people confuse “lifecycle” with “methodology.”

A methodology is a set of practices, sometimes built around a lifecycle. But many methodologies allow you to select the lifecycle that makes the most sense. Agile development is a set of practices, including frequent builds, pair programming or other built-in peer review, test driven development, frequent retrospectives (and the others) with a lifecycle that produces iterations of chunks of development. (Agile lifecycles are not just iterative. The short iterations and the focus on delivering useful product at the end of each iteration is different from other iterative lifecycles.) When you take the agile lifecycles plus the practices, you have a methodology.

Ok, so some of you are saying, “Semantics, JR. Puhlease.” We use words to convey what we mean. It’s hard enough to understand what everyone is talking about without changing the meanings of the words. Lifecycles are the way you lay out a project. A methodology is the set of practices you use with your chosen lifecycle. I would rather discuss the merits of specific practices or lifecycle in a particular project context than get stuck on the words we’re using to describe them.