Recently, we hosted a webcast featuring Jeffrey S. Hammond, Vice President, Principal Analyst Serving CIO Professionals at Forrester, to present "Digital Transformation Starts in Dev."
Business leaders everywhere are plotting out their digital transformation strategies, and how to get closer to customers?fast.
But there's a looming challenge: real digital transformation requires fast, sweeping modernization of development culture, processes, and old systems into new cloud-based systems that are agile, mobile, and able to deliver disruptive, real-time intelligence. Without major changes in your development shop, a digital transformation will struggle to take hold. In this Q&A with Jeffrey Hammond, Forrester Vice President and Principal Analyst, Jeffrey details his thoughts how to best guide your development shop transformation, including best practices that put the customer at the center of software delivery efforts.
Following our presentation, I sat down with Jeffrey to discuss his thoughts how to best guide your development shop transformation, including best practices that put the customer at the center of software delivery efforts.
Q: What do you do in a situation where there are cultural problems, but management is slow to understand them or act on change?
Jeffrey: Well, if you are running a team, you can have an impact on the conditions on that team and "run interference" for your folks. Try to understand what their blockers are and remove them. You can also look for other allies in the organization?change makers. Often, we see new executives brought into a digital organization to "shake things up." These folks are potential allies in change. You can also look to move toward parts of your organization where an Agile development approach and high-velocity delivery are not an option. As an example, mobile apps must release several times a year just to keep up with the platforms and with the competition.
Many companies have a digital team that is responsible for mobile apps and other customer-facing digital channels, and we often see these teams embrace Agile development practices ahead of development teams in IT organizations. Or, another example might be transferring into the part of your technology organization that's working with public cloud technologies, as the tools, services, and level of service abstraction all support a higher-velocity approach. Once you can demonstrate the capability to deliver functionality faster, your management is likely to give you more latitude to make broader organization and technology changes.
Q: What do you do if you can't find enough high-performance developers or can't afford them?
Jeffrey: If you can't find them, you can always try to rent them by working with a digital agency. But if you can't afford to hire your own, then a digital agency or specialist probably isn't an option, either. In that case, you can look for talent that others have overlooked, by looking at nontraditional options or developers who aren't classically trained comp-sci majors.
You can also use platforms, open source libraries, and third-party APIs to reduce the amount of code you need to write and maintain. Or you could look to expand the aperture of who can develop with a low-code tool. Any of these strategies or a combination of them might be an option depending on your circumstance.
Q: How do you convince the executive leadership team that an Agile transformation is the right one amidst a laundry list of other things that need to be tackled across the enterprise (e.g., technical debt, legacy migration, updating tech stacks)? How can you convince them that an Agile transformation can help put everything else in motion?
Jeffrey: All of the other issues mentioned here benefit from an increase in delivery velocity, and that's what an Agile transformation enables. Further, when you are updating your tech stack, there's always the chance you may not select the right technology.
An Agile transformation will help you discover that faster. Faster delivery helps you prioritize your technical debt and start building confidence in delivery and that teams are on the right track early. And legacy modernization works best when you refactor from the outside in, using design patterns that build APIs on top of existing applications to hide their complexity and that allow development teams to slowly replace existing apps a piece at a time. These modernization approaches of benefit from customer-focused Agile delivery teams.
Q: If Agile transformations truly start with dev, then what management layer or department needs to go next? Is there a method to transformation madness? An order in which things should be introduced or rolled out across an organization?
Jeffrey: Assuming that you've already brought in product owners or product managers, then QA needs to move next to get in sync with development, as Agile practices like test-driven development and automation can make or break an Agile team.
Devs also need to start realizing that "done" for them doesn't happen when the code is "checked in;" rather, it's when that code is deployed and working in production. The benefits are significant when QA activities are integrated into daily delivery processes, when they are highly automated and delivered by a team where everyone cares about quality and a great customer experience. After QA, bringing in design, ops, and data sciences are logical next steps?you essentially expand delivery outward.
