The Regenerate Web

Erik Gfesser posted a lovely review of Manage Your Project Portfolio. Thanks, Erik!

Tweet This Post

I wrote a little article about Barriers to Agility in the most recent version of PragPub, the online magazine from the Pragmatic Bookshelf. There’s a bunch of other good articles in there, too. Andy Lester has a great article about speaking as a way to practice interviewing, a bunch of comments/thoughts/rants about the iPad, and much more. Take a look!

Tweet This Post

I just returned from Tokyo, where I keynoted at JaSST, the Japan Symposium on Software Testing. 10 years ago, when they started the conference, maybe it was just about testing, but now it’s evolved to be about quality in the organization.

Some highlights from my trip:

• Everyone (and everything) I met appeared quite orderly. Everything had a place and everything was in its place. I saw this at the lost-luggage counter, in the hotel, and at the conference.
• I was pleasantly surprised that the subway ticket machines had an “English” button so I could buy my ticket and know what I was doing. The maps were in English as well as Japanese, so I could know in advance what my trip would be and which stop to get off at. I had a little trouble with which track, but that’s probably because I was jet-lagged.
• I was pleasantly surprised to see evidence that the simultaneous interpretation for my keynote worked fairly well. I could tell because people laughed when they were supposed to :-)
• For the tutorial, I did not allow enough time for the consecutive interpretation or for the questions about agile, so I needed another 20 minutes, which I did not have :-(
• I was a little concerned that when the panel prepared for the questions, I thought we might be boring. Nope, we were thought-provoking and funny.
• My Japanese hosts were amazingly solicitous and helpful for my entire experience: to/from the airport, to/from the conference, to/from sessions at the conference

I had a blast. I hope I have an opportunity to return to Japan. Now, all I have to do is get enough sleep so I’m awake during the day…

Tweet This Post

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

Tweet This Post

Wow! I can hardly believe how many people have signed up for the brand-new free teleclass, “3 Crucial Factors For Preventing Your Agile Titanic” that Gil Broza and I will be teaching next week!

I guess we struck a nerve with many people who want (or need) to get Agile going, and who don’t have other expert help lined up.

Go here when you’re ready to reserve your seat.

On this call you’ll learn:

• The 5 characteristics of your first Agile project that you must get right (but most people don’t consider).
• What to expect if the first project is already selected and it doesn’t exhibit all 5 characteristics —and how to avoid disaster.
• How to choose a winning team: one that can effectively leverage Agile to deliver the project and extract useful lessons for subsequent Agile roll-outs. (Hint: That’s not necessarily the people who happen to know the codebase or be available this minute.)
• What to do if the team is already selected and you’re not sure it’s the right place and time for all of them.
• How to turn this group of individuals into an Agile team. Unfortunately, many people think that just by referring to them as “Agile team” or “Scrum team” and putting them in the same room, they will self-organize and collaborate. Nope, it doesn’t work that way.

Go here to reserve your spot in this complimentary teleclass.

If you have questions, do email me.

Tweet This Post

I have a question for you:  Have you come across team whose first attempt at Agile adoption resulted in conflicts, pain, or just fell short of expectations?

I’ve met plenty of teams like that. I’ve heard statements like “nobody knew what they were doing”, “management still dictated an impossible deadline” and “those sprints became small death marches”. The most common blanket statement is “we tried it, it didn’t work.”

I’ve been coaching and training for years, helping people avoid just this sort of mess AND do Agile really well. But not everyone has access to an experienced coach, and many competent do-it-yourselfers get into trouble. Agile adoption is hard!

All this is about to change. On January 20th, my colleague Gil Broza and I will be teaching a free teleclass:

“3 Crucial Factors For Preventing Your Agile Titanic”

This is our way of helping you get Agile off on the right foot–and all you have to do is be on the phone. No need for approval, sign-off, expenses, or convincing anyone.

On this call you’ll learn:

1. The 5 characteristics of your first Agile project that you must get right (but most people don’t consider).
2. What to expect if the first project is already selected and it doesn’t exhibit all 5 characteristics —and how to avoid disaster.
3. How to choose a winning team: one that can effectively leverage Agile to deliver the project and extract useful lessons for subsequent Agile roll-outs. (Hint: That’s not necessarily the people who happen to know the codebase or be available this minute.)
4. What to do if the team is already selected and you’re not sure it’s the right place and time for all of them.
5. How to turn this group of individuals into an Agile team. Unfortunately, many people think that just by referring to them as “Agile team” or “Scrum team” and putting them in the same room, they will self-organize and collaborate. Nope, it doesn’t work that way.

Click here to reserve your spot right now.

This call is right for you if:

• You recently started an Agile effort, you’re thinking about it, or you’re planning to very soon. Perhaps you’ve been given a mandate: “Go Agile in 2010.”
• You have some basic training in Agile. You may have taken a course, read a book, been to conferences–whatever your experience, you have more than passing knowledge of the Agile principles, values and practices. Doesn’t matter whether that’s Scrum, XP or something else.
• You and your team will feel the consequences if agile fails to live up to other people’s expectations. Also, your project has or will have a team of some significant size, meaning that your organization is actually investing in the project.
• Professional Agile guidance has not been secured (for whatever reason). You or your team don’t have access to an expert who can look at your situation and offer practical ideas to guide you.
• Agile is among your personal objectives for the year. Yes, this is a terrible idea, and you may not have control over that.
• You are experimenting with Agile, and want to give it a real shot at working in your organization.

To sign up for the call click here.

Do you have colleagues and friends embarking on their maiden Agile voyage? Feel free to forward this to them — and remember to reserve your spot here first!

Tweet This Post

I’m back from our AYE conference planning. I had a blast.

The best thing, aside from being able to publish our program, is that we discovered that when we are together, the creative juices fly. For example, instead of two people pairing to teach the warm-up tutorial, we decided we all teach the tutorial. Not all of us all the time. No, we’ll still pair-teach, but we’ll pair with different people over the course of the day. That way we all get to know the new participants. Since AYE is so participatory, we expect this will help us learn the new peoples’ names. And, it might help these people make decisions about which sessions to choose when.

I’ve updated all my sessions. This year, I’m offering

• You Are Here. You Want to Go There?
• The Budgeting Black Hole: Predicting the Unknowable
• Coaching is a Two-Way Relationship
• Agile Program Management: Another Approach to Large Projects
• A Fresh Catch, so I can have a little while to see what strikes my fancy as the conference gets closer. Or, if you decide to participate, you can request a session from me.
• Coping With Change in Your Life

The Coping with Change session is a brand new session that does not arise from my work, per se. My fellow hosts suggested I use some of the ideas from my previous Reinventing Yourself sessions and what I’ve done in the past four-plus months to manage my life and offer a session. Let me know if you think this is a good idea :-)

