Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

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

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

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.)

Example 2: Using a Project Manager with Kanban, Silo’d Teams

This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.

This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.

The New York developers had a problem biting off more than they could chew. So nothing moved across their board. The Italy developers had a board where the work did move across the board. The teams took pictures of their boards every day and shared the work across a project-based wiki. That allowed the New York-based developers to see the work move across the Italy board. And, that encouraged the New Yorkers to call the Italians and ask some questions. That helped the New Yorkers to change the size of their work by working with the product owners.

Now, why did the New Yorkers have such trouble originally? Because the developers “knew better” than the product owners, so they changed the stories into architectural features when they had originally received them. (Now they don’t. They leave the stories as real stories.)

Release planning: Management in California plan with agile roadmaps. They have features planned specifically week-by-week for the next 6 weeks, and have more of a quarter-by-quarter approach after that.

Iteration planning: No iteration planning because they are using kanban.

Daily commitment: No daily commitment needed because they use kanban. They do have a checkin a few times a week with each other as a technical team to make sure they don’t create bottlenecks and that they respect the WIP (work in progress) limits.

At one point, both the New York and Italy developer teams created automated tests so that the testers could catch up and stay caught up with regression tests. They add a story like that every couple of weeks, and they are paying down their automated testing debt.

The Project manager keeps an eye on the WIP, work in progress. Project manager also shepherds the product owner into keeping the queue of incoming work full and properly ranked. The product owner is notorious for changing the incoming work queue all the time. Project manager makes sure the team does retrospectives and is a little unclear how to do them in such a distributed team. The project manager is not so sure their retrospectives are working, and has started an obstacle list, to make sure the team has transparency for their obstacles.

Measurements: cumulative flow, average time to release a feature into the product.

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

I’ve been working with geographically distributed and dispersed teams for the past couple of years. Some of them on quite large programs, some of them reasonably small. What they all have in common is that they all want to transition to agile.

Most of them start this way: someone takes a Scrum class, gets all excited. This is good. Then reality hits. Scrum is meant for collocated geographically cross-functional teams. Uh oh.

Almost all of these teams are separated by function: the developers are in one place, the testers are in another, the business analysts are in a third place, the project managers are in a fourth places, and if there are product owners (or what passes for product owners) they are often in a fifth location. It’s not uncommon for every single function of the team to be separate from every other member of the team. So, the teams don’t fit the Scrum criteria. Uh oh.

Since Scrum has so much brand recognition, these people think if they can’t do Scrum, they can’t do Agile. Nope, not so. What they need to do is start from the values and principles of the Agile Manifesto, and go from there. They create their own lifecycle, and their very own brand of Agile.

When I worked with one client, that client thought they could extend their iteration. Nope, if anything, that means you keep the iterations even shorter, because you need more frequent feedback when no one is in the same place. Well, there were words. And more words. But, if you start from the values, you see that short iterations are the way to go if you want to be agile. Otherwise, you get staged delivery, which is a lovely lifecycle, but not agile.

I’m blogging a series of examples. Please don’t ask me why the people ended up in these locations. I have no idea. All I know is that’s where the people are.

Example 1: Using a Project Manager With Iterations, Silo’d Teams

One IT organization has teams with developers in the Ukraine, testers in India, product managers and project managers in the UK, and enterprise architecture and corporate management in the eastern US.

This organization moved to two-week iterations. The developers were 3.5 hours ahead of the testers, which was not terrible. This organization had these problems:

1. The product managers had to learn to be product owners and write stories that were small enough to finish inside one iteration.
2. The enterprise architects had to stop dictating the architecture without features to hang off the architecture.
3. The developers and testers had to learn to implement by feature so the architects could help the team see the evolving architecture.

This organization had a ton of command-and-control to start. The project managers needed to facilitate the teams, not control them. The architects needed to help the teams see how to organize the product, not to tell the developers what to do. The testers needed to not be order-takers, as in taking orders from the developers.

You might ask why the organization wanted to move to agile. Senior management wanted agile because the releases got longer and longer and longer, and could not accommodate change. Agile was a complete cultural shift. The two-week iterations, along with an agile roadmap of features helped a lot.

The pilot project team consisted of the developers, testers, a product manager, and a project manager. The team rejected the enterprise architect as a member of the team because the architect refused to write code.

Release planning: The project manager and the product manager do an initial cut at release planning as a strawman and presented it to the team. “Can you do this? What do you think?”

Iteration planning: The team does iteration planning together, making sure every story is either small, medium, or large, where a large story can be done by the entire team in fewer than three days. The team makes sure they get every started story to done at the end of the iteration.

Daily commitment: The team does a daily checkin, not a standup. They timebox the checkin to 15 minutes. They ask these questions:

• What did you complete and with whom yesterday? (reinforces the idea that people work together)
• What are you working on and with whom today?
• What are your impediments?

The project manager who acts as a servant leader, not a command/controller manages the impediments.

