I love this book. Not because I am in it, but because of all the back-stories, the pictures, and the links. And, oh my goodness, the links.

I did not expect to love this book. I expected to like the book. I expected to learn something. I expected to entertain myself for an hour or two. After all, how interesting could it be? I’d been reading the Who Is… series on Yves’ blog. Yes, I’d missed a couple of people, but really. Put all the blog posts together, and have a book? So Yves edited, and added more links and edited and added more links, and maybe I’d missed a few people, but really, a book? How compelling could that be?

Well, you should read this book. You will understand how agile has become as strong as it is, not because of the signatories of the manifesto, but because of those of us who use agile in our day-to-day lives. How we live it and use it in our teams and our work. Read about Lisa Crispin and how she paired with Janet Gregory.

Read about Bob Marshall, Nicole Belilos, George Dinwiddie, and Jutta Eckstein. And those are just the people I feel as if I already know. Look at their beautiful pictures. Read their back-stories. Get to know them as people. And then, click on all of the links.

What is truly valuable about this book is the links Yves has collected for each of us Who Is people. There are links to each person’s web site, books, blog, videos, interesting stories, the list goes on. The links are what makes the book. Yves has created a collection unlike anything else I have seen.

Yves used Leanpub to create the book, which means you buy it now, and as he updates it, you get the updated version. What’s not to love? You get a wonderful book now, you keep getting a wonderful book, you read lots of different perspectives on how we all got to be agilists, and, you get all of these links.

Buy the book. Smile as you read it. Sigh as you read the one “Who was.” Laugh at the funny parts. Enjoy it. And, thank Yves for all the work. The links, my goodness, the links.

1. The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
2. The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

• Explain that velocity is not a productivity metric
• Say No and explain why
• Play the Double Your Velocity schedule game
• Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

If you liked the schedule games from the more traditional projects, you’ll love the agile schedule games. Please comment over there.

Except, none of the other process improvement approaches have been built on the notion of self-organizing or self-managing teams. None of the other approaches have been built on the idea that leadership emerges from within the teams, not from the top. And, I, the queen of tact and diplomacy, need to find a way to describe this to my clients.

Agile and lean provide a team with plenty of benefits: visualizing the work in a backlog, ranking the work so it’s clear what the first thing to do is at any time, making it possible for a team to swarm around the work, knowing what done means, demoing the work often. All of these benefits make it possible to allow for frequent change, which is the biggest benefit of all.

But the reason agile and lean work so well is that the team drives the work. The team is at the very least, self-directed, where the team works together, but still has some management guidance because they don’t know how to manage their team membership, for example. Many agile teams are self-managing, and some teams are self-organizing.

If the senior management or project management teaches agile, especially if they have never lived agile, it’s incongruent. It would be more congruent to have the team members teach each other agile. That would be the team driving the work.

I can sympathize with management wanting to cap their expenses transitioning to agile. And, training project managers as trainers who have no experience in agile is not a cost-effective way to create a successful transition. Neither is training managers with no experience. The problem is this: in order to teach agile, you need experience doing it so you can diagnose the problems as you see it in the training, because there is no recipe.

There is no recipe because every team of people is unique. There may be common patterns of pitfalls, but how each team solves those problems is often unique to their context.

This is a problem. It means that in one organization you might not have just one definition of agile if one project has silo’d teams across the world and another project has cross-functional teams in one location. The definition will come from the people on the team who will discuss what done means for them, and how they will handle the issues of where the people are, and how to manage the deliverables. The team members will lead from within the team.

How have you explained this notion of the leadership arising from the team to managers?

“Such investment will break our economical model.”

Wage cost is not the same as project cost. And, if you don’t outfit the “remote” team with the necessary infrastructure as the “headquarters” team, you can save a bundle. (Do you hear my sarcasm?) Of course, you pay for it in the cost of communication, the cost to ask a question, the overall schedule delays, and project cost. And, if the remote team are the testers and the headquarters team are the developers, well, guess what? You’ve got second class testers.

Types of Teams

In agile, we can’t afford second class testers (or second class remote teams), because the delay in acquiring information during the iteration is too high a risk. That’s Israel’s Friction of Agile bumping against the economies of scale.

If you look at the types of teams in this figure, you can see that everything above the middle line, the co-located and distributed cross-functional teams, have a shot of working well in agile, assuming they have adequate tools. Silo’d teams, and the dispersed teams have built in delays because they are not already cross-functional. Can you make them work? You can make anything work. Will they have communication delays? Yes.

But, as soon as you remove adequate tools from distributed teams, all bets are off.

If your economic model for distributed development is this: “Don’t pay people and don’t pay for their infrastructure,” I have a reply. “You can ‘save’ all you want on wages and infrastructure. You will pay for it in defects, technical debt, unhappy customers and eventual product death. Is that what you want?”

Infrastructure is inexpensive these days. I don’t understand why you would technologically handicap a team.

When you are a manager, program manager, project manager—anyone who leverages the work of other people—you have to limit your own WIP. If you don’t, you can’t pay attention to the most important work you have to do. If you don’t pay attention to the most important work you have to do, and finish it, the people who depend on you for the decisions you make, are working on the wrong thing. If they are working on the wrong project, that means you’re not managing the project portfolio well. If they are going in the wrong direction on a program, that’s waste. If they are going in the wrong direction on a project, that’s waste. Going in the wrong direction doesn’t have to be about requirements, although it certainly can be. It can be about architecture, or a legal decision, or when to get training involved, or all those day-to-day myriad decisions for programs and projects that manage risks.