We discovered that when we meet in person, we are much more creative than we are on the phone in our biweekly phone calls. We might have developed some of the new ideas, such as the Fresh Catch idea on the phone. Maybe. But I don’t think so.

We have an innovative program this year, aside from it being experiential and interactive. Our tagline this year is “Exploring Human Systems in Action.” We will be designing the post conference tutorial to help people take advantage of what they learned during the conference and explore more, and we don’t quite know what that looks like yet, so it’s still a Fresh Catch.

As hosts, we’ve known each other for more than a decade. We’ve worked together on the conference for the last 10 years. We work on our relationships. We talk biweekly all year and meet once. But this year we realized that we were much more creative in person than we ever are on the phone. The ideas flowed–we had no problem generating ideas.

On our calls, we often have trouble generating ideas. I don’t know why. But we innovate in person. That’s why we’re going to work on getting together again later this year.

In the meantime, you can review the whole AYE program and register. Yes, registration is up and working, I believe. If not, let me know. That’s my job to resolve.

Tweet This Post

The December Harvard Business Review has an article, Is the Rookie Ready? (You have to subscribe and pay to read the whole thing.) The story is this: Kristen is the new project manager, reporting to Tim. The old PM left because Tim, who’d been her manager for 6 months didn’t know how to work with her. Tim hears from an old customer two weeks before Christmas, “Please help us and send a team down to install your software, the stuff we rejected a year ago because it was too expensive. Oh, and we need it by Jan 1.”