The pilot project has two experienced agile people: the project manager and a developer. Both act as servant leaders.

Measurements: burnup charts, impediment charts

The pilot team has been together for six months now, and is successful. This is not Scrum. It’s not Kanban. It’s agile and it’s working. They are ready to start another project team, working by attraction.

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

I’m so pleased to announce that Shane Hastie and I are leading a workshop on Working Effectively In Geographically Distributed Agile Project Teams, April 17-18, 2012 in Pleasanton, CA. Yes, that is Elisabeth Hendrickson’s Agilistry Studio.

Shane and I first delivered this workshop last year in Australia, when I was there for Software Education‘s SDC. We had a great time, and so did many of the participants. We have since evolved the workshop, to address the needs of the participants who did not have a great time, and to make sure we covered the topics we need to cover.

This is an experiential workshop. You will learn by doing and debriefing. If you’ve taken my one-day versions over the past year, you’ve had a taste of what we do in the two-day. You will learn even more from both of us. Remember, we developed this as a geographically distributed pair.

One of the benefits of signing up for the workshop is the informal consulting you can obtain, not just from us, but from the other people there. You’ll hear what other people are doing, what’s working and what’s not working. If you want, you can hear from Shane and me about what’s working and not working at our clients as they transition to agile and explore more agile approaches.

Do check out the syllabus. And, if you’re ready to sign up, please register.

I have posted last week’s Pragmatic Manager, Are You Being Guilted Into Doing More?.

At Agile 2011, I had a great video conversation with Shane Hastie about agile project portfolio management. The chair is big, I’m not so short. The chair is big, I’m not so short. How many times do you think I have to say that to make it true? The chair is big, I’m not so short. That ought to do it.

My new Gantthead column is up, Who’s Playing Agile Schedule Games?

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

I posted my most recent Pragmatic Manager: Are Your “Shoulds” Driving Your Decisions?

Yes, in case you couldn’t tell, I am doing a series on project portfolio management, so that you do take a look at my Peer Project Portfolio Coaching. Several people took advantage of the early bird pricing. We’re in the not-quite-early-bird pricing now. And, if you sign up with a buddy, you can still get early bird pricing for the two of you. It’s a steal.

If you are struggling with too much to do, sign up. If you are overwhelmed with your workload, sign up. If you are trying to do it all, sign up. You cannot succeed. You are making yourself crazy.

We will use agile and lean approaches and help you overcome the guilt, the sunk cost syndrome, and the “you’re not playing with the team” nonsense that other people will pull on you. You’ll get the support you need from your peers.

Join us. You won’t be sorry.

I have an article posted at Techwell, Management Myth #1: The Myth of 100% Utilization. This myth has always been a problem. It’s even more of a problem now as more organizations transition to agile.

People need time to think. They need time to adapt to their current circumstances. They need time to create their teams. Some of the time, people are thinking about this iteration’s stories. Some of the time, people are thinking about the product roadmap. Some of the time, people are thinking about the next iteration’s stories.

Thinking is work. Not all work occurs when fingers touch a keyboard. Not all work occurs when mouths are open and moving. Even I have learned to sometimes think with my mouth shut, although that is an infrequent occurrence.

The more “utilized” a person is, the less a person can think. And that means a person is not going to innovate. A person cannot provide the best they can for their organization, which is not why you hired that person.

If you are one of those people who is working with a manager who still thinks in terms of 100% utilization, consider my peer project portfolio coaching. If you are a manager, who is considering another way, consider Manage Your Project Portfolio and consider my peer project portfolio coaching with your leadership team.

In any case, please read the column, and leave comments on the column over at TechWell.

If you missed my most recent Pragmatic Manager newsletter, Focus on One Thing at a Time, it’s posted. In it, I ranted about the delays of multitasking and introduced a new service: Peer Project Portfolio Coaching.

I keep seeing people trying to make the transition to agile, still multitasking and not able to say No to all those projects–at all levels of the organization. Partly, it’s because they don’t have the tools, which is why we’re talking about the project portfolio. Partly, it’s because they don’t have the language, which is why we’re talking about how to say No. And, partly, because they have rules about should they even say No. Or, they have guilt about saying No. Or, any number of other reasons.

If you are one of these people who knows you can’t quite do it all, and are not sure how to organize or say No, sign up now and take advantage of the early bird pricing.

If you are a leadership team who has trouble with the sunk-cost problem (“we already spent so much money, surely we’ll see some return soon”), talk to me, and we’ll decide if group coaching is right or if you need your own private coaching.

Please join us.

I have finally posted my most recent email newsletter, Three Myths and Three Tips. It took a while because I was converting my site to WordPress and I did not want to maintain the site in two places.

I have finally transitioned fully to WordPress. What a relief. All my old articles are finally posted. I have tagged back to somewhere in 2006. I’ll keep tagging as I get around to it.

What do you think? I’d love your feedback.

