Welcome to the Disciplined Agile Delivery (DAD) community website! You can follow us by signing up on the sidebar. If you support DAD and would like to contribute to this blog please let us know. Of course you can leave a comment about any post without being a contributor.

DAD Webcast on Oct 22: Disciplined Agile Delivery, the Foundation for Scaling Agile

October 21, 2014 4 comments

I appreciate how this is very last minute, but I’ll be giving a few webcast on Oct 22, 2014 at 8pm ET (same time zone as New York City) overviewing Disciplined Agile Delivery (DAD).  This is part of Software Guru’s virtual conference that day.  The URL to sign up is http://sg.com.mx/node/5300#.VEaBTEskHgJ and I hope you can make it.

Categories: DAD discussions

Strategies for Organizing Large Agile Teams

October 16, 2014 1 comment

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Team Approach Advantages Disadvantages Considerations
  • Reduces communication between sub-teams
  • Enables teams to build technical expertise specific to their component(s)
  • Requires a loosely coupled, highly cohesive architecture
  • Functional dependency management can be complex
  • Requirements need to be aggregated by component
  • Use for components or subsystems that are highly cohesive and loosely coupled
  • Use for technical-oriented components, such as a security framework or database encapsulation services, which require technical expertise
  • Enables teams to focus on a subset of the business
  • Potential to make it easier to assign features to teams
  • Requires common development conventions
  • Requires sophisticated configuration management
  • Technical dependency management can be complex
  • Requirements dependency management can be complex
  • Use for complex LoBs or applications which require developers to have deep understanding of the problem domain
  • Enables functional specialization of individuals
  • Comfortable approach for people with deep experience with traditional approaches
  • People motivated to be specialists, not generalizing specialists
  • Significant communication overhead between teams
  • Requires more documentation and reviews thereof
  • Requires greater management oversight
  • Increases overall project and organizational risk
  • It often makes sense to have an integration team responsible for integrating the entire solution and testing it end-to-end.
  • Support a “follow-the-sun” strategy where development is performed in one location and testing in another
Internal open source
  • Supports development of shared components or subsystems
  • Spreads the cost of building these components across several development teams
  • Requires other teams to provide developers, at least on a part time basis, to work on this effort
  • Requires management and governance structures which reflect open source development
  • Apply in organizations with developers with deep experience with “public” open source efforts


Categories: DAD discussions

Geographically Distributed Agile Teams

October 8, 2014 Leave a comment


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:

  1. What does it mean to be geographically distributed?
  2. Are agile teams geographically distributed in practice?
  3. How does geographic distribution relate to other scaling factors?
  4. What are the potential benefits of geographic distribution?
  5. What are the risks associated with geographic distribution?
  6. How do we address those risks?
  7. How do we organize a geographically distributed agile team?
  8. How does geographic distribution affect tooling?
  9. Is geographic distribution a good idea?
  10. Where do we start?
  11. What other resources exist?

I hope you enjoy the article.  Feedback is always welcome.

Agility at Scale Landing Page

September 26, 2014 Leave a comment


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:

  1. Scaling Disciplined Agile Delivery (DAD) to address scaling factors such as team size, geographic distribution, organizational distribution, technical complexity, domain complexity, and regulatory compliance.
  2. Scaling agile and lean techniques and philosophies across your entire IT department.
  3. 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.

Categories: DAD discussions

Tool Support for Discplined Agile Delivery (DAD)

September 12, 2014 1 comment


We recently posted a new page titled Tool Support for DAD which you may find interesting.

Categories: DAD discussions

Potentially Shippable Software Isn’t Sufficient: The Glass of Water Analogy

September 2, 2014 5 comments


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. 

Categories: Philosophies, Scrum

Toronto Agile and Software 2014

August 19, 2014 Leave a comment


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.

Categories: DAD discussions

Get every new post delivered to your Inbox.

Join 607 other followers