Managing Product Development

On mailing lists, when I speak, in email, people ask, “When did ’some principle, approach, or whatever’ start?”

A long time ago.

Timeboxes have been around forever. I’m pretty sure that when the Pharoahs told their architects to build a pyramid, they said, “And do it by this-date! Or else!” I know that military projects used timeboxes. We used them in the mid-70’s and I heard that they were used when my managers were young engineers.

Inch-pebbles were first defined by some Air Force guy in the 40’s. (That’s the first published date that I know of.) The Software Program Manager’s Network (and I!) publicized the concept more in the 80’s and 90’s.

Non-waterfall lifecycles, such as iterative and incremental have been used for years. Any of those projects where you had to show a demo partway through the project was either an iterative or incremental lifecycle. The projects I worked on in the 70’s, 80’s, and 90’s had feature-based teams where we had to finish our features and integrate and test as we proceeded.

What’s different about projects now is this: the easy work is done. Waterfall only works on shorter, smaller, and not-too-complex projects. You can make it work on longer, bigger, and complex projects–it’s really hard to do so, but you can. Now, if us mortal folks are faced with a longer, large, and more difficult project, it makes sense to use the tools (including the lifecycle that fits the context best) to make the project work.

I don’t understand why anyone wants to know when some practice or approach started. Assume it was a long time ago. (I used continuous integration at university, because there was no other way to know if what I was writing was any good. I first paired in 1982. Kicking and screaming, but I did pair. I first used version control in 1976 when I worked with another developer.)

Does it really matter when a practice started?

The real question is this: Is this approach or practice a good idea for my project? That’s a useful question. Ask it.

Tweet This Post

I finally heard about the almost-complete financial numbers from the Agile 2009 conference. The conference is supposed to generate enough monies for the Agile Alliance to fund research, other conferences, guest speakers, and a whole bunch of other initiatives that are on the site. I was happy, because early indications are that we did. No, I don’t have final data, and when we do, it will be up on the Alliance site.

I was explaining this to Mark, and comparing it to other conferences I’ve run, as well as other projects. With other projects, sometimes, it’s difficult to know how much revenue you can connect to a project, so I tend to look at other outcomes too, at 3-, 6-month periods, and possibly later, depending on the project.

He asked, “Doesn’t everyone do this?”

I didn’t know. Do you? Do you have access to the data? I’m curious.

Tweet This Post

I have an article up on Gantthead.com, No Planning Needed? (Free registration required, I think).

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’m yak shaving this week. When I returned from the Agile conference, my right ear didn’t clear. It’s all clogged now, and the left one isn’t totally clear either. I have vertigo. I’m moving slowly and look drunk when I walk.

In the meantime, I have articles to write, proposals to finish, work to do. I find that in order to finish an article, I have to first do three other things, some of which involve tilting my head one way or another, taking more decongestant, chewing gum, or drinking tea.

My yak shaving isn’t too onerous this week, but it feels kinda strange. Normally, I just finish a task. Not this week.

I first learned about yak shaving when I read the book If You Give a Mouse a Cookie to my children. I’d certainly encountered it in projects, and have since then. I didn’t know this was called yak shaving until recently.

Added later because I wasn’t clear: Yak shaving is when you have to do something–usually several other things–to finish the task. An example: in order to mow the lawn, you need to get a sharp blade, but you can’t ask Bob next door because you didn’t return his screwdriver. So you have to drive to the store to sharpen the blade. In order to drive to the store, you need gas. At the gas station, you notice your inspection has expired, so you ask them to inspect your car. They tell you that to pass inspection you need new windshield wipers, so you go to the autoparts store where you not only get windshield wipers,  but a new steering wheel cover. You go back to the gas station, they verify you have new windshield wipers, you get the inspection sticker and get to the store where they normally sharpen your lawn mover blade, and realize they’ve closed early today.  (does that help?)

So, I’m slow this week, both walking and writing. If my ears clear soon, I will be thrilled. If not soon, I have other alternatives.

Here’s a question for you: are you yak shaving? What is preventing you from doing work quickly and easily? Is there a solution that will let you do so? It’s worth looking at your work to see if you are yak shaving.

Tweet This Post

I love it when my readers challenge what I’m saying, as in  Plunge In or Dip Your Toe? (for Projects).

I do believe in small steps for projects. I’ve long been an advocate of inch-pebbles, of standup meetings, of iterations and incremental development. I love knowing what done means, for the project and for features inside a project. You don’t have to be agile to use those ideas.

The idea I was *trying* to get across is that if you call something agile, please make it agile. If you dip your toe into it, you have not made the commitment. If you vary your timeboxes depending on whether you finish work in the timebox, that’s not agile; that’s incremental development. You can say, “We’re experimenting with incremental development. We choose to  vary the length of the timebox so we can practice getting to done. Maybe after we practice it for a while, we’ll fix our timeboxes and see how that works.”

That’s perfectly reasonable. I encourage you to do so, if you haven’t tried incremental development yet. But don’t call it agile. It’s not.

The idea of plunging or toe-dipping for some of my clients is about management’s expectations. “We paid for this 2-day workshop last week. Why aren’t you agile now??” is a more typical management reaction (which is why I have a draft about what management needs to do).