Tim agrees (Big Red Flag here). He asks Kristen to go install and make the standard software work (no customizations) and to take whomever she needs. Kristen doesn’t think this is a such a good idea, but Tim tells her it’s her job to make it happen. He tells her to tell the team ‘we’re going to do this.’

The question to the famous commentators is, “Is the Rookie Ready?”

Wrong question. Michael Schrage suggests hiring back the old PM. But, then he says “Kristen is in over her head.”  NO. KRISTEN IS NOT IN OVER HER HEAD. TIM IS A TERRIBLE MANAGER. We can’t tell if Kristen is in over her head.

Sorry for yelling, but I just couldn’t take it. (You should have heard me while I was reading the article :-) Anyone would be in over his or her head, because the only way to solve this problem is to have someone intimate with the product install it. Even then, this is a 6-week project. Why would Tim agree to a 2-week install? Sure, the customer wants it. Customers want all kinds of things. They can’t always get what they want, when they want, for the price they want.

Tim is a terrible manager, because he keeps taking the best programmers and making them managers (part of the story I didn’t summarize). If they want to be managers, that’s fine. But it’s not clear Kristen wants to be a manager. And, he doesn’t even push back on the customer. And, Tim has allowed a standard product without a standard install.  (Ok, it’s a big product. Maybe a standard, unattended install isn’t possible. Maybe it really does need 6 weeks to install. So, why isn’t there an install group that does this??)

Why would Tim agree to do a special install over the holidays without asking for more money? Why would Tim even think this is acceptable to do without asking the team who will do it? Because Tim isn’t the one giving up his vacation. The fact that he even thinks this is acceptable behavior just astonishes me.

It’s time to ask if this project is strategic to the company. (Where are all the other managers? Why is Tim getting this call? HBR, I can write a more realistic story than this.) Maybe this is not even a project to take on.

If they’d asked me to comment on this story, here’s what I would suggest:

1. Decide if the project is strategic to the organization. Why has the customer changed their mind on what’s too expensive? What is an acceptable fee for doing this project in their time frame?
2. At the same time, before committing anything to the customer, ask the team if they are willing to make this happen in the requested time frame. If not, what is an acceptable time frame? Would that time frame change if they had the experienced project manager back? What would make the time frame decrease?
3. If the project is strategically important, and the team is ready to commit to something, negotiate that with the customer. Never assume it’s fine to commit your team to work they haven’t committed to.
4. Organize timeboxes of work starting now and through the final deliverable, so there is transparency about the project’s progress. If the project falters, you still have the option of getting the experienced PM back and see if that makes a difference.

Tim is creating management debt by making bad decisions. He’s not managing the project portfolio–what other projects are now crises? He’s not managing the people. He’s certainly not building a trusting relationship with his people. What the heck is he doing?

I’m so worked up about this because I worked for a jerk like this once. He committed all kinds of deliverables on behalf of my project to the customer. Half the time, he didn’t even tell me. He never once thought what was good for the organization or even the customer.

Managers like Tim kill an organization. They create management debt by not managing people correctly, by not managing the project portfolio correctly, and by not managing the customer correctly.

The question is not whether the rookie is ready. As Paul Muller, one of the experts who commented said, “Every manager has a first crisis, whether it’s three days or three years after assuming the role.”

