Part II – Organizational Transformation – Challenges and Strategies

Transformation Strategy Elements and Their Priorities  

In the previous blog (Part I) we discussed organizational transformation and organizational culture as a factor that is often overlooked, yet is a factor that can greatly impact the outcome and  success of the agile transformation. But before we analyze that impact, lets briefly discuss key elements of a successful agile transformation.

Elements of Agile Transformation

There are articles and books written on this topic discussing process, business agility, change management, and technical agility. But for this blog, lets focus on a few that really matter.

Process Transformation  

• Organizing teams for continuous delivery and self-efficiency. The most popular framework to achieve this is Scrum.  In Scrum teams are organized around the ability to deliver features quickly and desired level of quality. Adoption starts with reorganizing teams into smaller groups (versus a big monolithic development organization) with right skillset mix to achieve the above mentioned  objectives – speed and quality. Changing and reorganizing teams is a disruptive process (“Change is good…you go first”),  and there will be developers that may not embrace it at first. While talking  to a  bigger group of engineers about organizing into small teams, and the notion of shared responsibilities and collaboration, we experienced more than once, push back from at the back of the room with comments such as “coders like to work alone…”as they express their disinterest. But these instances are really outliers and for most part, engineers do tend to see benefits of scrum and with proper coaching, they start embracing it.

For small companies with a simple organizational structure, the transition to Scrum can be fairly straight forward. People know each other, often they are all collocated and they are used to dealing with frequent changes, comfortable with direct communication and may already have a “just do it” attitude. 

On the other hand, for larger companies with a complex structure and equally complex processes, these changes are much more challenging and may take time to fully transform across all departments and geographical locations. But even in this case, engineers can often see the “good” in the change. They embrace it, over time they improve it and ultimately become better at it. 

• Beside teams of developers organizing in scrum teams using Bezos’ two pizza size rule^[1], next process related change that is important to highlight here, is the ability to scale Agile in big organizations. This means organizing multiple scrum teams together to continuously deliver meaningful value to customers. Hence, the concept of a Release Train may be introduced to align scrum teams and other functions (development, DevOps, test, product and program management, service, etc.) in logical grouping with shared business and technology objectives. Release train may have up to 150 developers in large organization, with multiple release trains running concurrently.  Members of a cross-functional release train should seamlessly work together without traditional organizational boundaries or impediments (or “silos”) to complete all activities necessary to deliver value continuously, fast and with quality and security built-in. Further, the set of release trains’ activities can be organized around value streams where value is a content the train is delivering.  The value stream is also a reflection on how business is aligning a key product or portfolio strategic themes delivered  to customers over period of time. By definition, a value stream may include activities across multiple release trains. 

It is obvious that scaling Agile with release trains, value streams and associated changes, may require modifications of the existing organizational models especially if they aligned around technology, architectural components or existing product components. These organizations may have developers, test engineers and other functions working on these components that alone may not be releasable customer values. This is important to remember as we will later discuss organization culture models relationship with organizational changes introduced by implementing release trains. This may require reorganizing teams around the value they would deliver to customers.

---

^[1] According to Bezos, ideal size of the team is the one that can be fed with two large pizzas 

Technical Transformation or Technical Agility 

Beside organizing teams and aligning organization around value streams where value is delivered by release trains, another element of successful transformation is technical transformation or adoption of advanced engineering practices. 

As we said earlier, the ultimate goal is to deliver valuable product increments to customers continuously (in frequent deployments), with quality and security built in. To do this, teams need to change the way they produce code. In waterfall-like models, developers will write code, pass it to test teams who will open defects for any bug they found during testing. These defects will go back to developers to fix them. When code is ready, software executables are built and provided to operation teams to deploy to a sandbox environment to do more integration testing . This process keeps going  until predefined release readiness goals are reached and software is finally ready for customer deployments by operation teams. All this takes time, promotes silos and isolates developers from software delivery process,  and ultimately from accountability for product quality.  Because it takes time and deadlines are tight, this often causes burnouts and stress conditions for people involved. 

Hence it is important that along with agile transformation, teams embrace engineering practices that sustain agile and ensures quality issues are fixed fast, when they actually happen. . This reduces turnaround time for delivering value to customers and makes developers accountable for a code quality. Some of most important technical practices teams need to learn are:

• Automated Unit Testing – Teams should adopt xUnit test framework within which developers create unit tests pretty much for each line of code they write. One of the most popular models for embracing unit testing with full code coverage is adoption of Test-Driven Development (TDD). In this model, unit tests are written prior the code that is tested. Another good extension to TDD is Behavior Driven Development (BDD) which allows automation of acceptance tests that can be considered a contract between developers, product owner and business stakeholders. Adoption of these test frameworks, requires often mindset change,  but with proper technical coaching engineers quickly see the benefits and adopt.  
• Continuous Integration (CI) – Teams need to have the ability to run fast CI builds that are triggered each time they commit their code which, if done properly, means running CI builds many times a day. Developers are encouraged to run their unit tests during these builds along with performing other analyses to discover code anomalies and security vulnerabilities. The feedback CI provides is critical. It is important developers act and fix these issues immediately, not wait for downstream testers to discover and pass information about code  issues in the form of a documented bug or defect. 
• Automated Continuous Deployment (CD) – – While each developer is running CI builds on their code and cleaning it up as they get unit test feedback, it is important that code is continuously built and tested for integration between key components of the system they are building. To do that, a means of automating environment setup and code deployment are required. These days this is often automated by adopting infrastructure as a code paired with use of cloud platform and its related services.
• Proper branching strategy –e.g.  Trunk based development. Developers tend to keep their code isolated from main or release branch in private or feature branches for a long time.  These practices prevent code integration and timely discovery of integration issues. Hence in trunk-based development developers are encouraged to integrate their code branches into the main daily (and after passing their unit tests) 
• Security analysis – There are many tools available today that help with threat modeling  and finding timely security vulnerabilities in a developer code or open source they use. But, remember these tools must be properly integrated into CI/CD pipeline and developers are must look for their feedback and be accountable to fix issues. 

To make this technical transformation happen, two main things need to be provided: coaching and a proper engineering tools ecosystem that supports developers by seamlessly automating most of the process overhead.

There are other elements of successful transformation and other technical practices, but what is described in this blog is a good starting point helping us understand transformation priorities and risks discussed in Part III blog.