Ok, so these are writers or reporters, and they may not know. Choosing to be a manager without being a leader is like choosing to drive across the country without a map. Choosing to be a leader without having management skills is like choosing to be a fish without gills. You have to know where you’re going, and you have to know how to breathe in your environment.

Managers set the strategy and the vision, so everyone knows what is going on and can work on the most important work. Managers create the environment so that the people all over the organization can succeed, including the managers. They are not the only people who do this, but they are the leaders who must do this. If managers do these things in a command-and-control way, they might succeed. If they choose servant leadership, they are more likely to be successful.

Managers must be leaders. We cannot choose between management and leadership. We must have both.

I use a Mac, and don’t see these things, so I asked my web master for help. He suggested we ask my ISP. A day or so later, Google decided I was a malware site. Oh boy, that was a huge problem.

My ISP finally located the problem several days later, and discovered they had a backup from several weeks ago that did not have the problem. My backups only run for a couple of weeks at a time, not close to a month. Guess I will have to revisit that strategy.

Yesterday after my site and blogs were restored, and Google reviewed my site, the malware notifications were gone. Happy days!

You can safely surf to my site and my blogs again. (You actually could before. But who am I to argue with Google?)

The one nice thing about this is, I know who my friends are. My friends emailed me. You posted on Twitter to make sure I knew. This was a different kind of collaboration, but a collaboration nonetheless. Thank you. And now, all is well.

So, my nice example of a collocated team in Thoughts on Infrastructure, Technical Debt, and Automated Test Framework, rarely occurs in a program, unless you have cross-functional teams collocated in a program. If they do, great. You know what to do.

But let’s assume you don’t have them. Let’s assume you have what I see in my consulting practice: an architecture group in one location, or an architect in one location and architects around the world; developers and “their” testers in multiple time zones; product owners separated from their developers and testers. The program is called agile because the program is working in iterations. And, because it’s a program, the software pre-existed the existence of the agile transition in the organization, so you have legacy technical debt up the wazoo (the technical term). What do you do?

Let’s walk through an example, and see how it might work. Here’s a story which is a composite from several clients; no clients were harmed in the telling of this story.

Let’s also assume you are working on release 5.0 of a custom email client. Release 4 was the previous release. Release 4 had trouble. It was late by 6 months and quite buggy. Someone sold agile as the way to make software bug-free and on-time.

You do not have automated tests for much of the code, unit tests or system tests. You have a list of defects that make Jack the Ripper’s list of killings look like child’s play. But agile is your silver bullet.

The program manager is based in London. The testers for the entire program are in Bangalore because management had previously fired all the testers and outsourced the testers. That was back in release 2. They have since hired all the Bangalore testers as employees of the Bangalore subsidiary. The program architect is based in San Francisco, and there is an architect team that is dispersed into 4 other teams: Denver, LA, Munich, and Paris. The developers are clustered in “Development Centers of Excellence:” Denver, LA, Cambridge, Paris, London, Munich, and Milan. That’s 8 development teams.

Oh, and if you think I’m kidding with this scenario, I’m not. This is what most of my clients with geographically distributed teams and programs face on a daily basis. They deserve your sympathy and empathy. Do not tell them, “Don’t go agile.” That’s nuts. They have a right to go agile. You can tell them, “Don’t go Scrum.” That’s reasonable. Scrum is for a cross-functional co-located team. Agile is for everyone. Scrum is for a specific subset.

What do you do?