The question is not “Is the rookie ready?” The question is why is Tim employed at the organization? Why has no one seen the messes he has made?

Tweet This Post

Daniel wrote a lovely post, Kill, commit, or transform your projects over on praglife.

Keeping projects around that are not staffed, multitasking on several projects (committing to none of them), and running away from reality doesn’t help anyone. The projects don’t finish faster–they finish, if at all, slower. The people don’t have a sense of accomplishment, they feel as if they have a never-ending mountain of work.

Sometimes, transforming a project is as simple as asking “How little can we do and still have a valuable product?” Too often, we fall into “how much” thinking, instead of how little. Sometimes, transforming a project is much bigger.

Whatever you do, don’t blindly commit to projects. I’m in the process of drafting a post about that and will link it here when it’s done.

Tweet This Post

I just posted the October Pragmatic Email newsletter, You Can’t Do All the Work. Now What? If you subscribed, you’d have already received today’s….

Have a great New Year’s everyone.

Tweet This Post

Rant on.

There’s a flame-fest on the scrumdevelopment list about the use of “resources” or “people” to describe the human beings on projects.

I like “humans” or “human beings” or “people.” And, I actually prefer “resources” to “man-hours.” I can live with “people-hours,” and prefer that to “resource.”

I bet you’re a little surprised. I’ve written that People are NOT FTEs. And, in A Funny Story About Manage It!, I said that I didn’t refer to people as resources.

So why would I prefer to be a resource than repository of man-hours? Because it doesn’t matter how many hours I work, dammit. I am never going to be a man. (We can all be thankful for that!) I don’t count in man-hours. And, man-hours assumes that we can tell how long a task takes. Ha! Not a new task, which are the most interesting tasks. Fuggetaboutit.

I like calling people “people” and talking about what they as a team can accomplish. People are rarely fungible. (I’ve never seen true fungibility, but I haven’t seen everything.) Resources, to me, mean machines and other hard equipment. Every so often, I think of resource as the on dictionary.com:

a source of supply, support, or aid, esp. one that can be readily drawn upon when needed.

That resource might be a human who is not a part of our team. Maybe that’s a slip and it makes me more human.

I grew up looking for jobs in high school when the classifieds were split into “men wanted” and “women wanted.” The men’s section was always at least five times larger than the women’s section, and had the interesting jobs. I thought I was over it, but I guess not. I’m still rankled by the difference. At least “resource” treats us all the same way.

A project team is composed of people. Those people, working together as a team, have a certain capacity. Let’s keep that in mind, ok? I don’t care if those people are red, white, blue, black, brown, purple, men, women, something else. I care about how well they get along and what they, as a team, can do. Team capacity, that’s the key.

Resource is a backwards way of attempting to define team capacity. So, our HR departments (I much preferred when they were called “Personnel” btw, which they were when I started to work back in the age of the dinosaurs) don’t get it. HR doesn’t get much, except how to keep the company out of court. (See I Don’t Hate HR.) We, the technical leaders, will lead HR in how to hire people, in how to manage people, and in how to compensate people who work in tight-knit teams.

In some ways, I think of HR and their policies as a resource to me, as a manager or leader. But I certainly don’t think of the people with whom I work as resources. Sometimes I call them project staff when they are a group of people. Sometimes I call them a project team, when they work as an interdependent team.

They are people. Just like me.

Rant off.

Tweet This Post

If you have to make yourself a New Year’s resolution, resolve to be a Passionate Programmer (or a passionate whatever-you-are). Chad Fowler wrote a delightful book, The Passionate Programmer: Creating a Remarkable Career in Software Development. What Chad doesn’t realize is that you don’t have to be a programmer to read this book. You can have any role in software and benefit from reading this book.

The book is organized into 5 parts:

1. Choosing Your Market
2. Investing in Your Product
3. Executing
4. Marketing…Not Just for Suits
5. Maintaining Your Edge

Chad has 8-13 lessons/guidelines/suggestions in each part. Some of my favorites are:

