Image source: https://www.brainerddispatch.com/4490857-together-we-paint-mural-becomes-community-coloring-book

8. Allow teams to start pulling features to create

At this point, people start building. Importantly, they are not trying to build the entire solution: they are trying to prove capabilities. And importantly: while people need to build features, they need to stay focused on the capabilities. The capabilities are what are needed so that the product can do what is promised. The capabilities are the components of the big picture. The capabilities are the goal—not the features!

Think back to the X1 program. The goal was to prove that an airplane could break the sound barrier. Bell built prototype after prototype. Unfortunately, several people died in the course of that, but eventually one of the prototypes, flown by Chuck Yeager, succeeded. From that point on, work shifted to refining the machine, and then coming up with improved designs. The work on the X1 and its successors eventually led to the X-15, which was contracted by NASA (then NACA) and built by North American Aviation and Reaction Motors.

The point is that once you prove a capability, you can shift to refining that capability, and the main focus shifts to proving other capabilities that are needed for the entire solution. Adding (or changing) features is how you incrementally refine something.

Integrate All Along

In the article “The Development Runway” (a subtopic of step 4) we said to “go end-to-end from the beginning”. That includes integrating the various capabilities of the product. At the outset the capabilities will not exist, or will be skeletal. That’s okay: integrate those. Create a stand-in for each capability, so that you can set up the integrated skeleton. Some people call that a “walking skeleton”. That is what you start running your integration tests again. If there are tests that you don’t expect will pass, don’t run those yet, but run the integration test process, triggering all the tests that you expect should pass. Get the integration testing process going, and automate everything you can, from the beginning.

Help the Teams to Organize

The Agile Manifesto advocates self-organization. Unfortunately, Leader-Member Exchange theory tells us that self-organization does not usually go well. However, the key idea is powerful: individual agency. People do organize well if you give them help.

When setting up a team whose members you are not familiar with, one approach is to first challenge them, and then observe. See who actually does what. See who helps others. You cannot do that from a distance: you have to be right there. Do not conflate verbal participation with action: some people are good talkers, but might not be doers. Find out who the doers are. And the helpers. And the organizers. And the thinkers. Those are the people who you want to empower.

If someone is a thinker but is not good at expressing themselves in a group, they might benefit from having a role that encourages others to pay attention to them. If someone is an organizer, but is not good at getting others to cooperate, you might empower them by giving them a role for getting things organized.

The goal is to get the full benefit of everyone’s mind and natural inclinations. To do that, you have to pay close attention. You have to understand people. And you have to see beyond what people say, and see what they actually do. Read more about this in What About the Teams Themselves? in the right panel.

 

Step 7 <—

—> Step 9