The Regenerate Web

I was thinking about the automakers, and how they want many billions of $ from Washington (please, noooo). I don’t know what their strategic planning is, but it seems not to have changed from the 1960’s. Certainly, when I started buying cars in the 1970’s, I could not afford the low quality/high price/low gas mileage. When we bought our minivan 11.5 years ago (yes, I’m still driving it), we did buy a Dodge Caravan, because at the time it was the best value for our money.

Now that I’m approaching the end of my minivan years, I’m looking for a relatively high mileage four-door sedan. I have a few other requirements, but if you look at the comparisons of cars, you still don’t see US carmakers in the top tier for high quality/low price/high gas mileage. And if they are, the cars are not fun to drive.

I know enough about the car business to be dangerous, not to be helpful. But one of the reasons Detroit is in so much trouble is that they have such long cycle times. It takes any of the US automakers much longer to bring out a new model than any of the other non-US automakers. The longer it takes to finish a car (and let’s not talk about what done means here)–the cycle time, the longer it takes to see if your strategy is right. If it takes you 2-3 years to take a car from idea to manufacturing, and it only takes your competition 1 year, who’s more flexible? Who can react to a relatively changing market?

In my work with high tech companies, the organizations who can release faster (and I mean done, not releasing a product with major defects) have a variety of term strategies. The have near-term strategies, mid-term, and long-term. If you only have long-term, it’s like a waterfall project; you can’t get any feedback on the strategy until too much time has gone by. (Yes, their portfolio management does reflect their planning.)

To be honest, in this economy, everyone needs a short-term strategic plan that you can adjust frequently. Hopefully, you don’t have to throw it out, but just adjust it. You also need a mid-term plan so you can keep your eye on the path you think you want to take. And, you need a long-term plan so you can understand and adjust the business you’re in.

How to do this? Make your projects short, or at least, have them use an iterative/incremental lifecycle, so you can finish them at the end of a timebox if you need to. Now, at the end of each timebox, you can see progress and adjust if you need to.

I do understand that building a car is not like building software. The cost of the raw materials is huge, so the kinds of prototyping you do and the duration of the prototyping is quite different. But organizations who can successfully prototype quickly and move to manufacturing quickly have a marked strategic advantage over those who can’t.

And that’s true no matter what your business.

John Cook, wrote a lovely post, Peter Drucker and abandoning projects, explaining how Drucker talks about abandoning projects. (John, thanks, I will definitely be referencing Drucker in the PPM book.)

I haven’t been using the word “abandon” when I describe stopping projects. I’ve been using the word “Kill” and the concepts of permanently stopping projects (killing them) and putting projects on the parking lot (stopping them for now). John actually says the words from a developer’s perspective:

It can be a tremendous relief to abandon a project.

He’s right. It is a huge relief to stop working on a project.

Here’s why I’ve been using the word “kill” instead of abandon. I want people to make a conscious decision that this project is not worth continuing at all. (The three possible decisions are commit to; kill; or transform a project.) Abandoning feels more like we can just stop the project in whatever state it’s in and walk away from it.

But I don’t know people who can do that. Every time I’ve seen managers attempt to abandon projects, the technical staff want to wrap things up, or get them to a state where the project can be shelved and restarted again later. That’s why I separate the ideas of stopping a project for now (and putting the project on the parking lot) and killing the project.

Here’s an example of why I feel so strongly about this. I was working for a small company as a developer many years ago. We were not making enough money. Management stopped a project “for a while” where the duration was indeterminate. Over lunch, I asked my boss when we would start it back up again. He said, “Never, with any luck.”

But that’s not what was communicated to the technical staff. One developer said, “Well, management has abandoned this project. But I’m not. I’m going to save this project.” Ouch, not what management wanted and not what the company needed. The company needed us all on a project that could actually make money, not the money pit. But the other fellow thought that management had abandoned the project, not made a decision to stop it. If our management had considered the killing or parking of projects, maybe my colleague would not have continued working on a project that had no future and was diminishing the ability of the company to make money. We would have been in better shape if we had killed that project.

Maybe kill is too strong a word.  But if we want to stop a project permanently, I do want to kill it. I don’t want people doing skunk work on it. I don’t want more investigation. I do want it killed. For me, abandon isn’t a strong-enough word.