From Choosing Your Market: “Coding Don’t Cut It Anymore”, Fowler says you should learn the business domain of your product. I also liked “Be a Generalist” and “Be a Specialist” in this section. Why both? Because you need to know how things work outside your (small) job label to be really effective. And, you need to know specialized content to be great at a job. Luckily, Chad has “Act on it!” sections to help you see what to do.

In “Investing…”, the lesson I liked best was “On the Shoulders of Giants”. If you read existing code (or tests or project plans or requirements), what insights do you gain?

In “Executing” the lesson I liked best was “Say “No”". Chad has all kinds of reasons about why and how we need to say no at work. My favorite quote:

“If someone always says “yes,” they’re either incredibly talented or lying. The latter is usually the case.”

In the Marketing section, there’s a lesson called “Build Your Brand,” where Chad describes how to think about your brand (your name) and which types of projects to affiliate yourself with.

In the Maintaining section, the lesson I liked best is “Avoid Waterfall Career Planning.” As Chad says, your career is the most complex project you’ll ever have to manage. Careers are not linear. If you look at successful people, they took advantage of opportunities. (This is why I hate the interview question, “Where do you want to be in 5 years?”)

Do yourself a favor and buy this book. (Yes, your manager should do this kind of career development with you, but most managers don’t know how to do it themselves, never mind for someone else.) On the Prag site, you can get the book in hard and a variety of softcopy formats. On Amazon, just hardcopy.

If you’re looking for a job, check out my review of Andy Lester’s Land the Tech Job You Love.

Tweet This Post

A new article is up, Using the Project Portfolio to Move to Incremental Project Funding. It’s up on PMBoulevard.com. (Free registration required). Enjoy!

Tweet This Post

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 have fixed the how-do-I-get-up-in-the-morning-when-Mark-is-traveling problem. I bought a new Sangean RCR-5 Digital AM/FM Clock Radio with a Sangean Pillow Speaker – #PS-100 – D/S (I love them both) and now, I hear the alarm, no matter what side I sleep on! I don’t have the problem of blasting my good ear with noise that my deaf ear can’t hear anyway :-) I had to buy a new clock radio because my old one did not have a headphone jack, so I couldn’t just get the pillow speaker.

Now that I’ve fixed that problem, number 2 is now number 1. That’s the alarm-when-I-travel problem. If anyone knows of a vibrating watch that works (I bought one that doesn’t), where the alarm keeps going until you shut it off (I bought one where it vibrates once and shuts off), let me know. I could buy another pillow speaker for travel, and assume every clock radio wherever I go in the world will have a headphone jack. I prefer not to make that assumption.

Tweet This Post

A client recently asked me how many people should be on his agile team. “I have a two-person project here, and a 23-person project there. Do I want two teams, one of 2 and one of 23? Oh, and how many testers do I really need?”

I can believe there’s a small and short project that just needs two people. But when I asked him, he meant just two developers. I suggested he might want at least one tester, and what was the project? A boot ROM. I asked about the deadline. Three weeks. Was there any automated testing so far? No. Were there edge cases that were a problem? “How did you know that’s why I needed to rev the boot ROM?” (Lucky/educated guess.) I suggested three or four testers and maybe more people to develop some small simulators so the developers could test as they proceeded. “Why do I need so many testers?” Because there are so many possibilities of boards, OS’s, firmware versions, and some software, that even with combinatorial testing approaches, the fact that they felt they needed to boot all the way each test meant no test could take fewer than 5 minutes. That means a given tester is limited in the number of experiments he/she can do. If they had more time, maybe they wouldn’t need as many testers, and the developers would have to do more testing.

