Catching My Breath: Many Media Opportunities for You

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

Do What's Effective For You

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

Why Your Senior Managers Like Serial Lifecycles

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

Waterfall Projects Create Naivete

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

Using Multiple Life Cycles in Combination on a Project, Part 3

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

Using Multiple Life Cycles in Combination on a Project, Part 2

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