The Regenerate Web

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

Last week, when I was on vacation, my most recent Stickyminds column went up. I somehow expected more comments. Maybe other people were on vacation, too?

Tweet This Post

One of the problems many people encounter when moving to agile is that they (literally) cannot imagine iterations shorter than 4 weeks.

I rarely recommend an iteration as long as 4 weeks now, and if people insist on 3 weeks, suggest they find the root cause for the reason their iteration needs to be so long. “Our builds take too long” or “our testing takes too long” are the most common problems I’ve heard. If you know what causes you to need more time, you can make a conscious decision about what to do. Do you want to address that technical debt now? or later? Every time your iteration needs to be long, it’s because you have technical debt of some sort. You can choose not to address that debt now–but be conscious of that debt.

There was a question about the length of iterations on the scrumdevelopment list. Ron Jeffries said that he and Chet regularly paired in 2-hour iterations. With our teleclass, Gil and I often pair for an hour or two. We decide in advance how long to pair for, so we timebox our time, and then we do the work.. We have daily standups where we replan what we’re doing for the day.

Does it make sense for you to have one-day or shorter iterations? It depends on who your customer is and when you can get feedback. But why not consider how short your iterations could be, and remove the obstacles to those shorter iterations? Your project will thank you.

Tweet This Post

I’ve been working with Gil Broza on our teleclass series, Prevent Your Agile Titanic, both on marketing it and on its content. And it never fails, we have questions for each other almost every day. Sometimes I’m developing something and it looks “funny.” So I ask for review. Sometimes, as with the content, we discuss and one writes, and then we switch.

Pairing seems natural to us. We hadn’t paired before this venture, and that doesn’t matter. We are both ready to pair, which helps. Neither of us have egos that get in the way of the outcome: a great series of classes.

Tweet This Post

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