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.

The reason continuous integration is an issue on programs, is because the lack of CI can delay the technical program. That, in turn, can delay the overall program. That affects the project portfolio and often delays the start of other projects or programs. It reinforces the feelings of  “we have these sunk costs so we’ll keep sinking more money even though we can’t tell what we’ve done.”

I feel as if I’m saying when a butterfly flaps it’s wings over here, the world changes over there.

It does.

It’s easier to see in a smaller organization with one 3-team program. Of course, it’s easier to make continuous integration work on a 3-team program. It’s not so bad on a 4-8 team program. It can be horrendously difficult on a 37-team program, especially a program that’s new to agile. That’s why I don’t recommend people start their transition to agile on a large program.

This is one of the reasons program managers often make project portfolio decisions. They have the data the project portfolio managers do not. The program managers are face-to-face with the people who are saying, “One more month, and we’ll have a demo for you.” Even though those people have said this for the past four, five, six months. If those people had continuous integration, they would have had a demo already.

If you do not have continuous integration on your program, make sure you do have incremental funding. Otherwise, you have no way to do project portfolio management and call a stop to the program. Well, you do have a way, but it’s difficult. But if you have to go back for more money, that’s a great way to force the technical program to have to prove that they have something to show for their efforts —a demo, an interim deliverable, a something. Incremental funding means no one runs open loop.

Continuous integration is a form of risk management for all programs. I don’t see how you live without it for agile programs. And, if you want to take an agile approach to the project portfolio, you have to have at least regular deliverables for your projects and programs. Otherwise, the people on the projects feel as if you are yanking them around for no good reason.

The larger the project, as in programs, the more the technical practices matter. Not because the code demands it; code doesn’t demand anything. People need the structure that the technical practices provide.

But the people need the technical practices on their own terms. A program manager can’t impose technical practices such as continuous integration. A program manager can offer the practice and suggest ways it can work. A program manager can ask for the result, and wait to see how the teams want to implement the practice to achieve the result. That’s what it means to be self-organizing or self-managing teams.

Communities of practice can assist with these practices. It’s messy. It’s not top-down. It might take a few iterations to get right. That’s ok. Everyone will live with it, and then because the teams will have decided how it will work, they will proceed smoothly.

And, once you have the technical practices so that the program flows smoothly, the project portfolio work will flow smoothly, assuming you have people willing and able to make decisions. That’s fodder for another post.

The teams have determined their individual impediments to Continuous Integration. You, as the technical program manager, and the technical program team can take those impediments, with input from the teams can see the impediments to program-wide continuous integration. You have used a similar problem-solving approach, including the rule of three (which I learned from Jerry Weinberg) to generate some options for your problem solving. This is where it can get really expensive, because this is where you may need servers and build engineers. And, this is where you are going to start to see significant value, because this is where your program can start to come together every day, where you can get to releaseable product on a daily basis.

Once you do this, you may discover you have insufficient automated tests for your code. (You’ll uncover the next problem down the stack.) You may ask, “Is it still worth doing continuous integration?” I say, “Yes! Write more automated smoke tests as you write code.” But that’s just me. As with everything, your mileage will vary.

As a program manager, you can go back to your project pyramid and go back to the program charter, and go back to the tradeoffs you were supposed to discuss at the beginning of the program with the core program manager. Without continuous integration and the automated tests, you’ll be extending the time to release and possibly increasing the defects at release. With continuous integration, you may need to pay more to reduce the time to release and reducing the defects to get to release—or making it possible to release.

This is why I find the pyramid so helpful in having these discussions. You may need to show cumulative flow diagrams to explain your point. I especially like these cumulative flow diagrams that show features in integration. (You can do that if you use kanban.)

Now, let’s explore some paths I have seen programs use to move from staged integration to continuous integration.

Move From Staged Integration to Release Trains

If you are doing staged integration now, where you have a team of people integrating the software now, consider moving to a quarterly release train approach. Depending on how you implement release trains, you might be agile.

No matter how you implement release trains, every quarter, you integrate and have working product. That much is clear. So, at least four times a year, you have an entire product working in your program. The real question is how long does the product stay working? What is the cost of keeping the product working worth to you? (I don’t know, I’m asking.)

Move From Quarterly Release Trains to Monthly Release Trains

If you already have quarterly release trains, you know what it takes you to integrate the software every quarter. Are you stopping development every quarter to integrate for a few days to a week? If so, consider moving to a monthly train.

If it only costs you a few days, your cost of continuous integration is relatively low, and moving to monthly release trains is likely to be low. I would ask the teams if they can move to monthly release trains. This is where practicing to make the cost low and discovering the impediments to moving to real continuous integration is worth it.

This is still staged integration, but it’s reducing the staging time, and getting you ready for continuous integration. You might want to consider this if you are waiting for servers or build engineers, or other machines or people or training you have been promised, and “it’s coming.”

On the other hand, if you can barely get the product integrated for a few days every train, you have a high cost of integration. Moving to continuous integration inside trains is going to kill you. I have an even better plan. Move to continuous flow. This is the “just do it” philosophy.

Move to Kanban and Forget About Iterations

Some of you are thinking, “Ok, Johanna has lost it now. Staged integration was difficult, and release trains were difficult to integrate? Why move to kanban?” Because at some point, you will want to release the product. You do not want to wait for a quarter to end. If you start with continuous flow, and make your stories smaller, and each of your feature teams has to integrate as the feature team completes a feature, every single time they complete a feature, you will discover quickly what is going on.

If you visualize the entire technical program, and integrate every single sliver of a feature, you will be able to see the impediments and move to continuous integration more easily than if you struggle with more staged integration and more steps.

With iterations, you were like my college project, where you waited too long to integrate. You have too much work in progress across the entire program, and the costs of integration are killing your progress. Moving to kanban, continuous flow, will allow you integrate little bits (assuming your stories are small), and allow everyone to integrate a little bit at a time every day.

Grab a very large wall. You will need a large wall to visualize all the work in progress. Don’t bother with limits yet. First, visualize all the work in progress from every single team. Yes, for those of you with 47 teams, this is a huge pain in the tush. Well, if you don’t have continuous integration, that’s an even bigger pain in the tush, so get going with the stickies or the cards. Try a board that looks something like this:

Kanban for Continuous Integration

This kanban board has the backlog in the ready column, the development and the development-done columns before the system test on the local branch column. Then you can see the Waiting for Integration column. There’s a lot there. Finally, there’s the Done column.

When the teams realize how many local branches they are using, and how many features are waiting to be integrated, they might not even need the cumulative flow diagrams. But, I bet seeing the task boards even out and the cumulative flow look better will help them realize their hard work will pay off is worth it.

Use cumulative flow diagrams, make sure your feature teams are cross-functional, and I would ask each team to make sure they move a story across the board at least once every three days. Why three days? Because it’s less than once a week. I prefer once a day, and I realize that not every team can develop stories or slivers of features that small right away. But almost every team can learn to produce some sliver of a feature that they can deliver and show someone in about three days. If it takes a team about three days to deliver, they have the other two days to integrate and make sure nothing is broken. Now, in a week, they have delivered something of value, integrated it, and they can demo it. Ah, what a feeling. They have experienced what continuous integration is for themselves.

Multiply that by each and every team, and inside of no more than two weeks, each team has experienced continuous integration. Now, when the technical program team meets, they can intelligently discuss what they need for program-wide continuous integration. They will learn about collisions, where they need scripts, tests, tools.

What About the Waterfall Teams?

Some of you have waterfall teams in your programs, too. They need to use deliverable-based planning, rolling wave planning to get to the deliverables, and deliver something every quarter. This is called a staged delivery lifecycle. Or a design to schedule lifecycle. It’s an incremental lifecycle. Read more about these lifecycles in Manage It!.

Get Help if You Need It

