Do You Need to Create Virtual Teams with Freelancers?

Have you seen Esther Schindler’s great article yet? Creating High-Performance Virtual Teams of Freelancers and Contractors.

Here’s the blurb:

Plenty has been written about telecommuting for employees: how to encourage productivity, build a sense of “we’re all in this together,” and the logistics (such as tools and business processes) that streamline a telework lifestyle. But what about when your team is neither employees nor on-site? That gives any project manager extra challenges.

Lots of good tips.

 

Posted in project management | Tagged , | 1 Comment

Tips for Improving Your Geographically Distributed Agile Team

At the Better Software/Agile Development conference a couple of weeks ago, I gave a talk entitled At Least Five Tips for Improving Your Geographically Distributed Agile Team. (That link goes to the slideshare.)

If you look at Scott Ambler’s 2011 survey, you can see that his data matches my consulting experience. About half of all agile teams have at least one person not co-located. This is by management design.

We can say, “don’t do this,” but that’s not helpful to the distributed and dispersed teams. I would rather be helpful.

For example, in my talk, not the slideshare, I actually said, “Don’t do standups. Do handoffs.” If you are more than about 4 or 5 hours apart in timezones, standups make little sense. You are better off limiting WIP (with a kanban board) than using straight Scrum. Yes, use iterations if you like. You might like the focus of the timebox. But, consider using handoffs, not standups. Change your questions to statements—if that works for you. Change your deliverables to fit your needs.

One tip that created a ton of discussion was the one about keeping people together over time. Some managers are trying to be “efficient” about using team members, optimizing at the lowest possible level. They move people off and on teams, willy-nilly. (Groan.) I explained that agile is about finishing features, so their best bet was to optimize at the project level, or the project portfolio level. It didn’t matter if people weren’t fully utilized. People were best utilized when they asked, “How can I help move this feature across the board?” In a geographically distributed team, that is sometimes a difficult question to answer, especially if the testers are east of the developers.

I had stories, and we had audience participation, which is why the slides are sparse. I hope you enjoy the slideshare. If you have questions, please ask away in the comments. I will answer.

Posted in agile | Tagged , , | 3 Comments

Posted: What Is A Professional?

I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?

If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to join.

Posted in career development | Tagged , , , , , , , | Leave a comment

How Serving Is Your Leadership?

I once worked for a manager who thought everyone should bow down and kiss his feet. Okay, I’m not sure if he actually thought that, but that’s how it felt to me. He regularly canceled his one-on-ones with me. He interrupted me when I spoke at meetings. He tried to tell the people in my group what to do. (I put a stop to that, pretty darn quick.)

He undermined my self-confidence and everything I tried to accomplish in my organization.

When I realized what was going on, I gathered my managers. At the time, I was a Director of Many Things. I said, “Our VP is very busy. I think he has too many things on his plate. Here is what I would like to do. If he interrupts your work with a request, politely acknowledge him, and say, “Johanna will put that in our queue. She is managing our project portfolio.” If he interrupts you in a meeting, feel free to manage him the same way you manage me.” That got a laugh. “I am working with him on some customer issues, and I hope to resolve them soon.”

My managers and project managers kept on track with their work. We finished our deliverables, which was key to our success as an organization.

My relationship with my manager however, deteriorated even further. In three months, he canceled every single one-on-one. He was rude to me in every public meeting. I started looking for a new job.

I found a new job, and left my two week notice on his desk. He ran down the hall, swept into my office and slammed the door. He slammed my notice on my desk and yelled at me, “I don’t accept this! You can’t do this to me. You can’t leave. You’re the only director here accomplishing anything.”

I said, “Are you ready to have a one-on-one now?”

He said, “No. I’m busy. I’m too busy for a one-on-one.”

I said, “I’m leaving. We have nothing to discuss. You can put your head in the sand and try to not accept my resignation. Or, we can make my last two weeks here useful. What would you like?”

“You’re not done with me, Rothman!”

He stalked out of my office, and slammed the door on his way out. I got up and opened the door. I was never so happy to leave a job in my entire life.