And, if we can’t sufficiently fund this project now, I want to put the project on the parking lot, or somewhere in the unstaffed work list.

I hope you chime in with your reaction about abandon vs. kill.

I finally finished editing the second part of the PSL podcast. You can find it here.

We have only two registrations available for PSL in Sweden left. Take a look at the information page if you think you’d like to participate.

I was exploring the idea of co-teaching with someone I met several years ago. He now teaches at a local university and no longer works in industry. He wants to teach some kind of agile workshop with me.

He said, “I want to teach a thoughtful kind of agile. The kind where you work in timeboxes, but you still have requirements documents and functional design specs before writing any code.”

I replied, “That’s not agile unless the customer is demanding the specs as output. Are they?”

“No. But it’s impossible to do good software development without specs. I have xx years of experience that says so.”

“Your years of experience in a serial lifecycle don’t translate to agile, or even to an iterative or incremental lifecycle. Can you even imagine a project where you don’t need specs?”

“No.”

I tried again. “Have you worked on an agile project?”

“No, I was planning on talking to people who had worked on agile projects to see what it was like.”

I was angry and frustrated at spending time with this person. I declined the opportunity to co-teach. Here’s someone who’s never been on an agile project, who’s never tried another path, who wants to teach “thoughtful” agile–and pass it off as the real thing.

Maybe this isn’t criminal, but it’s darn close.

If you’re looking for agile training, ask the instructor about his or her experience doing, coaching, managing, whatever agile projects. Don’t blindly look for certification or a syllabus you like (although a good syllabus is helpful). Ask about experience. If you’re learning how to pair, how can you learn from someone who hasn’t and doesn’t know the pitfalls? If you’re learning how to use continuous integration or timeboxes, how can you learn from someone who’s never used CI or timeboxes?

I don’t buy the “I can hear about it and teach it” argument; that’s what leads to “People who can, do; people who can’t, teach” maxim.

Thoughtful agile is when you choose an agile lifecycle or set of practices, and follow them to the letter until you succeed. You inspect and adapt as you go. After you’ve succeeded, then, only then, can you change things to make more sense. (Read Ron Jeffries’ article We Tried Baseball and It Didn’t Work.) But you can’t change agile until you know how to make it work. And, if you can’t do agile, have never tried agile, and have no real idea what agile is, you can’t teach it.

Just had to get that off my chest.

P.S. Added the before writing any code to make it clearer what I objected to.

My Stickyminds column, Transitioning to Agile in the Middle of a Project, is up. Enjoy!

I’m sure you’ve read of the AIG scandal by now. (Here is the Fox News story and here is the CNN story.)  Shame is too small a word for those executives. I would love to know where their entitlement comes from. I’d squish it like a bug.

Maybe they went to the resort to do strategic planning. An off-site is good, as well as leaving behind laptops, pagers, pdas, everything that can interrupt you. Keep the tools, leave the interruptions. If your business has changed or needs to change, as I would hope it does after being rescued from bankruptcy, you do need to do strategic planning.

Here are the strategic planning steps:

1. Define your mission. (Why are you in business? Who do you serve? What benefits do you provide?)
2. Analyze the current situation
3. Define the plans for the new situation

There are lots of ways to do the analysis and planning. SWOT (Strengths, Weaknesses, Opportunities, and Threats) is a common way because it’s easy to see and easy to do wrong. Armstrong has a different approach: Seeking commitment as you specify objectives; generate strategies; evaluate strategies; monitor results. Armstrong’s approach appeals to me because it’s an iterative process, not something you do once while at a nice resort. There are other approaches also.

One of the best ways to do strategic planning is to do it constantly. No, not to take off-sites constantly, but to devote a little of your time each week to reviewing the mission, analyzing the situation, and see if you need to redefine your current plans. Of course, for that to work, you need data about sales (or the equivalent if you work in IT or a non-profit), where your projects are, and if you are truly serving your chosen customers. Then, once a month, maybe at the project portfolio evaluation meeting, you can review the strategy.

You might still need to do an offsite once a year. But not a really ritzy resort, where the booze, the golf, and spa treatments take you away from the business at hand. (Manicures and pedicures are not necessary for strategic planning.) Strategic planning is work. Hard work. Don’t treat it like it’s a day at the beach.

Full disclosure: Yes, I facilitate strategic planning meetings. They don’t look like the AIG meeting.