Maybe I’m too particular about what I like to call things. But if you’re toe-dipping, say you are. If you’ve moved to something, such as agile, commit to the principles and practices that make it up. But don’t call it agile if all you do is continuous integration. If you’ve never done continuous integration before, congratulations! You’ll never go back :-) But continuous integration by itself is not agile. I know of many successful waterfall projects who used continuous integration (merging the coding and integration phases) who would never claim to be agile, but used that practice because it fit for them.

Baby steps for change is a good idea. It’s difficult (impossible?) to make a wholesale change. Taking baby steps, trying them out, seeing what works is a great idea. Just be careful what you call it. If you’re not doing it all, you’re not agile. You are making changes. You are likely making it better. In my experience, at some point, you will need to make the plunge. At that point, commit and plunge. Just don’t call it agile until you make that plunge.

Tweet This Post

I’ve been teaching a variety of workshops recently, some of which are Scrum. One of the questions people have is: Can we do this partway?

No, not Scrum or any other agile lifecycle. You either do it all or you’re not doing agile.

You can work in timeboxed iterations. But if you haven’t gotten to done at the end of the timebox, it’s not agile. If you don’t do retrospectives, you’re not doing agile  (I don’t see how you can improve for the next iteration if you don’t look back at this most recent iteration). If you have to have an entire iteration (or two or three) of just architecture, with no working product, it’s not agile.

Timeboxes are helpful to people. But just timeboxes don’t make a lifecycle Scrum (or any other agile lifecycle). One group asked me “What if we keep the requirements and architecture phases? Then move into timeboxes where we get to done? Is that Scrum?” No, it’s quite a useful incremental lifecycle. But it’s not agile.

I understand why people would prefer to dip their toes instead of plunge in. If you’ve got an organization set up to do phased development and everyone is judged on their ability to meet their phase deliverables, it’s pretty darn scary. Especially if you don’t have automated tests and you have a legacy product. How can you tell you’re done at the end of a timebox?

The problem is that agile won’t solve these problems unless you put them on the product backlog or remove them as obstacles. Agile makes them visible.

For a project team, plunge in. Or, decide not yet. But don’t dip your toe and not commit to really being agile. You’re setting yourself up for complaining later.

(Added later because Joe was confused) Plunge in all the way. Go to agile. Commit to it. Or, commit to an incremental lifecycle. Commit to something. And, call it what it is. Don’t call it agile if it’s not, and then complain later that it doesn’t work. Don’t call it incremental if you don’t finish features, as in done-done-done. Know what you want to do, commit to it, and then evaluate your progress or success. (Is that better, Joe?)

Tweet This Post

I’m now the proud and happy owner of a new reservoir for our tankless hot water heater. (Tankless is a relative term, when it comes to hot water heaters.) A week ago, the reservoir part of our system finally broke. We had a new reservoir installed on Wednesday, and our lives have changed for the better. We have much more and much hotter water than we had in the past 9 years.

Looking back, I can see the graceful degradation of the hot water heater. First, a few years ago, we had slightly cooler water and we had to keep the temperature higher to maintain enough hot water. We actually ran out of hot water this past winter (but we thought Teenage Daughter Showers were responsible). Then came the drips. We’ve had trouble with the pressure relief valves for the past couple of years, but the plumber has been out monthly since January to fix the drips. When the reservoir finally went, it was not a drip, it was a full-fledged flood!

Our system degraded gracefully, but as with many complex systems, we couldn’t tell it was degrading. It would have been better if it had failed. At least then, we would have spent much less time and aggravation on the current system.

That happens in software all the time, too. We want  graceful degradation, but I maintain we need quick failure. Quick failure helps us see where the system works and doesn’t work and tells us where to look for problems.

Tweet This Post

Remember Why Projects Don’t Need Specialists? Well, I decided I had a little more to say. I decided to write an article, What’s So Special About Specialists? Please do comment there or here.

Tweet This Post

I’ve been sick for weeks, and am finally coming out of it to be close to healthy. (I was still coughing in the 8-degree Fahrenheit cold leaving the gym. Oh well.) One of the problems is that my work doesn’t stop if I’m sick. I bet yours doesn’t either.

Daughter #2 asked last night if I was caught up. “No, I just made choices about what could slip, and I made choices about what not to do anymore or for a while.”

As you can tell, blogging slipped. I’m not yet late on some writing projects, but I may well be. It depends on how quickly I can write my next Stickyminds column. I postponed several coaching sessions because if my brain doesn’t work, that’s not helpful for my coachees.

I’ll be at SD West next week, and was planning on having an entire day in the gym because I have no sessions on Tuesday. Nope, not going to happen. I can do a short workout and then my free day will be taken up trying to get the things done I haven’t done for the last three weeks.

You can postpone work. You can choose not to do it. You can deliver it late. You can do less. But catching up is not possible. Something gives when you can’t work.

The same thing happens when you manage a project portfolio. Just as projects don’t make up time, the portfolio can’t either. If something slips, you make choices about what to do next. You can postpone a project. You can transform it in some way. But don’t expect to make up time. Catching up doesn’t work.

Tweet This Post