Cyara’s Domain Consulting team works with many organizations who are undertaking the DevOps journey. While we’ve talked a little about some of the challenges in adopting DevOps, I’d like to expand a little more on moving between stages of DevOps maturity and the difficulties it can present.
Making a Start: Putting Together a Team
In our conversations with Cyara customers, we’ve seen that the first step of the DevOps/Agile process is relatively easy. In most cases, a few people within an organization who believe there must be a better way than the status quo will identify a need to improve processes. Thus, a team of cross-functional people adopt a DevOps or Agile model. To achieve this, they might form a separate DevOps/Agile team within the organization, that is allowed to work outside of the typical constraints. Because this team has bought into the fundamental mindset shifts necessary, they will show positive results.
Scaling the Process
The next stage is to cross-align the organization or a business unit, meaning that the processes put in place by the dedicated DevOps team are scaled or reused across multiple teams. While working with our customers, we’ve observed that this stage of maturity is much more difficult to achieve. While they may have adopted new rituals and ceremonies such as stand-up meetings or scrums, many teams are still following their old ways of working. So a scrum master may continue to function as a project manager, assigning tasks and getting status updates during stand-ups instead of working to solve problems or allowing the group to agree on who will take on which tasks. Ultimately, when this happens, the organization will derive very little value from adopting the DevOps model.
I believe the main difficulty at this scaling stage lies in getting team members to buy in to the mindset shifts — they’re being asked to completely change how they work in a lot of cases. It’s important to get buy-in, and this is where a champion is key. Their role is to convince individuals that the new way of working is better, and also to understand why people might be reverting to their old ways when that does occur.
Going Enterprise-Wide
We’ve found that the third and by far the most difficult stage of the Agile transformation journey is taking it across the organization. This is because supporting functions such as the Human Resources and Finance departments need to change how they work as well.
With respect to Finance, most organizations have a yearly budgeting cycle, but DevOps and Agile are better supported by a faster budget cycle or a different way of allocating funds entirely. For instance, if someone in a team has a great idea, but there will be no budget available for another 9 months, that potentially represents longer time to value and 9 months of time wasted waiting for funding. Concepts such as Innovation Accounting (which I cover in more depth later in this post), where teams are given a small amount to try ideas out and are rewarded with further funding if they show signs of success, are much better suited to the DevOps way of working. In effect, it’s a shift away from financing projects to financing resources and allowing teams to determine how they use those resources.
From an HR perspective, DevOps transformations often involve comprehensively reorganizing work forces and shifting layers of middle management. Here, the idea is to empower knowledge workers (who are closer to the work that’s being done and have a deeper knowledge than their managers) to make decisions. This has major implications for the HR team.
Changing Mindsets
Think Products or Services, Not Projects
I’ve talked about the importance of getting buy-in to a DevOps transformation; that means a fundamental mindset shift also needs to occur for it to be successful. When organizations adopt Agile or DevOps, they shouldn’t be thinking in terms of projects, but in terms of long-living products or services. They should be considering the whole lifecycle. This is because in a project model, once the project is delivered, for example, there is not a lot of incentive to look at how to operate it. That is really what gave rise to DevOps in the first place — the software might be delivered but corners might have been cut and there are problems in production, but the project is considered to have been finished and handed over. However, it is still costing other parts of the organization time, money, or resources.
Approaching the objective from a product or service perspective essentially encourages teams to have empathy with their future selves: they may decide not to cut that corner so they can avoid the 3am calls when there is an issue in production. Essentially, adopting this new perspective enables people to start thinking about the decisions they make differently.
Iterate, Iterate, Iterate
In his blog, Henrik Kniberg talks about the importance of working iteratively and incrementally to build an ‘earliest testable/usable/lovable’ product, but also about the importance of iterating on the whole to achieve an outcome. Doing this instead of trying to deliver a complex, expensive, innovative product that might not satisfy your customers’ requirements anyway requires a big shift in thinking.
Image credit: Henrik Kniberg
Innovation Accounting/Metered Funding vs Entitlement Funding
As I touched on earlier, many organizations use the same kind of budgeting process wherein funding is awarded on an annual basis. In The Startup Way, Eric Ries refers to this as ‘Entitlement Funding’. There are a number of problems with this approach, but he argues that the biggest is that it’s difficult to energize teams and innovate when they feel entitled to funding year after year.
Ries’s solution is to adopt Metered Funding or Innovation Accounting, which involves less complexity and matures along with the team and the product. The process starts with small amounts of funding and access to a small amount of customers, and if the team demonstrates success and validates their assumptions, new funding is released to scale (i.e., they run more experiments on a larger sample size).
Once funding is released to a team they can do what they want with it — there is no taking it back. However, if they use it all up and are unable to demonstrate progress (learning, growth, and so on) then they don’t get access to anymore funding and the initiative is shut down!
In his book, Ries describes a roadmap where the organization can mature their use of Innovation Accounting as teams or initiatives scale. An organization implementing this type of process might use the following roadmap:
- Dashboard
- Goal: show learning at small scale (limit costs and risk), demonstrate likelihood of success
- Metrics (examples): Conversion rates (number of people that go from trial to signed up), Revenue per customer, Lifetime Value per customer, Retention rate, Cost per customer, Referral rate, Channel adoption
- Notes: short cycles (weekly), focus on revenue and short term, less focus on costrs and long term retention
- Business Case
- Goal: validate “Leap of Faith Assumptions” (i.e., key assumptions) of a thought-out business plan
- Metrics: should reflect complete interaction with the customer, should validate value hypothesis (What is the specific customer behavior that indicates delight with the product?). Examples are: repeat purchase, retention, willing to pay premium price or referral, should validate growth hypothesis (Given that a customer delights in our product, what specific customer behavior will cause us to acquire more customers?). Examples are: word-of-mouth referral is higher than attrition (AKA sticky engine of growth), revenue from existing customers is reinvested to attract new customers (AKA paid engine of growth) or new customers can be recruited as a side effect of usage (i.e., network effect like Facebook or LinkedIn) (AKA viral engine of growth)
- Net Present Value (NPV)
- Goal: re-run dashboard with new values after each iteration and translate to NPV using standard financial tools
- Metric: Net Present Value
Using this same method across all initiatives allows organizations to compare all their investments in a like-for-like way.
Clearly, adopting a fundamentally different budgeting process like this requires a fundamental change to an organization’s mindset.
To learn more about how Domain Consulting can help you, get in touch with your account executive.