Some managers don’t realize that they are not their title. Some managers don’t realize that the value they bring is the plus: the management, plus their relationship with their peers, the people they manage, the systems and environment they enable/create. This guy had created an environment of distrust.

That’s what this month’s management myth is all about: believing that I am More Valuable Than Other People.

If you are a manager, you do provide a valuable service: servant leadership. Make sure you do so.

Posted in management | Tagged , , , , , | 3 Comments

Pragmatic Manager Posted: Time for a Decision

I published another Pragmatic Manager this week, Time for a Decision. It’s about program management decisions, and collaborating across the organization.

Do you receive my Pragmatic Manager emails? If you think you are on my list, but are not receiving my emails, let me know. Some of you long-time subscribers are not receiving my emails because of your hosts. I am working on that. Some of you don’t subscribe yet. You can subscribe. I write something valuable at least once a month. I post the newsletter on my site when I get around to it, later.

I hope you enjoy this newsletter. If you don’t already subscribe, I hope you decide to sign up.

Posted in program management | Tagged , , , , , , , , | Leave a comment

Scaling Agile? Think Out, Not Up

I taught the Influential Agile Leader workshop with Gil Broza last week in Edinburgh. (That’s why I was quiet. I was traveling and teaching. No time for writing, blogging or tweeting.)

Possible Small World Network for Nine Agile TeamsOne of the participants asked me what I thought about scaling agile. Before I could explain about small-world networks, not hierarchies, he said, “I am sure the way you scale agile is out, not up.

Well, blow me over with a feather. He said it more simply than I did.

If you look at my picture of a technical program team, you can see that’s how it works.

Technical Program with Communities of Practice

Technical Program with Communities of Practice

The technical program team has feature teams alone, if they can be alone. Joe, Tim, and Henry all have stand-alone feature teams.

If they need to be “collected” because they work on related features, they collect themselves. Sally has collected feature teams.

The teams scale out, at the technical level, not up. The technical program team does not have to get to bigger. When I ran programs in the past, I emailed the program team meeting agenda (it was a problem solving meeting) to everyone, and say, “Here are the people I need to attend. Everyone else: let me know if you are attending.”

Now, there’s a limit to how big a program can get for the software program or the hardware program. At some point, the it’s so hard to coordinate the interdependencies, it’s not worth the bigness.

If the teams are delivering small features all the time, you don’t need as many people as you think you do. The smaller the batch size, the fewer the people required. Your momentum will be greater. If you don’t believe me, think about that for a minute or two.

When you think scaling agile, think out, not up. You use small world networks, and when you say, “think out, not up,” it’s a very nice catch-phrase.

Posted in program management | Tagged , , , , , | 1 Comment

Spike It! Article Posted

One of my clients was having trouble with estimating work they had never done before, so I wrote an article explaining spikes. That article is up on agileconnection: Need to Learn More about the Work You’re Doing? Spike It!

It was a little serendipity; I taught an estimation workshop right after I explained how to spike in email. That article almost wrote itself.

You can use a spike in any project, agile or not. Spikes are for learning.

I also explain what to do when managers say, “Use the code in the spike” and you think, “Oh no!” See for yourself.

Would-be authors: want to write an article for agileconnection.com? I’m interested.

 

Posted in project management | Tagged , , , , | Leave a comment

Design Your Agile Project, Part 5

This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the book, I will talk more specifically about change and what to do. This post is the highlights.)

Project management and program management are all about managing risks. How do we bring the management of change and management of risk together in an agile project or a program?

Let’s review the principles again:

  1. Separate the business decision for product release from the software being releaseable all the time. That means you want the software releaseable all the time, but you don’t have to release it. I talked about this in Design Your Agile Project, Part 1.
  2. Keep the feature size small for each team, so you can see your throughput.
  3. Use the engineering practices, so you don’t incur technical debt as you proceed.
  4. Understand your potential for release frequency.

Are you doing these things now? Are they part of how you work every day? If not, you need to change.  I’m going to address what the program needs to do to succeed.

Your Program Represents the Teams

In a sense, the program will represent the state of agile for the teams. Think of it as Conway’s Law exposed. (Conway says the system design reflects the communication structure of the designers.)