P.S. I forgot to point to the Armstrong paper: The Value of Formal Planning for Strategic Decisions: Review of Empirical Research

A couple of weeks ago (!), Tobias Fors and Magnus Ljadas interviewed me via skype. I have finally finished the editing of the podcast and it’s posted here. It’s also in iTunes, in the Pragmatic Manager podcast feed.

Yes, I need a new microphone. It’s on my list, but not for this week

I had coffee with a friend Saturday night. She said, “Our family has a tradition of starting many projects to see what we can stick with. If you don’t start a project, you can’t finish it.”

She’s right. You certainly can’t finish something you don’t start. But the real question for all of is: Should we start this project at all?

My current todo list is way too long. That’s because we took a couple of days off to visit with Mark’s family, and with the Jewish holidays mid-week both last week and this week, I’m “losing” time to family and personal obligations. (No, I don’t really think of it as losing time, just about the actions I choose when.)

In order to get my list of projects down to a manageable number, I’m choosing which projects I need to finish this week, which ones I need to make progress on, and which ones can be postponed starting until next week. Notice that I listed the projects I can finish first in that list.

I hate having partially finished projects, which is why I’m trying to finish a bunch of things this week, even though it’s a short week. I literally get stuck with all the projects on my list if I have too many projects.

Here’s my general mode of working:

1. Make a list of everything I have to do. Get it out of my head and onto paper. Yes, this is directly from Getting Things Done: The Art of Stress-Free Productivity by David Allen.
2. Look at the list and see when I have to complete what. Make sure I know my interim deliverables.
3. Lay out the deliverables week by week for a few weeks (not more than 4 weeks total, generally only 2).
4. For the deliverables owed this week, I do 2 things:
   • Ask, “Should I do this project at all?” It’s worth making sure this work is still valuable.
   • If yes, finish the deliverable this week. Now, my deliverables may not be done-done-done. I might have to draft an article or something and let it sit for a few days, but it’s a deliverable to me.
5. Of the deliverables this week, see if there is something I have to finish earlier rather than later. Do those.
6. Make sure I ask “Should I do this project at all?” for each project left.
7. Of the rest, do the ones that take the least time (which tends to be the most valuable for me), and get them off my plate. Since I don’t estimate that well, I never know exactly how long things take, but I’m pretty good at relative sizing.
8. Loop forever.

This is the essence of project portfolio management. I happen to be using it for myself, but it works. If you know that the work is valuable, then it’s a matter of slotting it into your week or weeks. And, if you use inch-pebbles the way I do, it’s easy (well, easier) to keep up with the work.

When my friend says she starts lots of projects and then decides if it’s worth finishing, she’s asking the “Should I do this project at all” question repeatedly. I tend to ask that question before starting, but the key is to keep asking. If you don’t, you are throwing good money after bad, wasting time.

If your projects are hobbies, it may be worth starting a bunch of projects to see what you’re interested in. But if you are making decisions on behalf of the organization, timebox each project. Make sure you know what the deliverables are and see if the team can finish those deliverables in a timebox. Now, your starting and finishing makes sense.

When we arrived in Minneapolis, I tried to find an elevator down to baggage claim. (Yes, my knee is not working well enough to take an escalator.) I did find one, but it said “employees only.”

Many people who travel are employees. They are just not your employees. No, I didn’t use the elevator–although I was tempted. (That’s the evil part of me.) But it would have been much more convenient. The elevator I was allowed to use made me walk far out of my way on the arrival floor and then back on the baggage claim floor.

Why is it easy for your employees and not me? Why do you trust your employees and not me? Ok, for airport security, it’s probably the right thing to not trust anyone. But I sure would like to see employees use the same entries and exits I use. I don’t see why I should trust anyone when it comes to airport security.

We see this in software all the time. Have a problem with an application, call the service number, and the nice folks fix you up in no time, but not with a command you can use.

Is software security the same as airport security? (I argue no. In some ways it’s much more scary to entrust your vital information to a software application.) What would you have to do to your application to trust me to do the right thing? Even if I’m not your employee?

Mark and I visited his family in the Midwest. We used miles to pay for my ticket.

Aside from spending 50,000 miles (is it possible to get a ticket for 25,000 miles? We haven’t in years), it cost $5 for the ticket, $75 for the “services fees” and $15 to check one bag.

