(Note: The first version of this was a very random draft rather than the first part that I wrote. I blame computer elves. This should be a bit more coherant)

This episode of the series will focus on the development team – how a feature idea becomes a shippable feature.

A few notes before we start:

• I’m using “feature” because it’s more generic than terms like “story”, “MVP”, “MBI”, or “EBCDIC”
• I picked an organizational structure that is fairly common, but it won’t be exactly like the one that you are using. I encourage you to draw your own value stream maps to understand how your world is different than the one that I show.

In this episode, we will be looking at the overall development team. I’m going to start by looking at a typical development flow:

Green lines are forward progress, red lines show that we have to loop back for rework.

That’s the way it works for a single developer, and across a team it looks something like this:

I’ve chosen to draw the case where features are assigned out by managers, but there are obviously other common choices. Hmm… there are already a ton of boxes in the diagram, and this is just the starting point, so I’m going to switch back to the single-developer view for now.

What are we missing?

Adding the Queues

There are several queues in the process:

1. The input queue, which I’m going to ignore for now.
2. Design Review: After I have finished a design, I send it out to the rest of the team for review.
3. Code Review: After I have finished the implementation, I send out the code to the team for review.
4. Code Submission: I submit my code to an automated system that will run all the tests and check in if they all pass.
5. Test: The feature moves to the test phase. This might be done by the development team, or there might be a separate test team.
6. Acceptance: Somebody – typically a product owner – looks at the feature and determines if it is acceptable

Now, let’s put some times on the time spend in the queue. The numbers I’m listing are from my experience for a decent traditional team, and they are typical numbers.

1. Design Review: 3 hours to 1 day.
2. Code Review: 3 hours to 1 day.
3. Code Submission: 30 minutes to 1 day.
4. Test: 1 day to 10 days
5. Acceptance: 1 day to 10 days.

Here’s an updated diagram with the numbers on it:

At this point, we would typically try to put numbers on all of the blue boxes, but because our features sizes vary so much, the numbers were all over the place and weren’t very useful.

We can, however, try to put some numbers on the red rework lines. I’d like you to think about what the numbers are in your organization, and we’ll pick it up from there.

Part 3: The Development Team (2)