Do you need a release or deployment engineer or team to help you with integration? I hope not. But as you start your program, if you are not accustomed to continuous integration, you might. As a program manager, I might have a release/deployment team to start to manage the risks, and see if I could help those people into feature teams and out of a release/deployment job.

Only you, the program manager, your product owner, and your program architect as the triad to assess the technical debt and business value of the backlog and technical risk can know the value of continuous integration on your program. Maybe you have well-behaved code, and the cost of continuous integration is not worth the aggravation.

But, if you are like the programs I see, the value of continuous integration is quite high. Consider the options for your program. The more teams you have, in general, the more value you will get from continuous integration. You will be able to see the state of the program more often, because the program will be demoable and releaseable more often.

My guidelines are these: small programs of up to three teams: let the teams decide. Programs of 4-8 teams: nudge the teams into continuous integration, using cumulative flow and show them the value of not having lots of work in progress. Programs of more than 8 teams: continuous integration is not negotiable. You either pay for it now, or you pay a lot more and have a disaster later.

If you see more options than I’ve outline here, please do comment.

Technical Program with Communities of Practice

A program is composed of several feature teams, which may well be working on several projects or different feature sets. I assume they are. The goal of a program supersedes the goal of any of the projects, and the business gains much more value from the program than from any of the projects by itself.

So, the question before us is this: How do you help the teams bring the entire product together on a periodic basis, regardless of their technical practices? If you look at the comments from yesterday’s post, you can see that continuous integration is a real problem for any number of reasons.

Remember, on an agile program, the agile program manager facilitates the work of the projects/feature teams, the agile program manager does not demand. The agile program manager does not lay down the law. The agile program manager does not say, “Here’s how it’s going to be, folks.” Even I, as much as I have wanted to in the past, have not done this. Oh, you have no idea how much I have wanted to say this.

On the other hand, the agile program manager can point out the consequences or risks of not taking certain actions. “If we don’t integrate as we go, we will never meet this demo date.” Or, the trade show date, or the desired release date, or some other date. Or, manage some other risk.

I’m quite happy to explain the risks to the feature teams. They are adults. They know how to get married, raise children, dress themselves, get to work clean, fed, and live adult lives. Ok, we’re talking about technical people, so sometimes we have outliers :-). But if the technical program manager explains the risks, or even says, “I have a funny feeling about this, and I can’t explain it, but I think this is risky, and I would like your help on managing the risk of not integrating as we proceed,” most people will respond and say, “Okay, let’s see how we can get closer to continuous integration.” Or, they will say, “Hey, this is really hard,” or “This is really expensive,” or “We know how to do it with lots of branches which is crazy,” or “We only know how to do it we break the build” or any number of other problem statements.

They’re not stupid. They may be intimidated by continuous integration, but they are not stupid. And, they may have doubts about the cost of servers or breaking the builds—doubts which are real.

Ask for the Problems or Impediments First

You can’t solve the problems you don’t know about. So, ask for the impediments first. You might be surprised. Maybe you need some servers. Maybe you need a release/deployment team.

Maybe the feature teams don’t really  understand the problem either. Here are some guidelines for the problems and impediments:

1. Ask for the result you want. If you want continuous integration, explain that’s what you want. I say something like this, “I want the system to be in a releaseable state every day. At a minimum, I would like that every week. I know that’s not where we are now, and that’s the result I would like. What would it take for us to get there?”
2. Assume the technical teams understand the technical problems better than you, the program manager do. If you ask for the problem and impediments, don’t poo-poo the problems. Treat the problems and impediments seriously. Assume the technical people are correct about the problems.
3. Use the rule of three for each potential solution. That is, for each problem, develop three potential reasonable solutions to that problem. That way, everyone understands the problem well enough. If you only have one potential solution, chances are quite good no one understands the problem well enough to solve it.
4. Involve the communities of practice in generating the solutions to these problems. That’s what they are there for. Use them.
5. Ask for project or feature team volunteers to try a solution before committing the program to it. Never impose a solution on the entire program. If no one is willing to volunteer to try a solution, it’s not reasonable. Go back to the drawing board.

Some of the teams will need different initial solutions. Some teams will need help making their stories smaller. Some teams will need help learning to swarm around their features, so they finish features earlier in the iteration. That sets each team up for success for continuous integration. Remember my story back when I was at university? We might have succeeded on that small project if we had worked together on the features, instead of working by ourselves.

But those impediments might be just the tip of the iceberg for your teams. Once you start generating some options, you can start to see what the costs are, and you can start comparing the value.

I will have some options in my next post.

That’s the night I realized that if you don’t start putting software together a little bit at a time from the beginning it gets harder the more you have to put it together. I’ve been a fan of continuous integration ever since.

I am sure there are projects where continuous integration might not be the answer, and I have not met them yet. And, I admit, there are times when the cost of continuous integration seems pretty high.

The agilist in me says, “Do it more often. That way you see what the impediments are, so you can see what is so difficult and you can make it easier every time you do it.” The pragmatist in me says, “Not everyone knows how to do it more often. Have pity on these people. Do you want to make them suffer?”

I don’t want to make people suffer. I do want people to realize that continuous integration is often well worth their time, even on a large program. So, here are some steps to help you move to more continuous integration, depending on where you are.

What Does Continuous Integration Mean to You?

The first question is this: What does CI mean to you? To me, it means that the software is Done. That is, it is compiled, tested, and not just demoable, but releaseable.

Now, it doesn’t have to mean that to you, and it certainly doesn’t have to mean that on a program, especially on a large program. But you should know what continuous integration means on your program. And, you should know who decides.

On a program, I recommend that a technical program manager suggest a strawman proposal of what done means, and see if the feature teams can live with it. Then, the feature teams should test that strawman for a limited time, such as an iteration, and see if that proposal makes sense to them. If you’re working in kanban, set a time period, such as one week or two, to make sure you see some features flow through the system and see if the proposal makes sense.

Now, everyone knows what done means for the program, so you know what continuous integration can mean.

Where Are You in Your Journey to Continuous Integration and Agile?

The first step is to know where you are.

The ideal case: Are you finishing features every iteration, as often as every day or so? You are likely doing continuous integration across your program.

Finishing Stories All the End of an Iteration

What I see in many teams practicing agile: Are you finishing features in a hockey stick, with most of the features finishing at the end of the iteration? This is tricky, and leads to staged integration, and makes for staged integration in a program if all the feature teams do this.

What I see in some teams quite new to agile: Do your features span iterations? If your features span iterations, you need to make your features smaller. The reason to make your features smaller has nothing to do with continuous integration yet. Making features smaller is all about seeing your progress and providing feedback to the product owner/customer and making sure you actually complete work inside the iteration. If you are using kanban, this is similar to seeing a board not change for weeks while the same features are still on the board, nothing moving. You are also likely doing staged integration.

If some of your feature teams do one thing, some of your feature teams do something else and you need a way to merge them all together. When I work with program teams, I find the teams doing some of each of these. And, the waterfall teams are doing something else entirely. On a program, we need a way to bring the entire product together on a periodic basis.

Stay tuned for part 2.

Core Program Team

If you are coordinating and collaborating across the entire organization, you are part of the core program team. If you take a look at the Core Program Team image on the left, you can see that there are plenty of potential participants on this program team. Aside from the program manager, there is the software program manager, the potential hardware program manager, the Program Product Owner, the Sales, Deployment, Legal, Marketing, Finance, HR, Investor Relations project managers. And those are only the people I could imagine. There might be other or different people in your organization.

Notice that the Software program manager is a delegate to the core program team. That means that the Software program manager must have a program team of his/her own. Yes. That is true for a sufficiently large program.

Below is what that technical Software program team looks like. Notice that the Program Product Owner and the Program Architect work as a triad with the Software Program Manager to make risk decisions. Does that mean that the Program Product Owner does not work with the Core Program Manager?

Software Program Team

It depends. It depends on who needs the Program Product owner. Maybe you need a product owner team, and the program product owner works with the core team and the technical product owner works with the software program owner. It depends on what your program needs.

Look at the Program Architect. Your project teams might need their own architects on their teams. Sally’s project–which might be a Scrum-of-Scrums, and if it gets bigger, might be its own program–likely needs its own architect. That architect better talk to the Program architect. And if there’s a Hardware architect, that architect better talk to the Program architect. So you might need a cross-functional architecture team that I don’t have a picture of, right now.

So, if you are a program manager, first, are you on the across-the-organization program team, the core team? If so, do you have everyone you need? Does that team have responsibility for deployment? (I don’t care who has responsibility for deployment, as long as someone does.)

If you are not on the core team, are you on the technical team that works across the technology? Does this team have responsibility for deployment? I’m being a little touchy about deployment because I have consulted to programs where no one was responsible for deployment and they only discovered it when I asked, “Who’s responsible for deployment?” I thought I was being stupid because I didn’t see it. No, no one had thought about it. Oops.

So why do you need all these program teams? The core team runs on a different rhythm than the technical program team does. Since the core team has senior managers or senior people on it, I recommend the core team use kanban to reduce the WIP (work in progress). The technical program teams can use iterations if that works for them. Maybe they also use kanban; it doesn’t matter. But they address risks at different levels.

The core program team is much more strategic. Often program managers at this level manage budgets and project portfolio issues. They are the ones to say, “Wait a minute. The software program can’t succeed. We should stop this project.” That’s a project portfolio issue.

The technical program team is more strategic than a given project, but is not as likely to manage budget or a project portfolio issue.

Program management, especially for many teams (think > 20 teams) is about making sure you have a product that delivers the business value you want from all that effort. So the technical program will have its own risks and rhythm, which is separate from the core team’s risks and rhythm.

If you are a program manager, make sure you know which team you are trying to manage (coordinate and collaborate), so you can be most effective.

After a few more questions, I realized the teams were architectural teams, say, a GUI team, a middleware team, and a database team. I suggested that the project manager rejigger the teams so that they were feature teams, not architectural teams.

Sometimes the project/program manager is new to agile only realizes what the teams need to do in theory, not in practice. Or the project/program manager wants the teams to do things his/her way. I’ve seen that a lot in my training and consulting. I don’t think that was the issue in the LinkedIn question this week.

Often, the teams don’t realize that they are doing something not quite agile. The organization has cheaped out on training, or the training was insufficient or too long ago, or something. Whatever it was, the training wasn’t enough. The teams don’t realize that what they are doing isn’t quite agile, so they are still working in architectural silos, instead of feature teams.

To return to the problem, how to get to a done feature when the teams are still architectural silos, my suggestion was rejigger the teams. For teams accustomed to architectural silos, this can be a shock. You might have to entice them. Here are some potential enticing ideas:

1. Ask them to try to rejigger themselves. “I’ve heard about this slice of cake thing. That’s where we implement a feature from the GUI through the middleware to the DB and back, as thin as it needs to be, but all the way through, end-to-end. Can we try that, make teams to try that?” (I thought Bill Wake used that metaphor. Do any of you readers have the link? I can’t find it.)
2. “You folks are the experts. What do we have to do to make this feature done?” Now, you as the project manager, hush. Take notes. Listen. The team is telling you the impediments to agile.
3. Challenge the team. “In agile, the idea is that we work features through the architecture. I’m just the project manager. You folks are the experts. Is there any way to do that with our product?” Again, you as the PM stop talking. The team is telling you how they can self-organize.

Note that none of the ideas are “You go here and you go there” team assignments. Why would I do that? Even I, Bigger-Hammer Rothman, know not to do that. People need to see that they have choices. Offer them three choices, as in the Rule of Three, and they will likely generate more choices that are even better than my suggestions.

Don’t expect that you know all the ways to be agile. And, don’t lay down the law and tell people, “We’re agile. Do it my way.” That’s not congruent with agile approaches, and doesn’t work.

Explain the result you want. Engage people in problem solving. Assume you don’t know what the solution is. That’s how you entice a program, team by team, person by person, to move to agile. It’s not foolproof, but nothing is.