Now, for the 23-person project. I explained I would break that group into 3 teams, making sure there was a developer, tester, customer/ba/requirements person, writer, some sort of project-manager-type person on each team, and add however many other developers and testers the team thought they needed. “Isn’t there a correct ratio of dev to test?” No. (I discussed this in Manage It!: Your Guide to Modern, Pragmatic Project Management and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects and in It Depends.) Testing is all about obtaining enough information to assess risk. If you can’t easily test to get the information, you need more testers.

As for team size, I did some research (in addition to my experience) for Manage Your Project Portfolio, and found that while there is a somewhat ideal team size of roughly 6-8, fewer than three leads to worse decision-making. More than 9 leads to people grouping themselves into two teams. Once you have 10 or more people, the communication paths are so high that not all people have commitments to each other. Without those commitments, it’s impossible to create a team. You have a group, not a team.

I wish there was a recipe I could give you for team size and dev/test ratios. I can’t. No one can. Assess how many people need to commit to each other and how you will get the information from testing. Then you can make an informed decision.

Tweet This Post

I’ve been working with several management teams recently. They realize they need to change how they are organized in order to really make the agile teams even more productive.

For example, what good is a functional manager? If functional managers don’t need to assign tasks and check on how the work is going (the team does this), the functional manager needs to build a trusting relationship with people, and provide career development. The manager sets the mission/purpose of the group. The manager needs to see when the team (or teams) need more people, and to start and lead the hiring process. The functional manager may act in what I think a technical lead role is: to help uncover other ways of working, whether that is specifics (extend the design this way, test that way) or to coach the person into recognizing where to look for help. And, the big decision that managers make: which project to work on now. (Of course, there is also strategic planning, customer visits, etc.)

Project managers/Scrum Masters/whomever is charged with protecting the team’s process can’t do this work. Managers need to do this management work. But should there be development and test managers anymore? I think not.

Now, I can’t tell if my background is coloring my opinion here (of course it is, JR!). I was a development manager and a test manager at the first and mid-levels. I ran several departments, both in product companies and in IT. When I was a manager, first of development, we didn’t have professional testers. We did our own testing. We were ok at it, because we tested each other’s pieces of the product. As a test manager, I knew what the developers were going through, because I’d been a developer and a development manager. And, because I focused the test group on discovering more information (that’s the mission/purpose thing at work), the testers’ information became ever-more-valuable to the developers. I was a better manager because I understood what was going on between development and testing. By that time, I also understood the writers, even though I had not been a writer or managed writers. When I managed an entire engineering group of 80 or so people, I found that the bulk of my work was helping the functional managers understand the pressures on the other managers so they could work in a way that made sense for the entire organization.

In a technical agile organization, everyone is organized into cross-functional teams who deliver working chunks of functionality every few weeks. If the teams don’t have specialists, why should the managers be specialists? Isn’t that an outmoded way of thinking?

I should explain that Mary Poppendieck probably disagrees with me. We were talking about the role of the matrixed functional manager on an agile team while we were in Vancouver at Much Ado About Agile. I’ve been thinking since then, and working with my clients. I still disagree that the functional manager needs to provide specific-to-the-function technical leadership. I agree that coaching is necessary, but that doesn’t require a test manager for testers or a development manager for developers. It requires a true manager who can coach and help find the answers.

If we are asking the technical staff to be better at a wider variety of tasks, we need to ask managers the same thing.

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 receive a number of please-link-to-me requests each week. Some are for products, some are for random sites. I received one a couple of weeks ago and decided not to respond because I wasn’t going to accept the link request. I received another request, this time with a please respond with an “aye or nay”. I replied “no.” I thought I was being helpful.

Apparently not.

I received another email from the requestor telling me “We had sent you a business proposition. Your response to it is curt, rude, unprofessional and uncalled for. This “discussion” is over. Thank you for nothing.”

You betcha. Except now I remember the product’s name and I will remember to tell people, if they ask me, whether they should do business with these people. Nope.

I certainly see how a negative one-word reply could be seen as curt. Except, they asked me for it! Oh well.

Do be careful about what you ask for. You might just get it.

