I have a new book: Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility. I wrote it because I’m concerned about what I see in too many supposedly agile teams: Crazy-long backlogs and roadmaps. Those create a serial lifecycle approach with too little experimentation. Worse, sometimes the team doesn’t demo or deliver. […]
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
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
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. Serial lifecycles actually increase the duration of the project. And, serial lifecycles don’t offer feedback early enough for the project team. (They only
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,
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
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 (at the top of the picture) use Staged Delivery. Since this is not an
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
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:
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