You might think you need to standardize your approach to agile or lean. You might think you need to be rigid about how you move to agile.

You would be wrong about the process. You would be more correct about the engineering practices.

You need to create the most resilience for the organization. Here’s what I mean.

CynefinIf you have autonomous, collaborative teams, you will have uncoupled, collaborative code. If you look at the Cynefin framework, you get that on the right side, without too much trouble. (I’m not saying this is easy. Just that it’s more possible.)

But, what if you have geographically distributed teams, or your teams are new to agile/lean, or you are still responding to requests from all of the program because the rest of the organization doesn’t quite understand agile? What happens then?

You are on the Complex or Chaotic side of the Cynefin framework. Maybe you don’t use the Good Practice that we already know for program management, right? Maybe you don’t use what we already know about for the projects, because they won’t scale for the program.

That’s why each team needs to review Part 2 and Part 3, especially if they are part of a program.

That’s why program management needs to be servant leadership at the core team level. See Which Program Team Are You Managing? Some program managers think they are managing technical teams. They might be. But, they might need to manage a core team in addition to a technical team.

What Does this Mean for a Program?

  1. If you are trying to change everything, you have many unknowns. You are not in the right side of the Cynefin framework. You are somewhere on the left side of the framework. Agile “out of the box” is not going to work.
  2. Teams need to practice being agile as a team, before they are part of a program. They can come together in service of a program. And, because each team designs its agile project, no manager can change people on a team, unless the team requests that change. No “I can move people like chess pieces” business. Managers serve the teams.
  3. Beware of hierarchies. They will slow your program. What is a hierarchy? Scrum of scrums. Hardening sprints, especially where other release teams integrate for the feature teams, can create hierarchies. Why? Because it’s too easy to say, “My part is done.”

If you are designing your agile project to be part of a program, you want to consider, “How will we make sure we deliver on a consistent basis to the rest of the program?”

This is not about maximizing throughput. This is about meeting deliverables, and making sure that the teams know about their interdependcies long enough before they have to meet them. Then, the teams can meet them.

In a program, you always have interdependencies. Always.

Design Each Team’s Project to Optimize at the Program Level

If you are part of a program, it’s not enough to design your project for your team. You have to consider the needs of the program, too.

Each team needs to ask itself, “How do we deliver what the rest of the program needs, as the program needs it?”

You might want to watch Phil Evans Ted talk, How Data Will Transform Business. In a hierarchy, we have too-high transaction costs. (In geographically distributed teams, we have too-high transaction costs, too, but that’s a different problem.) Note how he says “Small is Beautiful.” Hehehehe. Gotta love it.

Hierarchies are slow to respond. They impose barriers where you don’t need any. The problem with programs is that they are big. You want to decrease the problems of bigness where you can. One way to do that is to decrease the effects of hierarchy. How? By not involving hierarchy whenever you can. That means using small world networks to solve problems between and among teams. That way you solve problems where the problems exist.

If I ran all the programs in the world, what would I do?

  1. Have feature teams everywhere, not geographically dispersed project teams. I prefer collocated teams, but I realize in very large programs that is not always possible. (Sigh.)
  2. Have a core program team (cross-functional business team) that runs itself using kanban. If you need a cadence, use a one- or two-week iteration for the team’s problem-solving.
  3. For the technical program team, run itself using kanban. Same idea with problem-solving cadence.
  4. Have the project teams use their own approaches to agile and lean, recognizing that their job is to reduce batch size, get to releaseable all the time, and not incur any technical debt as they proceed. The more the project teams are autonomous in their approaches to agile, the more they will collaborate with each other. The more they will feel free to explore what they can do.
  5. Have the program architect (who represents the business value to the core team) look for examples of bad implementations of Conway’s Law all the time in the product. That will help create architectural business value. Yes, there is more that the architects do.
  6. Encourage Communities of Practice for the functional areas. Encourage cross-pollination between the communities. The “plain” developers need to know what the architects are thinking, as do the testers. The developers need to know what problems the testers are solving, and so on. Organizing and facilitating CoP might be a management job. It might be a program management job. It’s a servant leadership role. It’s definitely not a command-and-control role. (“It’s Tuesday at 4pm. It’s time to learn.” Ugh. No.) The word here is “encourage,” not mandate.
  7. As a program manager, you need to be aware when people need more training in understanding deliverables or what those deliverables are. Do they understand flow? Do they understand agile? Do they understand feedback? Do the teams need coaches? Do the teams need help in project management (yes, the teams are doing project management)? Do the teams need help in agile or lean? Do the teams need help in the interpersonal skills? Do the teams need help in the engineering practices that will help them deliver a clean feature every day or so into the code base?