Yes, this is still cheaper than buying a coach ticket, but not by much.

I understand why the airlines are doing this. The real question, is what’s the effect on flyers, especially frequent flyers? Will I still fly with my family someplace I can take them on frequent flyer miles? Maybe not. Not if it’s still going to cost us $400 to get there (4 people, $100 each ticket). If our “free” tickets are no longer free, we will think long and hard about traveling and spending our money someplace.

But the real question is what about my expectations? When I originally earned those miles, the ticket fee was $5. There was no additional service fee. There was no bag-check fee.

This is the problem with “loyalty” programs. If you have to change the expectations of the consumer in the future, how loyal will they stay to you? If you’re a frequent flyer, you have loyalty  to some airline. If you, like me, live in a non-hub city, you have loyalty to a number of airlines (not loyal at all, is it?).

Promising a return in the future for a product you buy today is tricky business. If you’re trying to hold onto your customers with a loyaly program (this can be as little as a customer service agreement), watch out if the price of holding onto your customers increases. You could find that your loyalty program is working against you, rather than for you.

I was reading Ralph’s post, Whose Fault Is It?, and I realized that if you don’t know enough about management, you can misunderstand the root cause. Ralph’s example is of defects in an iteration and how they were not detected early enough because the acceptance criteria were missing. The criteria were missing because the testers and the domain expert were not available because they were also on other projects. I was surprised to see the reason for people on multiple projects be “matrix management.” But I can see why technical staff thought that was the reason.

The real reason is that the managers are out to manage *their* efficiencies of staffing all the projects. The managers are not out to optimize the organization’s throughput. (I don’t know this organization, but many of my clients have been in this position.)

Matrix management–itself–is not the evil. Multitasking is the evil. And the root cause is a lack of project portfolio management.

In PPM, you don’t commit to a project unless you can staff it. Fully. Period. No half-staffing. No 1/4 of this person and 1/3 of that person etc to make 1 FTE (full time equivalents). There is no equivalent for one person fully committed to a project.

Remember that, the next time your manager asks you to work on more than one project. “Which project am I fully committed to?” is a reasonable question.

Managers, if you feel the need to assign people to multiple projects, ask your manager which project is most important. Staff that one. Now ask about the next one. Stop staffing projects when you run out of people.

When managers optimize their work at their level, they are (almost never) doing this out of maliciousness. But if the organization rewards them for sub-optimal optimization, how can they not take advantage of it?

I spoke recently with a (new) Scrum Master with a team who’s new to Scrum. One of the team members is a little stuck. He doesn’t feel comfortable going to the task board to take a task when he’s done. He wants to wait until someone else is ready and then work with that person.

Part of this is ok–the working with someone part. But my colleague asked, “How do I get him to take initiative?”

You don’t. You can make it easy for someone to take initiative. You can make it a team norm. But you can’t make someone take initiative.

I know something about this organization. For years, the managers have estimated everything. The managers doled out tasks. The managers told everyone how to do whatever needed to be done. The managers made all the decisions.

This guy started at the company right out of school, has been there for almost 4 years. Why would he change his habits of 4 years in one iteration? How can he trust the management to not return to their old behavior and tell him he’s working wrong and they will tell him how to work right?

This fellow needs to see that management will allow the team to work the way they need to, without management interference. I don’t think he needs 4 years of seeing it, but he needs more than one iteration. He especially needs to see what happens when the team doesn’t meet a commitment during an iteration.

If someone is afraid of committing, or of taking work, or of anything else that smacks of self-management, take a look at the recent history. Does that person have a reason to be concerned? If so, address the issue at a retrospective. Don’t expect people will change just because you want them to.

Management who are attempting to move from command-and-control to encouraging a team to be self-managing need to extend trust first. Even if the team has shown no reason to be trustworthy–yet. Management needs to make it easy for people to succeed at new behaviors.

And if you’ve hired people with little initiative (hard to believe, but possible), explain what you need, ask for results, and back off for a while. Let people learn how to take initiative. There’s a reason it’s called “take initiative “and not “give initiative.”

I don’t normally pay much attention to these kinds of things, but what the heck, this will give Jurgen a link back.

Jurgen has collated the Top 100 Blogs for Development Managers (Q3 2008). I have no idea if he will continue to do this quarter after quarter (!). I’m glad that other people find this blog valuable. Thank you, dear readers, for reading and commenting.

