When it comes to organizing large or geographically distributed agile teams many people will tell you that there are two strategies, taking what is called a component team approach or taking a feature team approach. Many people will tell you to take a feature team approach over a component team approach, but the fact is that both strategies has advantages and disadvantages and neither is right for all situations. Furthermore, those are the only two strategies as you will soon see, although to be fair they are the most common two.
This article explores the four basic strategies for organizing agile teams. We compare and contrast these four strategies in Table 1 below, in accordance to the “it depends” philosophy of the Disciplined Agile Delivery (DAD) framework. Our goal is to make it clear that you have choices when organizing agile teams, and that you should understand the trade-offs that you are making with each choice. You will also find that you want to combine strategies, and in fact most large agile programs that we’ve seen do in fact do this. The four strategies are:
- Component teams. With this approach each sub-team is responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams. Because component teams are effectively organized around your architecture you will need to invest sufficient time up front to identify that architecture.
- Feature teams. A feature team is responsible for implementing a functional requirement, such as a user story or use case, from end-to-end. This is often referred to as implementing a vertical slice of the solution. Sometimes a given feature team will focus on the requirements for a single line of business (LoB), such as brokerage or life insurance within a financial institution, enabling them to gain expertise in that LoB. Other times a feature team will take on requirements specific to a given application or system within your organization.
- Functional teams. Some large teams will be organized by development function – there is an architecture team, a development team, a testing team, a deployment team, and so on. Each team focuses on their specialized function and hands off their work to other functional teams.
- Internal open source teams. Sometimes a component or subsystem will be developed via an open source method, even though all of the work is private to your organization. Developers from other teams voluntarily work on the component to evolve it over time. When Scott was at IBM he saw this strategy work in practice for several important components reused within several IBM products. For some detailed thoughts on strategy, read Reuse Through Internal Open Source.
Table 1. Comparing the team organization approaches.
|Internal open source||
I recently wrote a detailed article summarizing my thoughts about Geographically Distributed Agile Teams. The article addresses a series of questions that I suspect you’ll find interesting:
- What does it mean to be geographically distributed?
- Are agile teams geographically distributed in practice?
- How does geographic distribution relate to other scaling factors?
- What are the potential benefits of geographic distribution?
- What are the risks associated with geographic distribution?
- How do we address those risks?
- How do we organize a geographically distributed agile team?
- How does geographic distribution affect tooling?
- Is geographic distribution a good idea?
- Where do we start?
- What other resources exist?
I hope you enjoy the article. Feedback is always welcome.
A few days ago we posted the Agility at Scale “landing page”. This article summarizes our thoughts and experiences scaling disciplined agile delivery from three points of view:
- Scaling Disciplined Agile Delivery (DAD) to address scaling factors such as team size, geographic distribution, organizational distribution, technical complexity, domain complexity, and regulatory compliance.
- Scaling agile and lean techniques and philosophies across your entire IT department.
- Scaling agile and lean to the entire enterprise.
As you can see at the page we intend, over the next few months, to post many more pages exploring the details. In the mean time, I suspect that you’ll find this page to be an interesting read. Please stay tuned.
We recently posted a new page titled Tool Support for DAD which you may find interesting.
At the end of July I spoke at the Agile 2014 conference in Orlando about what it means to be an agile enterprise. Part way through that presentation I spoke about the differences between producing potentially shippable software, one of the mantras of the Scrum community, and potentially consumable solutions as promoted by DAD. To do this I walked people through what I call the glass of water analogy. Here’s how it went:
I had a glass of drinking water. I took a sip from the glass to verify that the water was clean and the right temperature for drinking. The water was very refreshing and was something that I thought others would enjoy. It was my opinion that this glass of water was potentially shippable. I took another sip and then offered the water to the audience, there was over 200 people in the room, yet nobody was willing to drink from my glass. Shocking! I even singled someone out and tried to bully him into drinking my water (oops, I mean I aggressively marketed the wonderfulness of the water to him). Still, nobody wanted to drink the water. I took another sip and verified that it was in fact still refreshing. It was clear to me that my glass of water was potentially shippable. I could very easily have walked over to anyone in the room and they could easily have drunk from the glass. But everyone chose not to. It was potentially shippable from my point of view, but from the point of view of every single audience member it wasn’t consumable. In a venue where drinks are easily available, not a single person was willing to drink from my water glass (I assume due to a fear of catching my cooties). Had the venue been different, perhaps a desert with no other sources of drinkable liquids, someone might have been interested.
The point is that creating potentially shippable software isn’t sufficient. It needs to be something that people actually want to use, to consume. It must be a true solution that adds real value for them given their current situation. Cootie-laden water isn’t attractive when other drinks are readily available. Similarly, software that is difficult to use compared to other options, that isn’t well supported as other options, or that doesn’t enhance the way that people want to work isn’t going to be very attractive either.
Disciplined agilists focus on producing potentially consumable solutions. High-quality software is clearly part of this, but that software needs to be usable and something that people want to use. It needs to be supported with sufficient documentation. It needs to be supported with adequate hardware. It may even be part of an overall change to the business process and even organizational structure of the people using that software.
“Potentially shippable software” is a wonderful slogan, but we need to do a lot better than that.
I just posted a session idea for the Toronto Agile and Software 2014 conference. The title of the session is The Disciplined Agile Enterprise: Harmonizing Agile and Lean. The URL for the idea is http://agiletoronto.ideascale.com/a/dtd/The-Disciplined-Agile-Enterprise-Harmonizing-Agile-and-Lean/125226-30411 and I was hoping to get some feedback about it. I gave this presentation a few weeks ago at Agile 2014 to a packed room.
The conference organizers are taking an interesting approach this year by crowdsourcing the CFP process. I think it’s a really great experiment to run, so we’ll have to see how it goes.
Also, if your organization is interested, I’m happy to do this presentation as a webcast to you. Feel free to contact me directly.
Like it or not, functional dependencies occur between requirements. This can happen for many reasons, as we discussed in Managing Requirements Dependencies Between Teams, and there are several strategies for resolving such dependencies. In this blog posting we explore what happens when a functional dependency between two requirements exists AND one requirement is implemented by an agile/lean team and another by a traditional/waterfall team.
In our example requirement X depends on requirement Y. Neither requirement has been implemented yet (if requirement Y had already been implemented, and better yet deployed into production, the point would be moot). When we refer to the “agile team” this team may be following any one of the lifecycles supported by DAD (Basic/Agile, Advanced/Lean, Continuous Delivery, or Exploratory/Lean Startup).
Scenario 1: An Agile/Lean Team Depends on a Traditional Team
In this scenario X is being implemented by an agile team and Y is being implemented by a traditional team. From the point of view of the agile team, this is very risky for the following reasons:
- The traditional team is likely working on a longer time frame. Disciplined agile teams produce a potentially consumable solution (potentially shippable software in Scrum parlance) on a regular basis, at least every few weeks. A traditional team typically delivers a working solution over a much longer time frame, often measured in quarters. The implication is that because Y is being developed by a traditional team it may be many months until it is available, compared to several weeks if it was being developed by an agile team. This potentially adds schedule risk to the agile team.
- The traditional team may not make their deadline. According to the Standish Group’s Chaos Report, the average traditional team comes it at almost twice their original estimate (e.g. a project originally estimated at 6 months of work takes almost a year). Similarly, the December 2010 State of the IT Union survey found that traditional teams were much more likely than agile teams to miss their deadlines. By having a dependency on the deliverable of a traditional team, an agile team effectively increases their schedule risk.
- The traditional team may struggle to deliver something that is “agile friendly”. Agile teams routinely develop well written, high-quality software that is supported by a robust regression test suite and where needed concise supporting documentation. Although traditional teams can also choose to deliver similar artifacts very often their code isn’t as well supported by regression tests and their documentation may be overly detailed (and thereby more likely to be out of date and difficult to maintain). In other words, there is potential for quality risk being injected into the agile team.
- The traditional team may not deliver. There is always the risk that the traditional team doesn’t implement Y, traditional teams often need to reduce the scope of their deliveries in order to meet their commitments, or if they do implement Y it is done too late to be useful any more.
There are several strategies the agile team may decide to take:
- Negotiate a delivery date with the traditional team. Once the agile team has identified the dependency they should collaborate with the traditional team to determine the implementation schedule for Y. The agile team now has a release/schedule dependency on the traditional team which is a risk and should be treated as such. The agile team’s high-level release plan should show a dependency on the delivery of Y and their risk log (if they have one) should also capture this risk. The agile team should stay in contact with the traditional team throughout construction to monitor the progress of the development of Y. The agile team should also attempt to negotiate early delivery of Y so that they may integrate with it, and test appropriately, as soon as possible.
- Collaborate to develop Y. One way for the agile team to make it attractive for the traditional team to implement Y earlier than they normally would is to pitch in and help to do the work.
- Rework X to remove the dependency. One of the general strategies discussed in Managing Requirements Dependencies Between Teams was to rework X so that it no longer depended on Y. This may mean that you reduce the scope of X or it may mean that you deliver part of X now and wait to deliver the rest of X once Y is available.
- Reschedule the implementation of X. Another general strategy is to deprioritize X and implement it after Y is eventually deployed. This is a realistic option if Y is about to be implemented soon, say in the next few months, but often unrealistic otherwise.
- Implement Y. When the lead time is substantial, the agile team may choose to do the work themselves to implement the functionality. This can be viable when the agile team has the skills, experience, and resources to do the work. This strategy runs the risk of Y being implemented twice, once by each team, potentially inconsistently. To avoid this sort of waste the agile team will want to negotiate with the traditional team to take the work over from them.
Scenario 2: A Traditional Team Depends on an Agile/Lean Team
In this scenario X is being implemented by a traditional team and Y by an agile team. From the point of view of the traditional team, this might be seen as risky for the following reasons:
- They may not understand how a disciplined agile team actually works. Many traditional teams are still concerned about the way that they believe agile teams work. This is often because they perceive agile to be undisciplined or ad-hoc in nature, when the exact opposite is true. The implication is that the agile team will need to describe to the traditional team how they work, why they work that way, and describe the types of deliverables they will produce.
- They may want traditional deliverables from the agile team. Disciplined agile teams will produce high quality code, a regression test suite for that code, and concise supporting documentation. Traditional teams may believe that they also want detailed requirements and design specifications, not realizing that the tests produced by the agile team can be considered as executable specifications for the production code. The implication is that the two teams will need to negotiate what the exact deliverable(s) will be.
- They may struggle with any changes to the interface. Agile teams are used to working in an evolutionary manner where the requirements, design, and implementation change over time. Traditional teams, on the other hand, will often strive to define the requirements and design up front, baseline them, and then avoid or prevent change to them from that point onwards. These different mindsets towards change can cause anxiety within the traditional team, the implication being that the agile team may need to be a bit more strict than they usually would be when it comes to embracing change.
The fact is that scenario 2, a traditional team relying on a disciplined agile team, is very likely an order of magnitude less risky than the opposite (scenario 1). Either scenario will prove to be a learning experience for the two teams, particularly the one that relies on the other team. Going into the situation with an open mind and a respectful strategy will greatly increase the chance that you’ll work together effectively.