Those are just your deliverables to the program. That’s nothing about what you deliver to your management team.

Keep these three words in your pocket for your teams: autonomy, collaboration, and exploration. The teams need to be autonomous. It’s their deliverables that you care about. Not the teams being in lock-step.

You care about the teams collaborating. How do you encourage that? With small features and product owners who have well-defined feature backlogs and roadmaps. The more often the teams check completed features in, the fewer collisions, and the more manageable the collisions are. You get momentum that way. I talked about momentum in Organizing an Agile Program, Part 3, Large Programs Demand Servant Leadership.

The exploration occurs when the teams (which include architects) spike or explore what the team(s) think the options are. Or, when teams talk among themselves to solve problems. Teams can first solve problems themselves. They do need a small world network and to know that you want them to solve their problems. They don’t need a hierarchy to solve problems. These people are smart. Isn’t that why you hired them?

Okay, all the previous posts in this series are:

Design Your Agile Project, Part 1

Design Your Agile Project, Part 2

Design Your Agile Project, Part 3

Design Your Agile Project, Part 4

Sorry this series took me so long. Travel and our new house interfered. Being a product owner is all-consuming.

Posted in agile | Tagged , , , , , , , , , | 2 Comments

Are You Running from Problems or Solving Them?

Back when I was a manager inside organizations, I had many days that looked like this:

  • Meetings at 9am, 10am, 11am.
  • Working meeting through lunch (noon-1pm)
  • Meetings at 1pm, 2pm, 3pm.

I finally got a chance to check my email at 4pm. That’s when I discovered the world had blown up earlier in the day! (This is before cell phones. Yes, there was a time before cell phones.)

I then ran around like a chicken with my head cut off until I left work at 5:30pm, because, yes, I had a family, and, yes, I had to leave at 5:30pm. I either made dinner or picked up children, depending on my agreement with Mark.

We did the family stuff until 8pm, and when the kids went to sleep, I went back to work.

No wonder I was exhausted. My decision-making sometimes suffered, too. No surprise there.

Luckily, I had some days that did not look like this. I could solve the problems I encountered. And, some of these meetings were problem-solving meetings.

However, I had jobs where my senior managers did not manage their project portfolios, and we had many crises du jour. My VP would try to catch me on the way to my next meeting, and attempt to get me to “commit” to when a patch would be available or when we would start, or finish a project.

I swear, one of my VP’s used to know when I went to the ladies’ room. He did yell at me through the door, just as in this management myth.

I finally put my foot down, and said I was no longer going to meetings that weren’t problem solving meetings. Have you read the chapter about meetings in Manage It! Your Guide to Modern, Pragmatic Project Management? I wrote it for project managers and for managers who run around like the proverbial chickens. I wrote Manage Your Project Portfolio for managers like me who had well-meaning senior managers who had trouble making decisions about which projects to do.

This management myth is something I see often in organizations. This one is the one where people are running around so often they don’t actually solve problems.

Many problems are a combination of several problems. You might have to separate the problems and attack them in sequence. But, you might have to see the whole first, because there might be delays. The overarching problem is this: if you don’t give yourself enough time as a problem solving team, you can’t tell what the problem is. If you can’t tell what the problem is, you can’t solve it.

Problem solving tends to go through the process of:

  • Problem definition: What do we think the problem is?
  • Problem discussion: Let’s get all the divergent ideas on the table. Brainstorm, whatever we need to do.
  • Select a solution: Converge on a solution, trying out the ideas, understanding the results of each potential solution
  • Determine an action plan, with dates and people’s names associated with each step