1. Assign specific testers to specific development teams. No calling people resources; that allows managers to treat people like resources and plug-and-play them. You need to get rock-solid teams together. Once you have teams together, you can name them.
2. Name teams so the teams reflect the feature groups they work on. What does an email product do? It gets email, it sorts email, it deletes, it forwards, it creates new mailboxes, and so on. The eight feature teams had to be named for the feature areas: Platform for the general features, Sort, Delete, Forward. There were two teams who worked on Platform. They were called Platform 1 and Platform 2. At one point, someone suggested they call themselves Thing1 and Thing2 from the Dr. Seuss book.
3. Make sure you have enough product owners so they can develop roadmaps for each feature area. With a roadmap, the teams know where they are going. Even more importantly, the architects know where the program is going.
4. Architects think and provide just enough guidance ahead. In a small project, the architecture can probably evolve with the project. In a larger program, that risk is too large. You have too many people developing in parallel for the architecture to evolve on its own with no guidance. But I do not mean there should a Master Architect Who Knows All Handing Down the Architecture From On High. NO NO NO.
   I want the architect who is a working member of the development team, who also is part of an architecture community of practice team, who curates the architecture, who guides the business value of the architecture. I do not want Big Architecture Up Front. But Thinking Up Front? Sure, that’s a great idea. Stuck on only one idea? Bad. Willing to spike an idea? Great. Willing to play in a sandbox and debate several ideas? Great. I wrote about this before, in How Agile Architects Lead.
5. Decide what done means for every feature. You must have acceptance criteria for each feature. What does that mean? You need a product owner present for each team. You still need the conversations with each team to discuss what done means. Especially with a geographically distributed team, you need the conversation when you create the backlog at the beginning of the iteration.
6. The US  development teams had trouble planning their iterations with their testers, because of the time zone differences with the testers. So, they asked their product owners if the product owner would write more than just a few phrases on the cards, because that would help them get through the iteration planning meeting faster. Someone was going to get up early or stay up late, and either way, someone was going to suffer. It made more sense to have a little bit more preparation than less sleep.
7. Decide to do continuous integration and stick with it. Especially if you know you have technical debt and you don’t want to create more, you have to do continuous integration now. That prevents more technical debt.
8. I have recommended to some teams that they have one-week iterations so that they stop the estimation nonsense and make their stories small. The point of estimation is so that you have an idea of what you can do as a team and not commit to more than that. The idea is that if you know what it takes to make your stories small, you will.
   Instead, we have all these crazy rituals around estimation and management tracking velocity of all things. (Yes, I’ve been drafting this post for a long time, and I wrote Why Does Management Care About Velocity? last week.) You know, velocity is a little like weight. Only you and your doctor need to know your weight. If you are healthy, you are fine. If you are not, you need to change something.If your team velocity is not healthy, you, as a team, need to change it. But, your management has no business butting its head in. Only you can change it.
9. When you limit the iteration length, you tend to have the team swarm around a story. This is a tendency, not a given. If I really was the Empress of the Universe, I would decree this, but I’m not, so I won’t. If you want to decrease technical debt, or even eliminate it on your program, explain that your team will only work on one story at a time until that story is done. That story will be polished and gleaming. Fast. You will not have to worry about what kinds of testing will be done. All if it will be done.
10. Explicitly discuss what you will automate for testing and when. In a program, I assume we will have automated system tests first. I assume we will do exploratory tests later. That’s because if you don’t start building something for test automation when you start the program and refactor as you proceed, you can never catch up. I assume every time we fix a defect, we will have an automated test for it. I also assume we build these assumptions into how we develop :-)

So far, this is all about preventing more technical debt, not what happens when you trip over technical debt as you enter code or tests you never looked at before.

If you expected to walk into a closet, take out a shirt, and close the closet door, that’s one thing. But now, you stepped into something out of one of those death-by-hoarding shows on TV, you have an obligation to do something. You can document the problem as you encounter it; you can let the product owner know; file a defect report; write a test so you can contain the debt; and maybe you have more options. Whatever you do, make sure you have done something. Do not open the door, see the mess inside and close the door on the mess. It’s tempting. Oh my, it is tempting.

See, on programs because of the size, everything is magnified. With more people and more teams, everything is harder. Things happen faster. If you have co-located cross-functional teams, no problem. But if you don’t have co-located cross-functional teams, you have to work with what you have. And, if you already have a big legacy product, you want to address technical debt in small chunks, refactoring in small bits, integrating as you proceed.

My philosophy is this: the bigger the program, the more you need to become accustomed to working in small chunks, integrating as you go. Fully implement a small story, integrate it on the mainline. Everyone on the program does that. If you need help from an integration team, so be it.

But, if everyone only implements small stories, and everyone takes care of their own technical debt as they discover it, you don’t need an army of integration people. You only need an army of integration people when you have technical debt around integration and release. Fix that, and everyone can become responsible for their own integration.

And, if you can’t release, that’s where the architects should start. If you can’t do continuous integration, that’s where the architects should start. Because that’s what’s preventing you from making progress on the product. Work backwards from release, and then the architects can work on the rest of the product. Until you can release and build reliably, the rest of the product doesn’t matter.

Management Myth #3: We Must Treat Everyone the Same Way and Management Myth #4: I Don’t Need One-on-Ones are up. Please leave comments over at Techwell.

“Double Your Velocity” is an agile schedule game. It’s easy to manage–you double the points you assign to your stories. Whee! You’ve just doubled your velocity. No muss, no fuss.

But let’s understand what management really wants.

What your management wants is for the team to do more in a given time period. That’s why they want more in a sprint, or for the team to become a hyper-performing team. So, let’s look at the project conditions for a hyper-performing team:

1. No multitasking. Management must manage the project portfolio. You can ask your managers to do this. Really, you can.
2. The customer or product owner must rank the features.
3. The project team must already know how to work together. That means you can’t add or subtract people. The team must have already formed, stormed, and have normed. They have to know how to work together.
4. They have the physical infrastructure: build servers, phone lines, computers, whatever that they need, and they know how to use them. Do not underestimate this part. If you don’t have this part, you can’t do continuous integration, for example.
5. The team needs enough people who play enough cross-functional roles: developer, tester, and whatever else the team needs, so that the team can finish its work. I am being vague on purpose. I don’t know what your team needs. It might need a catalyst. It might need a UX person. It might need an almighty DBA. It might need a project manager to coordinate work from other teams. I have no clue, because it’s your team. All I know is that your team needs enough cross-functional roles to get all of its work done so that the stories don’t come back to bite you on the tush.

Those are just the project conditions. Take a look at the project pyramid I have in the estimation series I wrote last year. The project conditions are part of the work environment. If you have a distributed team, good luck moving to a hyper-performing team. Can you do it? Of course. Will it take longer? Yes. Why? Because you have to experiment with your project conditions. Management will have to stay out of the way while you run your experiments.

Now, I am not known for my tact and diplomacy. Here’s what I have said to management: “Velocity is personal to a team, just like weight is for a person. What you need to care about is our feature throughput. You need to care about our demos, not our points. How we manage our velocity is like making sausage. You don’t want to know that. You want to know the results. We want to show you our demos, not our act of creation, okay?”

I’ve had success with that, especially with overweight managers, and those who knew about sausage-making. I’ve had success with that as long as teams had iterations no longer than two weeks.

Why? Because as a team learns and experiments, it is more likely to create smaller stories. It is more likely to swarm around stories. It is more likely to automate more of its testing. It is more likely to pay down technical debt as it proceeds. It is not guaranteed to do any of this. In my experience, it is more likely to do so, because the team members learn that postponing automation hurts. And postponing technical debt hurts. And big stories cost more than little stories. And waiting to integrate costs more than integrating right away. And, informal pairing among anyone is better than no pairing, and and and… Every team learns their own lessons because every team is different.

But just because many of the lessons the teams I’ve worked with are applicable to many other teams does not make them “best practices.” Phht. They are practices that work in a context. They especially work in a business context. And, once management starts focusing on velocity, the business context has changed for a team.

Managers, look at the demo. If you want more out of a team, work on the project portfolio. Decide what is first. If you can’t decide, run the project portfolio as a kanban. I explain how in Manage Your Project Portfolio. Velocity is too-low-level a measure.

