Yesterday, I was talking with members of the SAS government team about recent developments, such as the state of their business, acquisitions (here's my take on one of those companies), and success stories. I was very, very happy that they wanted to devote the majority of time on the success stories, since you often get more insight from discussing how customers are using technology than running through the list of new features and functions.
Funny thing, that's exactly the conclusion of our research on thought leadership: If you want to be a thought leader, talk about how you've made people successful. Actually, there are more aspects of thought leadership, but success stories are a good place to start. Not only do they illustrate how a vendor can contribute to a project, but they also identify the types of projects worth pursuing.
SAS is involved in well-established, well-understood government activities, such as preventing fraud in corporate tax collection and social programs. It's also involved in far less established and understood areas, such as nipping new cybersecurity threats in the bud and dealing with recent IT requirements for health care. Not only are governments trying to figure out how to fit technology into their strategies for dealing with these new challenges, they're still figuring out the strategies.
Our first application of Agile principles to the research process, which occurred during our study of thought leadership in the tech industry, was a very Agile-esque journey into the unknown. We learned a great deal that applies to future applications of Agile Research Development, so here's my retrospective.
You Can Be Agile Up To The Boundaries Of What You Control
Ultimately, you control only part of the value stream. This maxim holds true wherever you apply Agile, and software developers learn this principle right away. You can be the most disciplined developer imaginable, never checking in code that doesn't work, always building in tests, and still be at the mercy of your own QA team. And even if the larger team, including testers, works in blissful harmony, someone needs to deploy the code on a live system. (Which is why dev ops is receiving a lot of attention from within the Agile community these days. See Jez Humble's recent book for a good example.)
If a stream is an appropriate metaphor for value creation and delivery, then this stream always takes many twists and turns, frequently encountering dams and obstructions. The success of Agile, therefore, depends to a great extent on eliminating these kinks, navigating around them, or learning to accept them as part of the value stream's trajectory.