When program team members,  and especially program team managers and project managers talk about “headquarters” and “remote” teams, they, and the teams, assign a hierarchical and positional meaning to the teams.

When you say “headquarters” and “remote”, the implication is that the people who count are the people at headquarters, and the people who don’t count are remote. The people whose opinion means something are the people at headquarters and the people whose opinion doesn’t mean anything are remote.

I am sure, that for the majority of program teams, this is not their intent. They don’t mean to exclude other people’s opinions or discount their ideas. But they do. Language matters.

I prefer to call the teams by either their feature team names or their locations: Floor 2, Section 27, Bangalore, Dublin, Cambridge, LA, whatever the geographic location is that defines that team. (I like to identify a dispersed team, with a feature.)

However you name your teams, consider avoiding “headquarters” and “remote”. Consider naming teams after their features. That may help your organization move to cross-functional teams in one location.

Whatever you do, avoid the us and them of “headquarters” and “remote”.

Program management is hard enough without throwing a new approach to projects into the mix. Since so many of you are emailing me about this, here is a draft of what I’ve written from the program management book. (This is unedited. It’s my rough draft. Please do review :-)

1. Start one team on an agile project to make a build system that builds the entire product in under one hour. If you already have a product, and your build and system test takes longer than one hour, invest the time to bring that build duration to under one hour. If you don’t already have a product, this is your opportunity to set up a build system for your product that allows you to build and system test in under one hour.
2. Start another team on an agile project to create an automated test system for unit and system tests. I don’t care if they buy, build, or “steal”, as in use an open-source system, but I do care that the testing system exists, and is automated. The automation goal is to automate the system test to provide a pass/fail within one hour.
3. Start a third agile team doing a Hudson Bay Start, or a “Hello World” application using the build system and the automated test system.

Organize these three teams into one program. Keep the iteration to no more than 2 weeks. (No, not 4 weeks. That’s too long. 2 weeks max. One week is even better.) See what happens with their need to discuss state with each other. See what happens with their backlogs. See what kinds of status they and you need. Make sure to do a retrospective at the end of the iteration.

Now, based on the retrospective output, you have a program backlog of what you need to do to create a successful agile program. Can you? Can the teams? If you can’t, don’t start an agile program. Start a staged delivery program. Start an iterative program. Start with an iterative approach to architecture and then move into feature-based development. (I have pictures for these lifecycles. Do you want to see them or are you tired of seeing lifecycles in my blog posts?)

I strongly recommend against your first agile attempt being a program. If you feel you cannot wait to start agile on a project and you must start with a program, start this way. You’ll have more success and you’ll be set up for success.

But when you develop or use products, more friction is bad. Brian Marick talks about  this when he speaks and writes about “ease” for development teams. If you’ve encountered a web page that made you do 25 different things before you were able to do what you wanted (some conferences want a whole lot of information, even if they’ve requested you send in a proposal), you’ve encountered friction as a user.

Up until this morning, I thought the technical debt and ease metaphors were sufficient to describe the friction that people encounter on projects. However, I also like Keith Ray’s post, “High technical debt = slum.” I feel like a second-class citizen–sometimes a third-class :-)–when I am part of a team or use a product with high friction.

When you hear these statements, you know you have friction:

• We can’t move to shorter iterations because of overhead
• It works on my machine
• Let the testers find the problems
• We can’t finish a feature inside of a week
• It’s just too hard to do <that thing>

And, if you don’t acknowledge technical debt, you can’t do a darn thing about the friction you encounter. It just grows and grows and grows.

If you work on a project, what do you do about the friction? Do you reduce it at all times? Sometimes, that’s the right approach. Sometimes, it’s not. If you are a project or program manager, do you look for friction? If not, start. Friction is often an unknown risk coming true.

Most of the time, friction makes our lives miserable. Unless, we’re in the gym. Then it might make our lives better in the long run. But for work, and for general living, think about reducing friction. Work and life will be much easier.