How Long Are Your Iterations? Part 2

implement by featureWhen I teach agile, I explain I like small and short stories. I want to see value in the product every day.

Many developers can't do that. That's because they have interdependencies with other teams—not developers on their team, but other teams.

They can't implement in the way the picture next to this shows: small, coherent slices through the architecture.

Instead, they implement in curlicues.

When you implement by curlicues, you often have to wait for other teams. You might have component teams. You might have performance teams. But you can't implement in nice “straight” features. Your features are complex and don't take a straight line through the architecture.

When I work with people who have curlicues instead of straight lines through the architecture, I often discover that the different teams can complete parts of features in one iteration. (It doesn't matter how long the iteration is.) But completing an entire feature? Because that takes the efforts of several teams, the team members believe they have interdependencies and the full feature often takes longer than one iteration.

The teams are correct. They have interdependencies. Sometimes, those interdependencies are quite difficult to see when you start. You only know that they exist when you get stuck partway in the feature.

Implementing by curlicue creates delays. The iteration is not the two weeks, three weeks, four weeks. No, the iteration can be as long as eight, nine, or ten weeks. That's because each piece of the curlicue has to get to the top of each team's backlog. The teams might have different product owners who don't realize each arc of the curlicue is actually related to each other, that you need all of them to become one finished story.

In the meantime, each team has work in progress (WIP) and might not realize it. Or they do realize it, but they can't get “credit” for their work.

What can you do if you are in this pickle?

  1. Consider asking the component teams to self-organize into feature teams.
  2. Ask the teams and product owners to collaborate on backlog ranking for each team according to total feature. This will allow the teams to work together, as if they are in a program.
  3. Ask one team to do the entire feature. Stop asking component teams to specialize in one component. That would allow the teams to see what the smallest value is, and implement that. (Repeat until you get the entire feature.)
  4. Make the stories smaller to see the value build. When I see this, I often see very large stories. Too often, the teams work across the architecture, doing platform work, database work, GUI work, rather than see the simplest possible feature that would allow everyone to see the value.

I bet you have other alternatives you might consider. If you see other alternatives, please comment. I would like to help more teams see how to manage their interdependencies or remove them altogether.

The first post was How Long Are Your Iterations, Part 1.

7 thoughts on “How Long Are Your Iterations? Part 2”

  1. This is an Agile At Scale issue and is the “norm”where we work. The solution is a higher level planning process showing the interdependencies for the team. Most agile tools provide this. Ours is Team Foundation Server, but other do this as well.

    For the Feature interdependencies, a “network” of these dependencies drives what work is performed in what order. This is standard project management using the Master Schedule. The Features are sequenced in the needed order to produce the needed Capabilities (Epics) in the needed order. Then the interdependencies are visible to all the teams and they can act accordingly.

    The interdependencies can’t be removed – in fact are part of the system of systems architecture – but now they’re know and can be managed “above the line,” at the systems integration level, while the “agile” work is done by the individual teams

    1. Glen, that’s certainly one way to do it. It sounds as if you get the product owners together and help them manage the backlogs, so each team has the interdependent features ranked at the same level. That was something I taught several teams to do recently.

      Part of me still wonders if the architecture is from Conway’s Law, and there might be a way to rethink the teams’ makeup or simplify the architecture. One of my clients has said yes to that. Two have said no.

      This is not easy, regardless of the way you attack it.

      1. The architecture is from the Systems Engineers, DoDAF and ToGAF not the organization.

        Conway may be present in commercial orgs but not the same way were we work. The organizational structures are unique to the orgs. RTN has much different org then LMCO for example. But the technical architecture is imposed from the outside.

          1. Agile is flowed down from the acquisition processes in DOD, DOJ, DOE, NASA, and HHS.
            If you google “agile in the DOD” you see the work has been going on since the early 2000’s (2002) was my first paper at an Agile Conference for a DOE program I worked.
            Lately Dr. Carter (The SecDef) has release Better Buying Power 3.0. That has an Agile component.
            Another client (OSD(PARCA)) is leading the integration of Earned Value Management with Agile, with two recent conferences One that has public briefings the other that doesn’t.

            But this is not “your fathers Agile,” It’s not 5 people at the same table as the customer, pair (or heaven forbid Mob) programming and showing the customer work at the end of the day. These are $20M or greater SWDev programs – System of Systems – that benefit greatly from “agile” approaches to the emerging requirements to fulfill a set of “needed capabilities”

            Here’s a typical experience report in the INTEL Community,

  2. So, no, our problem is not in curlicues. We have some dependencies, but they are well outside of the product. And although they are delivered by separate teams (using mostly waterfall), I do not see that as a main problem when it comes to the size of stories. The main problem (and I really have looked into it from several different directions) is that they are large because: 1. the system itself is very complex and deeply integrated (this can be solved by changing the architecture and definitely would be a good thing to do), 2. we are using some “legacy” technology, such as enterprise J2EE spiced with some frameworks that basically inhibit rapid development (I am told that this is because of the stability, scalability, performance, … – I am not sure, but let’s not go there now), 3. the system is huge and the business processes themselves are very complicated (this may have to do with the fact we are in a regulated business, but I suspect more has to do with our inability to just don’t solve some corner cases) and 4. we have very little automation (so testing is really painful).

    So, if I were to make any conclusion, it would be: if you already have followed all the advice you list within your post (you already have cross-functional teams, you are doing the smallest thing that will bring customer value, …) and your iterations are still long, try to look at:

    1. What technology are you using and whether the technology itself is not blocking you from going faster.
    2. How big, complex and old your system is and how much technical debt has accommodated in it and is slowing you down.
    3. What level of testing automation do you have and how frequently you are able to assess that what you are building actually works.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: