Tweet This Post

Tweet This Post

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

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

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

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

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

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

Have a great New Year’s everyone.

Tweet This Post