Aug 062015
 

One of the best presentations I heard this week at Agile 2015 was Declan Whelan and Jason Little’s pithy summation of the necessity of structural change in organizations embracing Agile. Their argument was as pithy and forceful as the phrase, No justice, no peace: No structural change, no Agile. If you want to judge whether any organization, including the big and complex ones most notoriously prone to inertia and rigidity, has embraced Agile, look no further than the presence or absence of significant structural change. Agile should remold the organization, starting with the team, not just turn into another set of governance rules (“Thou shalt do a daily stand-up”) imposed on teams.

We’ve been over this ground many times, but we keep getting better, year by year, at understanding what those organizational changes should look like. We have more experiences on which to draw, from small software start-ups to large biomedical device companies. We have learned how to articulate these changes more clearly: scaled Agile frameworks, for example, are in essence an attempt (frequently misunderstood) to describe what those structural changes might look like. We have, by no means, arrived at a final answer, but we get better, year by year, at understanding the range of possibilities.

While we definitely want to keep exploring the structural changes that Agile demands, we shouldn’t be apologetic about these seemingly incomplete results. All the time, we take a chance on other kinds of innovation that has organizational effects that we understand far less. We don’t stop in the face of them; in fact, we muddle through our imperfect understanding of these changes, and our imperfect efforts to deal with them.

I’ll get back to Agile in a moment, but first, I’ll give an example from military innovation. In 1914, the great powers of Europe new that airpower would have some impact on the future of warfare. However, their first guess at what that impact would be was completely wrong. The original vision was of zeppelins dropping bombs on cities, terrorizing enemies into submission. After the war started, and that very grand expectation proved completely wrong, airpower assumed a more limited role, a means to collect battlefield intelligence and support the artillery, using fixed-wing aircraft, not zeppelins. Even though airpower in World War I turned out to be something completely different than originally envisioned, the Great Powers did make the necessary adjustments, including to the military organizations themselves. These governments muddled through, just as we all do, every day.

If you read the social science literature on innovation, which I hope you do, you’ll find that no innovation has zero organizational cost. Every innovation means some structural change, often out of scale with the innovation itself. And yet, we muddle through.

Take, for example, the introduction of user experience design into the team. At first glance, UX might look a lot like a simple addition to the repertoire of skills on the team. However, the organizational impact can be quite large. UX designer becomes a new role on the team — an increasingly essential individual, in many cases. Frequently, the UX person started in a different role, such as business analyst, and the result is a hybrid BA/UX function. The team’s proficiency at generating UX designs, earlier in the development cycle will change the timing and content of collaboration with the customer. Release and sprint planning will need to change, to accommodate UX activities.
Even smaller changes require organizational changes. A new built automation tool might prompt someone on the team to adopt added responsibilities around scripting and streamlining the build process. Moving to Git as the source control management system might increase the status of younger developers on the team, who have more experience using Git in college and in open source projects. A new Agile planning tool might increase the transparency of the team to the  rest of the software value stream, reducing the need for project managers to communicate status, leading to questions about how else they will spend their time.
In other words, any change — methodology, technology, or tool — has organizational implications. That should not frighten people about organizational change; instead, it should reassure us that we’re able to make these structural adjustments. Agile happens to be an increasingly known quantity, even if the scale of change is quite profound.
In every case, if we don’t make the structural modifications, we won’t get the value out of UX design, the new build automation tool, Agile, or any other change we embrace. The classic science fiction writer Robert Heinlein had an acronym for this principle, TANSTAAFL, which stands for, There ain’t no such thing as a free lunch. Happily, in the case of Agile, the structural change is easier to anticipate.
avatar

Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.

Discussion

  One Response to “Agile Organizations And The TANSTAAFL Rule”

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)