In the first in our interview series with industry luminaries, we chat with Jim Highsmith, executive consultant at Thoughtworks. He has more than 30 years of experience in IT and is the recipient of the 2005 Stevens Award for outstanding contributions to systems development. Jim is the author of Adaptive Software Development (2000 Jolt Award winner), Agile Project Management: Creating Innovative Products, Agile Software Development Ecosystems and the just-released Adaptive Leadership: Accelerating Enterprise Agility.
Q: As one of the signatories of the Agile Manifesto, you’ve witnessed Agile grow from a unique vantage point. What have been your observations of its evolution and adoption by the industry?
A: There are not many industry movements that have been sustained over what is now about a 13-year period. I think one of the big differences, and advantages, of the Agile movement is that it has a set of articulated values and principles—the Agile Manifesto. Previous methods had processes and extensive documentation—but no heart, no emotional anchor that said, “This is what we believe”. I think the fundamental driving objectives that energized the 17 manifesto signers—building better software and creating engaging work places—have been successfully met in many organizations. Not enough of course, but a growing number. Surveys show that Agile is being used, in part at least, by a majority of companies worldwide.
However, there are four key areas for expansion and growth in the future:
- Being Agile
- Technical Practices
- Innovative Extensions
- Enterprise Agility
First, too many organizations are “doing agile” without “being agile.” They embrace the practices, but not the culture. Second, more organizations need to embrace the technical practices of Agile as well as the planning and management practices. Third, we need to keep the Agile movement invigorated through innovations like continuous delivery, and linking to other key movements like Lean/Kanban and Lean Startup. Finally, enterprises need to become more responsive to be competitive; they need to embrace Agile, Lean, and other emerging, innovative leadership ideas.
Q: What does Agile bring to the table for senior leadership? How does it translate into value for them? Why would you want your enterprise to be agile?
A: Every two years, since 2004, IBM has published a study about the concerns of CEOs around the world. In 2012 the number one issue for CEOs was technology. Managing complexity was the theme of the 2010 study. Executives are concerned about three interlocked trends: advanced technology, disruptive change, and complexity.
“To put it simply, there has been no other point in history when so many aspects of disruptive change have collided and conspired to wreak havoc on the retail and consumer packaged goods industries,” says retail guru Doug Stephens in his recent book, The Retail Revival: Reimagining Business for the New Age of Consumerism.
In the retail industry where technology (cloud, big data & analytics, social media, and mobility), complexity (tying new technologies together with legacy systems and the organizational complexity to manage the business in new ways), and disruptive change are causing massive headaches for leadership. The retail industry at least has a name that encompasses these issues—omni-channel—using all these new technologies to create a new and completely integrated customer experience. These ideas challenge the very core of the retail industry and it’s not an IT solution, it’s a business solution, powered by IT, that requires agility on everyone’s part—from top to bottom and side to side in the organization.
Q: In the Agile movement, typically, the onus of “putting Agile into practice” lies with the development team. What is the role of senior management in an enterprise-wide Agile transformation?
A: Most Agile transformations begin with, appropriately, with delivery teams. Agilists have focused on defining roles, processes, and practices for members of delivery teams—developers, testers, product owners. We haven’t been very definitive about what senior managers’ role is other than supplying money and support. However, there are three key action items for managers and executives:
- Create a vision for a responsive enterprise (Ask yourself—what would your agile enterprise look like and why is it important to your future?)
- Deliver a continuous stream of value to the enterprise (examine new performance measures, reduce batch sizes and cycle times, focus on enhancing value measures, think in terms of continuous delivery, not the old delivery then maintenance model)
- Create an adaptive, innovative culture (the cultural transformation is the most difficult, but the most important. It’s not enough to just do agile management practices, we must be agile in our behaviors).
Q: In the current healthcare.gov crisis, many have pointed out that testing was neglected till the very end. What guidance would you give to the leaders of this initiative in terms of creating a more responsive organization?
A: Test early and often.
Q: What aspects of Lean and Kanban help with Agile transformation?
A: Lean, Kanban, and Lean Startup are all complementary with Agile and should be incorporated as they become useful. Some feel that the word and ideas around “Lean” have more meaning for upper management than “Agile”—some feel “Agile” does. Use what works in your organization. Those responsible for transformation have to find a way to incorporate and integrate ideas, principles, and practices from all of these areas.
Q: What are some techniques you recommend for measuring the success of your enterprise Agile adoption? How do traditional viewpoints of defining success work with Agile projects?
What to measure somewhat depends on where an organization is in the adoption process. One useful metric is the “tail” length—the length of time from code freeze until deployment. I like using the metric of “tail” length because it is easy to calculate and tells a lot about an organization’s agile implementation. It’s not a vanity metric, like the number of developers who have attended a refactoring seminar, but a true learning metric because it focuses on a key tenet of agile development—running, tested software. It’s also a metric that can help an organization move closer to continuous delivery.
The “tail” period is when companies do some or all of the following: beta testing, regression testing, product integration, integration testing, documentation, defect fixing. The worst “tail” I’ve encountered was 18 months—18 months from feature freeze to product release, and most of that time was spent in QA. Using the tail length metric, particularly in products or applications that have large legacy code bases, can help organizations monitor their progress toward continuous delivery.
Shortening the tail is a simple, powerful metric for measuring progress toward agility. The goal of agile teams is to produce shippable software every iteration, but most are far from this goal—especially if they have large, old legacy code bases. Think of everything a company might have to do to reduce a tail from 6 to 3 months, then to 1 month, then to 1 day.
For large products, the tail might never reach zero, but it could be small. Just think of the competitive disadvantage a company has when its delivery tail is 18 months, or even 6 months. Such a lengthy tail means that for 6 or 18 months prior to release, no changes in the competitive environment could be incorporated into the company’s products.
Q: In your book you talk about the financial implications of technical debt. How does the executive translate it to the customer who would rather prefer that the team “builds more features than fix tech debt”?
A: When we ask managers “more feature or higher quality" (less Technical debt, etc.) we are asking them to trade off a business outcome for a technical outcome—mostly as we have learned, a losing proposition. We need to switch the question to one of business outcome versus business outcome—features or reduced cycle time. Business managers are always asking for quicker results, and the key way to become quicker is to reduce technical debt, improve quality, and implement continuous integration and delivery. Let the development team worry about the technical details of “how” to improve cycle time, but impress on management that they need to think of the tradeoffs in different terms than the old features versus quality.
Enjoyed the interview? Explore further resources for your Agile Project Management needs
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.