Last week, five of Excella’s Agilists traveled to Orlando, FL for Agile 2017 for a jam-packed week of learning about all things Agile! Here they share their top takeaways of the conference.
Security Testing in an Agile World – Dan Davis
One of my favorite presentations this year was Abhay Bhargav’s talk on how to incorporate security into an Agile team. Security is generally a hard piece to integrate into an Agile team, especially those practicing continuous delivery. Bhargav offered an interesting approach—in addition to traditional continuous delivery tools like scanners and static analysis tools (which only cover about 30-40% of vulnerabilities) he suggests writing “abuse” stories based on how a particular feature could be exploited. For example, a team building a new form would create a threat model for how that form could be abused and then write stories to prevent those exploits. By doing this work earlier in the process, the team is more likely to pass security audits later in their release cycle and avoid the typical deluge of findings right before go-live. Even better, when a security vulnerability is discovered, teams can write an automated acceptance test to reproduce the bug and demonstrate that it’s been addressed. I loved the idea and Bhargav’s talk gave me some valuable talking points for working with security-conscious organizations that want to practice continuous delivery.
Shifting from Technical Debt to Technical Health – Paul Boos
My most insightful takeaway came from the Audacious Salon session run by Declan Whelan. He is running an Agile Alliance initiative focused on addressing Technical Debt. He hypothesizes that by changing the dialogue and emphasizing the creation of Technical Health, we can embed better technical practices into an organization’s DNA. We explored the differences between a focus on addressing technical debt and an emphasis on maintaining good technical health, and through that process uncovered systemic beliefs, principles, and practices that would need to be in place to encourage Technical Health. The concern shifted from a problem at the team level to an overall concern for the entire organization. I came away with a number of ideas, not only on this, but also on how to help an organization make this shift using systems thinking.
Stumbling with Intent – Trent Hone
I was most impressed by the very mindful talk Woody Zuill gave on the value of “stumbling purposely and purposeful stumbling.” He believes we need to explore, experiment, and meander a bit in order to deeply understand our circumstances. Inevitably, when we do that, we will make mistakes, but we will learn through the process. Our power as change agents derives from our ability to purposefully “stumble,” mindfully assess what we’ve learned, and adapt to newly emerging information. The humility and intentional curiosity embedded in the concept really spoke to me and reminded me of successful Agile transformations. So much depends on adapting Agile to an organization’s context; Woody spoke to that well.
Focusing on Value and Impact – Mathias Eifert
One of the principles supporting the Agile Manifesto states “working software is the primary measure of progress.” However, there is an emerging consensus that working software is a necessary prerequisite to fulfill the promise of Agile, but a focus on IT deliverables alone is no longer sufficient. Different presenters used different terms – Business Agility is pretty well established, Full Stack Agile is a very descriptive and intuitively appealing phrase that I heard in Felipe Castro’s presentation – but there is a growing chorus of voices that emphasizes the need to focus on value and impact, not just outputs from a feature factory. Two of the main challenges in this regard are how to achieve better alignment between IT and the rest of the organization, and how to establish feedback loops that let us know if we are achieving the desired impact.
Credit to John Cutler, taken from https://felipecastro.com/en/okr/okr_and-agile/
Evan Leybourn presented on the importance of identifying and pursuing business outcomes rather than completing projects defined by sets of features. Felipe Castro gave a great overview of how OKRs (Objectives and Key Results) can support autonomous execution by clarifying strategic objectives and associated business metrics. Other presentations covered the topic of delivering value from different perspectives. It is clear that having IT teams working inside a small Agile delivery box is not creating the desired ROA (“Return on Agile”) or ensuring success in today’s competitive landscape. Even when deployed continuously, working software is no longer enough.
Doing the Right Thing… Not Just the Thing Right – Tony Solomita
At Agile2017, I consistently heard amazing stories about teams delivering software better and faster than ever before. But, for every story about deploying to production five times a day in the federal government (Dan Davis said what!?), there were very few conversations about the business value these deployments delivered. And, it’s not that we don’t know how to discover what we should be building – Mathias Eifert, David Bland, Ellen Gottesdiener, Angela Wick and others have us covered – it’s that we simply aren’t doing it.
Why?
It’s impossible to know, but I think I have a pretty good idea. Smart people with really good ideas don’t want to hear that users don’t want to buy, or use, them. If a company’s survival depends on the success of a product, maybe those smart people will listen. But, in federal agencies and large companies that have dozens of efforts going on simultaneously, the success of one effort probably doesn’t matter. It DOES matter to the users though, even the users that are “mandated” to use the system. That’s why we have all those home-grown databases and spreadsheets and paper files sitting out there as workarounds for beautifully crafted pieces of software that were delivered on time, but didn’t come close to meeting users’ needs.
So, I guess it’s about time we really start to heed Eric Ries’s advice from The Lean Startup, “The big question of our time is not can it be built, but should it be built.” We know how to figure this out. The users are demanding it. It’s time that we just start doing it!