Tweet This Post

Dave and Bob have great comments on my post, Might Three Backlogs Be Better Than One?. Dave is describing situations where management is making reasonable decisions, not incurring management debt, and by extension, technical debt. Bob and I have experience with significant management debt. (Take a look at Musings About Management Debt for more information about what I mean by management debt.)

Let me provide a little more perspective on these situations. The clients range from large systems of up to a million lines of code (but still software-in-the-small) to software-in-the-large systems of 14, 15, 16 million lines of code. These systems have been in existence for more than 5 or 6 years. They are the flagship, and sometimes only, product that creates revenue. In each case, management is fairly new. The product owner players are new. Many of the technical people are new.

No one knows enough to make good decisions. Yes, they should have one backlog, and they don’t know how to prune the defect list. When you’re talking about more than a few thousand defects, the number is just too big. When your builds take longer than one day, when you have no automated tests, when you’re using a configuration management system from the ’70s (ok, not quite that bad, but close), and you don’t know how to break down the work into small chunks, it’s all overwhelming. Oh, and don’t forget the customers breathing down your neck for not just the defects you need to fix yesterday, but the features the sales people promised tomorrow.

One VP told me he could not make the decisions. He was concerned about who he needed (”do I need all of Engineering??”) and the time to rank into one backlog (”We’ll be here all day and we won’t be able to trade off against features and defects”).

He’s inherited a situation not of his making. He knows that if he can get people to start working in an agile way, they could make progress and finish some work. That would make their decision-making easier. But he has no roadmaps for feature sets for the product to see into the short-term or long-term future. He doesn’t know how many of the 1000’s of defects are still valid. (He thinks more than he wants.) Everybody is nervous. No one feels as if he or she can make a decision alone. The notion of a product owner as a “single, wringable neck” (do I credit Mike Dwyer or someone else with that phrase?) is not something they are ready for. They wanted a committee. I did manage to talk them into a committee of 2: one technical person and one marketing person. That technical person is the erstwhile project manager and the marketing person is talking himself into being a product owner.

I don’t claim these folks are agile. I don’t think they would either. They are working in timeboxed iterations. They are trying to finish valuable chunks of work in those timeboxes. They are struggling with how to make their decisions.

One thing I know about decisions is that the smaller the decision, the easier it is to make it. When you have to make tons of decisions that last forever, it’s really difficult, especially if you think you don’t know enough. At first, they all thought their technical debt was too huge to make inroads. But when I explained how to break down their technical debt into user stories, and that they didn’t have to tackle everything at once, that if they could just get the build to take less than a day they would already be ahead of the game. They didn’t need to stop developing features or fixing problems to address their technical debt.

As we see more people who have used a phased approach to development for years, and have not had tremendous success move to agile approaches, we will see people who may not be ready for real agile, but are ready (desperate?) to try something else that will provide value. We need to help them move from their previous insufficient decision-making to decision-making that will work. I do like baby steps. (See  Small Steps Are Good; Be Careful What You Call Those Steps).

I do worry about the issue of three backlogs. In the face of no decisions, I still think it’s better to make some decisions even if the outcome of those decisions is not one backog. Maybe other people have had better results nudging decision-free organizations to decisions faster than I have. I do think that the visibility of the different kinds of work can help people out of their defeatist attitude of “We have so much to do, we can never finish it.” One of these clients is actually pruning their defect list this week. The reason they can do that is because they took one story off the technical debt list, finished it, made so much more progress in just two weeks that the person-who-might-be-called-the-product-owner-but-is-resisting-the-role asked if they could finish a few defects in the next iteration, and how many did they really have anyway? They have bought themselves room to breathe.

Agile–real agile–is about making decisions based on business value, and delivering valuable chunks of work in a small timebox. If you have an organization that can’t decide on business value, you are in trouble. If you have better ideas, I’d love to hear them.

Tweet This Post