I’m at the end of redesigning my website. I’m posting and tagging my articles now. These are the articles from several years ago I didn’t get around to posting because it was too much of a pain to do in Dreamweaver. Yes, I’ve transitioned to WordPress site. I’m planning to unveil it next week.

I have a question for you, my loyal readers. Aside from typical tags, such as “project management,” I can also tag my articles with the outlet in which they were published. Is that helpful to you? Please comment and advise me. Thank you.

The nice folks at getabstract like Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Some of the takeaways they highlight are:

• Project portfolio management helps you finish your software projects on schedule.
• You must understand your mission to make choices about prioritizing software projects.
• Managers must select which projects to undertake and which to avoid.
• Create a visual overview of all current and upcoming projects to depict who will work on them and when.
• Some managers dislike project portfolio management because it prevents them from shifting developers between assignments. This is, in fact, a primary benefit.
• Project portfolio management aligns your team’s work objectives with your organization’s strategic objectives.
• Project portfolio management’s central truth: You can do all your software projects – but you can’t do them all at once.

I get to display this nice badge on the book’s page on my site, and the Prags have it on the book’s page already.

You don’t have to read just the abstract. You can read the entire book. Buy it from the Prags in both the ebook (many forms) and/or print as a holiday present to yourself so you can start the new year right.

Or, if you are still a print-only reader, and want to buy it from Amazon, that works too.

But, if you are still trying to plug people into projects part-time, or if you are still trying to figure out how to get it “all” done, stop. You can’t. You need to engage your peers into having those difficult discussions about what you can commit to for now, what you can’t commit to for now, and what projects you will never commit to.

Welcome to the project portfolio!

I’ve been working with several management teams who want me to train them or their project managers to take over the agile training. It’s not unreasonable from their perspective—it’s how they’ve transitioned to all the other process improvement approaches over the years.

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?

I hope that  this 3-part series on how to move to continuous integration and how to evaluate if it’s worth moving to continuous integration on your program convinced you moving to continuous integration was worth it for programs.

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.

To continue our story from part 1 and part 2…

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.

Let’s set the context (which I did not do in my most recent post–sorry).

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.

I like continuous integration. A lot. I started being an aficionado of continuous integration back in my senior year of university . It was my very first (and last) team project in my college career. There were three of us. The project manager waited until the night before the project was due to get us all together (argh #1). I had completed much of my code several weeks before (argh #2: who can remember what they’d written several weeks ago?). We wrote code madly for hours, and then tried to make it work, starting about 9pm. It didn’t work. We stayed up all night (argh #3). I finally went back to my dorm about 7am so I could shower and eat breakfast for my 8am class. The other two guys blamed me for leaving, saying I should stay with them. I explained nothing had worked yet, nothing was going to work if I went to my other classes (just about the only smart thing I’d said all night).

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.

We are looking for authors for the Agile Journal. Here is the 2012 editorial calendar as a guideline for you:

January: Requirements; Agile Game Development

February: Low Tech Test Tools

March: Mobile, Redefining Quality

April: Acceptance Test Driven Development

May: What is Quality?

June: Agile Management

July: Cloud Development

August: Business Value

September: Agile Testing

October: Kanban

November: Salary Survey; Embedded Systems

When I say editorial calendar as a guideline, I mean just that. If you have an article that is jumping out of you, and it doesn’t fit the guideline for a given month, please send the article to me.  Do not worry!

Here’s how I work with authors: I read your article. I try not to make any copyedits. I do make some edits if I think they affect your meaning. I ask you questions in comments to  make sure I understand your meaning. My job is to make sure you make sense and that you look smart and consistent to your readers. I want everyone to think, “Wow, this author has something really interesting to say.”

Sometimes, authors have peanut butter thinking. That is, they get their thoughts all stuck together. (I do this, which is why I recognize it.) I can help you unstick your thoughts. Sometimes, authors have their best sentence at the end. (I do this.) I can suggest it go at the beginning. Sometimes, authors need an example. (I do this.) I suggest you need an example. You don’t have to take my suggestions. I try to have a light touch.

My goal, which I think is your goal, is to help you get published.

PR people:  Once you send in the article, your work is done. I work with the author, not with you. And no, I don’t talk with you on the phone. I edit, which is writing, not talking. I know, that’s so different from what you do. Thank you for understanding.

So, what do you say? Want to write an article for the Agile Journal? I’ll get some of my previous authors to say how nice it was working with me, even when I pushed them hard to make their articles different from what they originally thought. The results were great.

Matthias Bohlen interviewed me as part of the preparation for the OOP conference. We spoke on a wide range of topics, not just my talk which is “Six Behaviors to Consider When Hiring for an Agile Team.” We spoke briefly about program management, which is why I’m leading my influence tutorial.

Hear the entire podcast here. You can even comment there, although I don’t know if I will be notified of your comments.

I didn’t know that Matthias was a lean coach when I started speaking with him. Listen for the bonding moment when we learned we had both seen lean teams understand their WIP limits. I can’t wait to meet Matthias in person. I’m really looking forward to OOP.