Transformation Priorities
We talked in Part II of this blog series about elements of agile transformation with a focus on two main initiatives: process and technical agility. We laid out some ideas and details to consider and to understand approaches to scaling. But one question is still not answered – in what order of priority do you tackle these initiatives? Does it even matter?
There are a lot of changes in the “trenches”, at the engineering level with adoption of technical practices, changing how we build, test and deploy the code. And at the time these changes are happening, the organization can be changing to support release trains, engineers are moved around, and new teams are formed. By doing so, release trains may start breaking up existing organizational entities managed by directors and executives.
Let’s look into some scenarios, link them to organizational culture types and discuss outcomes that we may expect, at least based on our humble experiences.
Process Changes as Higher Priority
In this scenario, priority is given to process transformation over technical transformation to align engineers around scrum teams and form release trains. This obviously requires lot of preparation at the leadership and executive level as existing organizational entities and silos are broken. All this is done while teams and leadership still have a commitment to the business and customers. For example, we can’t stop on these promises while reorganizing in an effort of creating a better delivery model. This can be challenging and creates a lot of stress and potential burnout. Developers are under the gun to deliver, fix issues, deal with escalations, and yet the world around them is changing.
At the leadership level, this can start creating “antibodies” and “non-believers”. Reasons for this could range from just not understanding how breaking established organizational models will create better value, to extreme situations where it may even be political. To understand the latter, we need to reference our Part I blog where we discussed Westrum’s organizational culture model where the first two models mentioned are power-oriented (pathological) and rule-oriented (bureaucratic).
Both models are basically based on a siloed mentality with often unhealthy relationships where either information is withheld, collaboration is low, or scapegoating is present. With a rule-oriented organization, each organization protects its own “turf”, where they have their own rules and any attempt for cooperation means others need to adopt those rules which may create friction.
Leaders in these types of cultural environments often push back on changes since their “turf” is changing, and the rules and processes they created are not valid anymore. In some cases, some leaders may see breaking up existing teams as a loss of power and control. With this, they become demotivated or even they challenge process changes as they don’t see evidence of immediate positive impact on product quality or time-to-market.
So executing big organizational changes first, changes which may not provide immediate tangible and measurable results, have some risks and may result with “antibodies” within leadership and teams themselves that may slow or sabotage the transformation. Thus, it becomes important to have the right strategy defined to turn these into forerunners of change.
In our experience we also see the HiPPO [1] effect emerging in these organizational cultures with top engineering leaders with authorities giving up on transformation efforts and falling back to old practices for doing business, which in return puts the company behind against the competition and the market pace.
Technical Agility as Higher Priority
In this scenario priority is given to technical transformation over big processes and organizational transformation forming release trains and values teams. Just to make it clear – we are not stating that process transformation is not done, but just that effort and energy is first put into work on “low hanging fruit” – fixing code quality and improving delivery capabilities. In this approach, the organization recognizes the existing technical challenges, long release cycle, or inadequate testing and agree on prioritizing these challenges first before doing bigger organizational changes. In this approach agile and technical coaches and DevOps engineers are typically hired to drive most of technical transformation:
- Agile coaches will start helping teams embrace Scrum, help them understand how to break problems into smaller increments and how to deal with flow and apply lean principles. They will help limit work in progress (WiP) to allow a percentage of the capacity to address technical debt such as manual testing, complex branching, or slow, infrequent builds, to name some.
- Technical coaches will pair with developers and help them start refactoring code and teach them how to embrace proper unit testing and advanced methods such as TDD and BDD frameworks for example. They will examine their branching strategies and teach how to move from long lived isolated branches to a more trunk-based model with CI and daily merges.
- DevOps engineers will start helping with a tools ecosystem, help automate build and release processes, and help with environments setup automation to enable continuous code integrations and deployments.
Above are typical examples of technical transformations which, when combined and well executed, will start demonstrating evidence of continuous deployment capabilities improvement.
In order to see the evidence of progress, monitor the changes and make sure to address any negative trends of teams falling back to old practices, a set of engineering metrics unified across teams must be established. These metrics mainly provide answers to two key questions:
- What does my code quality look like? The expectation is to see positive trends with regards to defect reduction, security issue reduction, increased unit test code coverage, and increase overall test automation.
- How well are my teams transforming? This means teams embrace fast CI/CD with a reduction in build-cycle-time and increased number of builds, a positive trend with regards to pass/failed builds, story-cycle-time shows positive trends and so on.
It becomes almost obvious that with proper adoption of technical practices along with coaching and servant leadership support to ensure teams have what they need, then positive results of the transformation become very measurable quickly. Ideally, key metrics are automated and updated on a daily basis (ideally by each integration build run) and displayed and visible within team spaces.
Conclusion
We looked into two prioritization cases, one where priority is given to organizational changes over adopting technical practices and fixing teams first. There is a risk with this approach, if an organization’s culture is power or rule oriented. While organizational changes are important to set the organization for success long term, they are quite disruptive for leaders and engineers and there is no immediate return on investment – by changing the organization we don’t improve code quality or time-to-market immediately. In this scenario, it is easy to see that people in doubt will become vocal and undermine the efforts and in extreme cases, division can be so deep that transformation efforts may fail.
However, when we put priority on technical transformation first, and staggering organizational changes until we start seeing benefits of technical practices and DevOps we put in place, we are minimizing risks of disagreement and friction. Those potential non-believers or antibodies will not have arguments if we start seeing better code quality, more automation, less security issues, reduction in delivery cycle time and happy teams. Once we start seeing an indication of these key benefits (metrics are so important here), we can start executing organizational changes to set scrum teams around common goals, create release trains and focus on delivering value faster to customers. We focused these recommendations for organizations that may have experienced symptoms of those two Westrum’s cultural models, i.e., power or rule oriented. However, if an organization is supporting a generative culture with good information flow, high collaboration, and with servant leaders focused on eliminating impediments for teams, then transformation can be much easier to execute. These organizations see transformation as a business change and not just an engineering experiment.
[1] Highest Paid Person’s Opinion