The good thing about this list is that now I have more blogs to consider reading. That’s also the bad thing

I was trying to address the issue of ROI (Return on Investment) in the project portfolio book. I don’t buy project ROI. FIrst, the idea of a project for software is an artifical construct–our consumers buy running tested features, that we happen to package in a project to release as a product. But the idea of ROI means you know how many consumers are going to buy/use the product, and you know how much you’ll charge for it. That means you need a crystal ball. Mine’s not working.

Instead of Producer-ROI, I’ve started thinking about Consumer-ROI. When someone consumes your product, what can they do with it? What kind of waste can they eliminate? What new abilities will they have?

If you think about one consumer at a time, and think about their capabilities and waste, you get a better idea of what the real ROI is. It’s possible to have examples of how the product would reduce waste or increase capabilities for a given consumer. Then you ask this question: which features help solve a particular problem or reduce waste for a specific kind of consumer?

I still don’t know how to predict Producer ROI (Project-based ROI), with any sort of assurance I’m telling the truth, but when I think about the users or potential users, I feel as if I’m more of the right track.

In July, I sent out the Pragmatic Manager email newsletter: 90% Done is Not Almost Done. I have finally posted it. Enjoy!

Bob Payne interviewed me at Agile 2008. We spoke about my initial plans for Agile 2009, and my (in-writing) project portfolio book. The link is here: Agile 2009 - Johanna Rothman - Agile Portfolio Management and Agile 2009. I had a blast with Bob.

If you’re wondering why it sounds like I’m chewing my cud (!), it’s because I was shivering. I was wearing a nice shirt and a nice jacket, but it was so cold in the area Bob had set up for the interviews, my teeth were chattering and my mouth was dry because I was so cold. Next year, I will bring my fleece, and possibly a scarf and gloves.

Glen Alleman has a post about program management, Managing Multiple Projects is Called Program Management which got me thinking. (I’ve written about program management in the past also: Program Management: Multiple Projects With Multiple Deliverables.)

But in the portfolio management book, I defined a few ways to think about your projects as programs:

1. You, and two other colleagues are managing projects that have interdependencies. In fact, you don’t have a product unless all three of you release at the same time. That’s a program and you need to treat it as such.
2. You are managing a bunch of checklist projects (you’ve done similar things in the past, and the risk is not in the project, the risk is in just finishing the work), but when you’ve done all of them, the company gains some sort of strategic advantage.
3. You are phasing releases of a product. That is, you’re working on release 3.2, then 3.3, then 3.4, and eventually 4.0. A program manager can manage the interdependencies among the releases, and a project manager would manage each release.

It’s the strategic part of “we don’t have success unless we all have success” that makes these examples programs.

BTW, I disagree with the difference between project and program managers that Glen quotes from the PMI Portfolio Management Guide. The same table (with the addition of portfolio management) is in the PMI’s Standard for Portfolio Management. IMNHO, a useless book.

Great project managers act like program managers in the table Glen quoted. But it’s worth thinking about program management, collecting related projects or project-like activities to fulfill a common strategic goal.

When I teach coaching or feedback skills, I teach them in the context of work. At work, as long as the feedback is about the work, or the work relationships, or it’s a question of safety, feedback is appropriate. Coaching, as long as it’s about work behavior is appropriate.

But a funny thing happened to me yesterday, when I didn’t give feedback. Mark and I had been at the beach celebrating one of the few sunny weekend days this summer. We were leaving, and I was all set to use the public showers. The showers are outside, three shower heads around the top of a post. There’s room for three people at each of the three posts. The dressing areas are single-person and private.

As I walked toward the showers, a man approached the showers wearing small white underwear. I have to admit, I am not current with all of male underwear styles, but this was close to a thong. There’s a problem when white underwear gets wet–it becomes transparent. I don’t know if he didn’t realize it, or he didn’t care. I did, but I kept quiet. I was quite uncomfortable (!) and just stood at another shower to rinse the salt off.

I asked Mark later, what he would have done. He wasn’t sure. That’s when I realized if either of my daughters had been with me, I would have verbally pushed that guy back into the dressing area. That’s because the context moves from “two adults who can ignore each other” to “an adult being not quite appropriate in front of younger people.” That’s an issue of personal safety.