That’s why I like using kanban or some version of WIP limits for project managers, program managers, and senior managers. No, I don’t often tell them this when I coach them, not at the beginning. I explain we’re going to get to done on a few things, and then a few more things, until they achieve some flow of work through their work. After we finish a few weeks of work together, then I explain what a kanban board looks like, and I ask them if they want to use one. Often, the answer is no for managers. Often, the answer is yes for program managers and project managers. And then, they want to use a freaking tool.

I explain the best tool is a wall and stickies. That the work will change often enough that otherwise they will spend all their time updating the tool, and they will start cursing the tool and the time they spend in the tool. “But how will I share what I’m doing?” I tell them to take a picture with their phone and post it on their common site. Everyone has common web access in the form of a wiki, blog, or something else. It’s easier and faster to post a picture every day than to update a tool.

Transparency in work is great for programs and projects. I would say it’s necessary. I like it for managers, too. Is it necessary for managers? Well, sometimes the work that managers do has to stay quiet because of the regulations that outside forces impose on the organization. I know that many of my management decisions were improved when I asked for—and received—advice from my management team. Being a more transparent manager helped me. I was too immature at the time to post my work. At least I discussed it.

One of the questions I hear a lot is this: “If I’m lean as a project/program manager, how does that work if the technical teams are agile? They are working in iterations and I’m working in continuous flow. How do we sync?”

This is a great reason to keep the iterations short. If you allow the iterations to be as long as 3 weeks, you will feel as if the iterations take forrrreeeeevvvveeeerrrrr. Sometimes, even 2-week iterations will feel tortuous.

• You can ask the teams to work in flow inside their iterations, but I have a rule about changing the contents of an iteration once the team has committed to it: DON’T DO IT.
• You can ask the team to work in flow, but not all teams are comfortable working that way.
• A much better option is for you to change the way you work. Try to look ahead a little more and anticipate a little more. Yes, this might increase your waste, which is the topic of this post. You cannot win them all.

Can you find the Golidlocks moment of no one having WIP, and no one having waste? Maybe. It takes experimentation and time to work together, which brings me back to Yves and his fine experiment.

Yves has not worked with most of us before. Yves and I have known each other through email, and one or two in-person conversations before he asked me to be in his series. One of the ways I limit my WIP is to respond to emails such as his quickly. I was on vacation and turned around his email within 24 hours, which surprised him. And, then a number of other people surprised him in a similar way. So, Yves did not have experience working with all of us before. I don’t think Yves could have discovered that Goldilocks moment last summer, not without a lot of experimentation. He did experiment. He discovered. He learned. Through his transparency, the rest of us learned, too. Thank you, Yves.

Re the Who is series: I hope you read the series, and go back all the way to Lisa Crispin, who was first in the list. If you ever have a chance to participate in a conference with Lisa, do so. Aside from being generous in her comments on the who is series, she is generous with her tweets. She hears the nuggets in people’s talks and tweets them. And, she is fun to hang around with!

That’s the ability of the less powerful people in the situation to talk to the more powerful people in the situation. Where do we hear about successful agile transitions?  Israel, Denmark, Sweden, New Zealand, Norway, Finland: countries, and by extension, organizations, that we assume have low power indices. This is an assumption. I know of organizations in these countries that do not have low power indices.

The countries, and by extension, organizations, have had more trouble with their agile transitions, have had a higher power index. That’s because it’s more difficult for people in less powerful positions to talk to people in more powerful positions.

This has implications for geographically distributed teams, for project managers, program managers, for anyone working across the organization to accomplish work, not just the agile teams.

What can you do about it?

1. Acknowledge it. Recognize that some people are intimidated by others and their titular power in the organization. (I’m not, but that’s just me :-)
2. If you have to work with people who revel in their titular power, acknowledge their power, because it makes them feel good. Now, move on. Know what you want, and help them acknowledge that what you want is also necessary for the organization to succeed.
3. Stay positive. Sometimes, the other person needs to put you down, because he/she has no other way of dealing with other people. I allow it for a limited timebox (10-20 seconds, maybe up to a minute) and then I move the conversation on.
4. Look for common/joint objectives. What will make us both happy? Often, this puts us on the same power plane. Usually the other person doesn’t recognize this until we are done talking.
5. I’m happy to build a long-term relationship to make this work.

I avoid gossiping about other people. I need to keep my integrity. I don’t make promises I can’t keep. I need to keep my integrity. I especially don’t let the other person blame my team, my project, or my program for the other person’s emergencies or failings. I also don’t blame his/hers. I keep my integrity. I didn’t say this was easy!

I’ve come home from these meetings and said to Mark, “I need a drink and it’s not water!” When you have these conversations, you are re-educating the person about culture. Sometimes it takes, and sometimes it doesn’t.

Agile exposes this power differential. Yet another transparency.

Can you make and keep the transition to agile with this power differential? I don’t know. For me, the jury is still out. When I see organizations with a high power differential, they keep falling back to command-and-control approaches, because the power differential is so ingrained in their culture. This is why a transition to agile is not just a technical issue, but a cultural issue too.

If you want to explore this in more detail, please join me at the AYE post-conference workshop (if you will be at AYE) or at Agile Testing Days for my tutorial.

I’ll also be exploring this at Agile Vancouver in my keynote and tutorial, and in my tutorial at OOP. (My influence tutorial is an entire day at OOP.)

Managers create a system, an environment, in which the teams can thrive or dive. But which one? And, how do they do it?

Agile managers create an environment of collaboration for the teams and for the managers. They do this by optimizing at the highest level of their influence, not the lowest. This is a huge change and challenge, because it may be opposite from how they have worked and have been asked to work in the past.

I’ll discuss the four prongs of program management: to set the strategy, to build trusting relationships, to remove organizational obstacles, and to build the capacity of the organization.

Please RSVP no later than, September 14, 2011, to:  pferguso@yahoo-inc.com