Teams, show your managers a product backlog burnup or burndown chart. I also explain that in Manage Your Project Portfolio. And, demo! I suggest a number of other measurements, such as cumulative flow diagrams.

I like velocity for telling us if the project is not going to end. I have those charts in Manage Your Project Portfolio.

Managers, you can ask a team to do more. But you don’t need to see an internal measure like velocity. That’s personal to a team and doesn’t help you make any judgements about what the team is doing.

Encourage the team to experiment. Use cumulative flow, product backlog burnup/burndown, feature throughput, and demos. That’s the way to see if a team is producing.

Building Rapport

Distributed? Yes. Alone? No.

If you think you subscribe, but you are not receiving your own personal copy, email me. We’ll discern what is going on with your subscription and fix it. If you don’t already subscribe, and you would like your own subscription, either sign up using the handy-dandy form on the right, or email me, and I can add you myself.

Do you have something for us to test yet?

We have completed the card

Hi again. I didn’t hear back from you yesterday on this. We’ve already lost a day of status. Please find some time today to send us your status.

Hurry. I need to test!

Hi guys and gals, in the standup you mentioned that you had questions about the requirements. Could you please provide us with details regarding the stories?

Need you to pull some overtime

I don’t know in which order the emails were, but it doesn’t matter. The building part of the project simulation was only 15 minutes.

Jack Vinson brought my attention to an HBR article about when to bring geographically distributed teams together: at the very beginning or after they had been working together for a while. As with all interesting questions, the answer is, “It depends.”

If this team had enjoyed a meeting before they had started working together, they could have chartered the project and worked out roles and responsibilities. They could have worked out how they would have done their standups. They could have advocated for travel money when they were all in one place. They could have measured the value stream when they were all in one place and estimated it when they were not all in one place to explain why they needed more travel. Maybe.

One of themes of our workshop was “measure the value stream.” If you are in doubt about whether or not something makes sense with the way you are organized, measure the value stream. Look for where information flows, and where the delays are, and how long the delays are. Now you have a shot of understanding who adds value to the work products and who does not. Read Wage Cost and Labor Cost when you have a chance.

We had a great time. Too bad you were not there.

Oh, and if you are considering conducting a workshop in the Bay Area, use Elisabeth’s Agilistry Studio. It was a great facility and she was easy to work with.

So using leanpub and publishing early and often pushes me way out of my comfort zone. Which is why you haven’t heard anything from me about my book under development up until now. Yesterday, I announced the beta of my newest book Manage Your Job Search: Reduce Your Overwhelm, Focus Your Search, and Get Your Next Job!

I couldn’t just push the button and publish. Oh no, no, no. I had to make it a beta, because it’s not done. It’s not even close. Oh, more than the outline of the book is there. The networking chapter is great. How to use personal kanban is great. Much of how you reflect on the past week is great. The tips and traps are great. And, I know they are not complete, which is making me nuts.

That’s not all that’s making me nuts. The copyediting is not done. The layout is not done. The what to do now is not done. I need feedback from readers to know what to do next, which is why I needed to publish, and oh boy, it’s not perfect. That’s why I don’t have a real cover, because I don’t know that I have the correct title. How do I balance my perfection rules against the need for feedback?

Beta! Especially if I explain that it’s a beta book. That’s what I did in my announcement yesterday. I was able to balance my need for perfection against my need for feedback.

I bet my fellow leanpub authors are delighted to not have to hear the teenage drama queen angst on the leanpub list anymore. I will get the feedback I need. I will be able to perfect the book from people looking for a job. It’s a win-win.

If you are looking for a job, please do check out my new book, Manage Your Job Search: Reduce Your Overwhelm, Focus Your Search, and Get Your Next Job! It’s not perfect; it’s a beta book. I would love your feedback.

Oh, and I am just about to send the logistics email for our workshop next week on geographically distributed agile teams next week in Pleasanton, CA. I am sure we will discuss issues such as these. Have questions? Still want to participate? Email me.