I felt uncomfortable, but not unsafe. As soon as the context changed, it would have been necessary for me to give the man feedback. I could have said something like this. “Hi. I don’t know if you realize this, but your underwear has turned transparent in the water. I’m not comfortable. Can you please put something else on?” I suspect, that in a public area, as this was, many men would change what they were wearing based on that statement.

If you’re worried about giving feedback at work, don’t be. Look at the context. Make sure you talk to the other person, providing non-judgmental data (transparent underwear), explain the impact with “I” statements, and ask for a change in behavior. It’s not difficult once you practice. (See here for the feedback “recipe”.)

Feedback at work is almost always easier than telling a man his parts are showing. Well, for me it is. But, if you want to enhance your working relationships, and make sure everyone is working well and in a safe way, feedback is necessary. Practice it. Even with the guys at the beach.

If you’ve never been a victim of Medieval software project management, wow, I’m impressed. You don’t have to read the rest of this post. But if you’ve ever tried to break free of a legacy product/project, and haven’t been able to, you are not alone.

The problem is we can’t create a knowledge management system that can copy everything in a developer’s head. So we attempt to keep the developer chained to that product, only to break free if he or she leaves the company. I left a job, and the company asked me to keep a listing of all of the files for that product. I explained I had a limited short-term memory, once I started with other things. “But what if I need you?” the manager wailed. “How else will I know what’s in the code?”

Uh, read the code. That doesn’t always work–some people like to make complex code. Or maybe, their code needs to be complex and I just don’t get it. In that case, read the tests. Oh, there are no tests? Hmm, maybe pair-write the product before you get into the one-person-one-product conundrum.

Here’s what I did when I was a manager inside organizations, and what I suggest to clients now: make sure a team works on each project. That means no single-person projects, ever. A team to me contains all the people necessary to release a product. Certainly a developer and a tester. Maybe a writer, maybe a release engineer, maybe an analyst. Maybe a DBA. Whatever it takes to release a product, everyone’s on the team. Everyone participates. If they can automate their work and explain it to other people, great. But it’s not a team unless the team can release the product.

When enough other people know about the insides of a product, it doesn’t matter if all the developers leave–the testers can explain what’s going on. Same if all the testers leave, the developers know. If all the writers leave, the testers and developers know what’s going on. Sure, there’s a learning curve, but no one is hamstrung by legacy projects.

There is no such thing anymore as a single-person project. If all you’ve got is one customer, you’ve still got a two-person project.

Managers create legacy projects because they don’t understand productivity and capacity. What managers need to care about is the number of projects a team can complete per unit time, not how busy any one person is. If you can’t complete n project because you’re still fixing legacy project (which was project n - 4), your manager is not being effective and neither are you.

If you have a legacy project, insist on a team to finish it. Or, if you’re like me, you quit after a while because you didn’t get the team and you couldn’t take it anymore.

If you’re a manager, count those legacy projects, and stick them in your portfolio to either finish or kill or park somewhere if you really think you can’t kill them outright. But stop the partial-staffing of legacy projects. That’s nuts. Either staff it or not. Don’t make people leave because you can’t decide what to do with this project.

In Knowledge Management Needs to be Agile, Too, I said

If you put people in competition with each other *in any way*, they will have dis-incentives to share their knowledge.

John, in his comment on that post, said it seemed intuitive, but was having trouble articulating why. I’m here to help Some of my reasons, which all go to how people are evaluated and compensated.

Managers evaluate and compensate people for their knowledge, rather than the results they provide. Sure, a company might say “We want you to work together and share your knowledge.” But as soon as they pay people for their knowledge, not their results, everyone is in competition with each other.

And, if an organization pays people individually (even though all the work we do in organizations is via some sort of team), knowledge sharing goes right out the window. If you and I are in competition for raises (and paying people individually after evaluating them means that we are in competition), why should I share what I know with you? That sharing can only hurt me.

The only way I know to enable knowledge sharing across an organization is to:

• Pay for results
• Pay people “enough”so it doesn’t hurt them financially to cooperate with each other
• Use open-book management so people know who’s making what.

Sure, some people will share their knowledge because it enables the organization to do better, but those of us who know the company doesn’t love us are going to be much less altruistic. As soon as our sharing hurts us, we stop.