Embracing Modern Software Development
As software continues to eat the world, successful companies build strong development teams that are empowered to continuously innovate and move the business forward. Such teams operate as independent units and are able to leverage each other’s work to build up complete solutions. This mode of execution is highly efficient and scales well as the number of teams grows. Empowered teams that own the product development and operation are able to efficiently take ideas from design to production. This results in real agility where shifting priorities can be embraced as software is being continuously released.
As CTO of RightScale (now part of Flexera) I was directly involved in the modernization of our software development practices. We transitioned from a classic development setup with teams organized around functional areas (development, QA, operations) to a modern organization leveraging best of breed technology. I am very proud of what we accomplished in that time: we completely overhauled our development process and technology stack to enable the adoption of radical devops. The results speak for themselves: the team’s velocity increased by more than 30% and the work being delivered is more closely aligned with the needs of the business than it has ever been. It’s not just about speed and accuracy though it’s also — and arguably more importantly — about the sense of satisfaction of doing work that is more relevant in a setting that promotes creativity.
In this blog I’d like to share the most critical learnings that came out of our transition focusing on the changes we made to our development process. A separate blog — Tips & Tricks for Building Microservices — describes the underlying technology including key best practices. These two topics are closely related: applying modern software development processes requires modern technology and using solutions such as Kubernetes requires a modern devops-based development process. One cannot work without the other.
Empowerment
Not surprisingly, the key to velocity and frictionless development is empowerment. Development teams must be empowered to remove artificial barriers and accelerate decision making. Empowerment applies to all aspects of the development process:
· Teams design, implement, deploy and operate the supporting services. The adoption of modern architecture patterns like microservices would otherwise result in bottlenecks as multiple groups need to get involved at each stage and for each service.
· Teams decide what specific feature gets developed in a given focus area. This is a key empowerment enabler. Product decides the focus area and the priorities, teams decide what granular features get delivered.
· Teams have direct access to other groups in the organization. They reach out on an as-needed basis to product, sales, services and marketing for example. This gives the teams all the input needed to decide on specifics.
· Teams communicate directly with customers. Specifically, the team members understand the business goals of customers and not just what product features they need.
The first thing we had to change at RightScale was the teams composition. We dissolved the Operations and QA teams and reallocated the members to the dev teams. Team members learned from each other and the expertise spread across the team members very quickly — that ended up being a non issue. The biggest challenge was empowerment: changing the developers mindset from pure execution (“tell me what to do”) to actually owning the product development. Finding the right amount of direction to give to the team when starting a new focus area is still a tricky task. The key here is to have one or two anchoring features identified by Product that the team starts working on right away. The team then engages with stakeholders including customers to find out what’s missing.
An important side effect of empowerment is the direct impact on the team’s morale. Empowered teams are more engaged, work faster and produce results that are better aligned with the business needs. In this model the product group provides the longer-term vision and helps identify the areas of work in priority order. The group then operates on a consultative basis as questions arise during development.
Transparency
There is a natural tendency to want to protect precious Engineering resources from the rest of the organization. We found that approach to be counterproductive as engineers operating in a bubble is not conducive to producing work that aligns with the needs of customers.
Concretely the development teams at RightScale include honorary members from other departments. This includes a dedicated support engineer that reports on issues related to the services owned by the team. The support engineer also provides valuable feedback when designing new features to enhance supportability. He is also intimately familiar with the team’s roadmap and can thus better prepare the entire support group as new features get released or existing functionality evolves. Another key honorary member is an account manager that handles the team’s communication with customers and provides feedback coming directly from the field. This helps keep the team grounded in reality and is also a powerful tool to strengthen customer relationships. Having the teams engage directly has helped us turn customers at risk into happy ones more than a few times.
Communication is bi-directional with the team producing frequent progress reports and broadcasting completion dates as they become available. The end result is a much-improved alignment across the entire organization: The different groups understand what Engineering is working on and why. Sales can talk more effectively to customers and the services group can anticipate changes and affect outcomes. This has been one of the most visible and impactful outcomes of the transition at RightScale.
Agility
One of the most challenging aspect of an agile process is producing actionable roadmaps. The product roadmap must be detailed enough to enable sales when engaging with prospects and customers. Yet producing detailed roadmaps goes against the fundamental idea of quick iterations and the “learn as you go” approach promoted by an agile process.
The solution we adopted at RightScale to tackle this specific challenge is the concept of focus areas (I’ve seen other organizations refer to the same concept as seasons). A focus area identifies a new product, a new capability, or — more often — an existing functional area that is being prioritized for enhancements. The work on a focus area is time-boxed and typically anchors on one or two key features. At RightScale focus areas typically last 3 months but can be extended when implementing brand new capabilities for example. The idea is to give the team enough time to iterate in the area potentially adding value that was not thought of initially.
This is where the balance of agility vs. roadmap comes in: the product group provides the team with all the research data that led to the creation of the focus area. The team uses that data to decide on concrete features and keeps the rest of the organization informed as it makes progress. The focus areas and key features get communicated internally as part of the roadmap. Additional specifics are communicated as the work progresses when features and corresponding dates are identified. This is a rolling process: the product group presents the next focus area and the team starts providing feedback as work on the current focus area finishes. This makes it possible to identify anchoring features and to make high-level architecture and design decisions required to keep the team productive.
Sustainability
Another challenge that comes with such an iterative process is addressing the need for foundational work. Building lasting products that evolve over time together with the needs of the market requires building a set of core capabilities that can be composed together to build customer facing solutions. For example, the RightScale orchestration engine built on top of Cloud Workflow underpins products such as RightScale Self-Service and RightScale policies. Building point solutions works for a while but results in complex and heterogenous systems that are hard to maintain and extend in the long run. You know you’ve reached that point when implementing new features takes an inordinate amount of time or when the rate of defects being reported by customers requires constant attention.
System composability is key to maintaining a nimble development team that reacts quickly to market demands. As an example, it only took 6 months to build the Policies product from the ground up because the team was able to reuse existing services to implement some of the most complex parts of the system.
How can teams focused on implementing product features as quickly as possible plan and get time to implement such foundational pieces? The solution we adopted at RightScale is architecture driven teams. Around 30% of the engineers work on a team that designs, implements, deploys and operates these foundational services. These teams take requirements from Architecture. Architecture communicates constantly with Product to maintain a common vision and anticipate long term needs. This setup also helps with innovation as the architecture driven team implements new capabilities that go beyond the initial — sometimes narrow — scope identified through customers.
Wrapping Up
Companies that want to leverage the full premise of software must continuously adjust their development processes as the underlying technology evolves. Modern processes start with empowered teams that own all aspects of the development and operate independently. Such teams gather inputs from all departments in the organization and interact directly with customers. They constantly update the rest of the organization on their progress and share details on the roadmap as they become available. Product defines focus areas and provides the team with the data required to defines the final set of granular features. Architecture leads teams that focus on the foundational capabilities required to support the product driven teams and help long term sustainability.
There is obviously a lot more that goes into a modern software development process. In this blog I’ve tried to cover a few key discoveries that we made on our journey. While certainly not the only way to implement a modern development practice the points describe here are used successfully today to develop the RightScale platform (now the Flexera CMP and Optima products). I believe they provide a solid foundation on which you can build a winning execution strategy.