Your problem solving might vary from this a bit, but that’s the general idea.

If you never give yourself enough time to solve problems because you’re always running around, how can you solve problems? It’s a problem. (Like the recursion there?)

That’s this month’s management myth, I Can Concentrate on the Run. Maybe your myth is that you can concentrate in a 10-minute standup. Maybe your myth is that you can concentrate on your drive into work. You might be able to, for some problems. Complex management problems require more than one person to solve them. They require more than a few minutes thought.

How do you solve complex problems in your organization? Do the problems run around the organization for a while? Or, do you solve them?

Posted in management | Tagged , , , , | 1 Comment

Estimation and the Sunk Cost Fallacy

I’m not a fan of using schedule or cost estimate as a way to value the projects in your project portfolio. If you do, you are likely to miss the potentially transformative projects or programs.

In Manage Your Project Portfolio, I have an entire chapter devoted to ways to evaluate your project portfolio: business value points (not story points), waste, risk, to name just three. I wrote about cost of delay on this blog a while ago.

Last night, I heard Jutta Eckstein give a talk about Beyond Budgeting. That talk was the genesis for our Agile 2014 workshop, Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio.

Last night, I realized something while Jutta was speaking about estimation and sunk cost. One of the attendees asked about estimation. A paraphrase of that question is, “How can we start if we don’t know how long it will take?”

The projects that are worth doing have risk and are complex. What do you know about these projects? You can’t predict them. You cannot know how long they will take.

Remember the post Why Cost is the Wrong Question for Evaluating the Projects in Your Project Portfolio? If you don’t do the risky projects, if you only do the safe projects, you might maximize short-term gains. You lose the long-term market share, because you don’t do the risky projects.

Many managers find themselves in this position. The Operations committee or the PMO or “someone in charge” wants an estimate of the budget or when this project will be done. You provide a 3-point estimate: optimistic, realistic, and pessimistic estimate. Or, you provide an estimate with a percent confidence. (You have read Essays on Estimation.)

They don’t like that estimate, so they take the optimistic estimate, or they remove the percent confidence. That’s the first date you can’t prove you can’t make the project.

Never mind that the estimate is a guess. Never mind that you had caveats. Never mind that you had assumptions. Your estimate is now a commitment.

That date arrives. You are not done. You are in a variant of the 90% done schedule game. Why? Because you had an estimate. If you did not re-estimate, and update your estimate. Even if you did, your “in charge” people might not have wanted to hear your updated estimate.

Now, you might be in the sunk cost fallacy. The sunk cost fallacy says, “We have spent so much money on this, we may as well finish it. We can’t recover that cost. Our estimate says we only have xx much left to go.”

The difference between evaluating the project portfolio on value and estimates is that when you look at the business value, you ask this question first:

Should we do this project at all?

You always ask that question. It’s the zeroth question. Even if the project has been proceeding for a year. Because sunk cost doesn’t matter. You still have to support the system after you release it. Repeat that sentence: you still have to support the system after you release it.

If you evaluate the project portfolio based on estimates, you don’t ask the “Should we” question. You ask about the estimates. You don’t ask about follow-on after the release. You don’t go meta, which is the point of the question.

Sunk cost will catch you every time. Can you avoid the sunk cost fallacy? Of course. Do estimates cause the sunk cost fallacy? Of course not. They contribute to it.

In my experience, you are more likely to be caught by the sunk cost fallacy if you use estimation, because you are less likely to go meta on the value of your projects.

Is it okay to know if this project is bigger than a bread box? Of course. Should you use those estimates as a way to hold a project’s commitment to dates? No. Not if you want to work in an agile way and update the backlog as you work through iteration or flow the work. See Trust, Agile Program Management, & Being Effective for why you want to vary the backlog.

If you use estimates as a way to evaluate the projects in your project portfolio, beware of the sunk cost fallacy. You would be better off to ask, “How much value does this project have for us, compared to the other projects we have to do?”

Posted in portfolio management | Tagged , , , , , , | 8 Comments