In Agile delivery, we often face a variety of problems, not just limited to technology but also across processes, tools, capabilities, customer constraints, ways of working, management and more. All of these things will affect the outcome of delivery, and in some cases, even lead to its failure, where distributed delivery will add more complexity to it. Therefore, how to govern the delivery effectively, improve engineering productivity and ensure there is consistency in productivity governance across projects will play a vital role in setting up teams for success. Engineering productivity and governance covers a wide range of fields. Although we can’t cover everything, we would like to put forward some ideas from a framework perspectiv
Introduce the framework
It is important to make your people aware of the reasons why you want to govern and improve engineering productivity when delivering a project. You can use the following two questions to start with the conversation:
How do you differentiate yourselves from other competitors when delivering a project?
What can you do to retain your values, make it sustainable, and even add more value to your clients when delivering a project?
People may have different answers to those questions, but we hope this could help people think differently and eventually agree on why this is important for them. Although different projects may have different situations and challenges, the ultimate goal is to ensure the success of delivery. Therefore, you will need to continuously think, review and improve engineering productivity with the aim of generating a positive impact on the delivery outcome.
Based on our years of experiment and practice of distributed delivery, we summarized our methodologies, experiences, and lessons learned into the following Engineering Productivity Governance and Improvement framework.
The framework
Overview
A framework to emphasize the value delivery via sensible default practices, measurements and capabilities following North Star goals, with the aim of creating impact and cultivating engineering culture.
At Thoughtworks, when we work on a delivery project, we strive to deliver the right values, reduce waste, seek faster feedback. We add value to our clients through continuous improvement on sensible default practices, capabilities and measurements, while cultivating our engineering culture.
Although this framework is mainly from Thoughtworks' perspective, any organization that embodies a purpose and value driven approach should be able to benefit from it as well. What you may need to think about is how to align it with your organization’s purpose and values. In particular, if you are running a distributed delivery model, aligning purpose and values will help to create a coherence for people working at different locations.
The purpose
A powerful approach of articulating the ‘why’ is to align with your organization's purpose. At Thoughtworks, our purpose is:
To create an extraordinary impact on the world through our culture and technology excellence.
This purpose is our belief and why we are here. Based on this agreement, we believe we could add value to our clients and create an engineering excellence culture in delivery through the improvement and effective governance of engineering productivity.
You will have a higher chance of success if you can connect goals to your oganizations’ purpose which could help you gain more support from the exec team. More importantly, it is a motivation for your people to achieve desired goals.
The ultimate goal
Our ultimate goal is to generate impact to our clients, which could be achieved from the following two perspectives:
Business value - what we deliver should aim to create relevant business values. Objectives and key results (OKRs) could be a way of articulating business values.
Engineering excellence and culture - we should influence our clients through a continued pursuit of engineering excellence and developing engineering culture
Our ultimate goal is derived from Thoughtworks’ purpose. You will need to think about your ultimate goal based on the purpose and vision. Business value should be an important goal to be considered given the value-driven approach has been widely recognized in Agile delivery.
The North Star
While creating business values, we use the following North Star goals as a direction to guide our delivery lifecycle:
Right values
Less waste
Faster feedback
High quality
Those North Star goals are our directions, any issues that we want to address should align with those goals. You may have different North Star goals, but the concept should remain the same. If the issue you are trying to solve doesn't align with those goals, you may need to think about why you need to solve this issue, is this issue your current priority, what is the impact to the outcome of the delivery? You can use the following relationship mapping tool to evaluate whether you are addressing the right problem, which can also help you to assess whether or not your governance process is on the right track.
This diagram maps the relationship between Sensible Default Practices, metrics and North Star goals in order to ensure right problems are addressed.
The Golden Triangle
Based on those North Star goals, we believe the following three elements of the golden triangle could help us improve engineering productivity and delivery efficiency：
Sensible Default Practices - These are our best practices and core IP, which is why we call it ‘default’, i.e. those practices are the practices being used by default in our delivery projects. The practices here are not only for the developer role, but also include best practices for other roles, e.g. BA, QA, UX, PM and more. You may have different best practices based on your context, the importance is to be aware, adapt and improve.
Measurement - You need to find a way of measuring the success, in order to assess engineering productivity, identify problems and areas for improvement. You need to use both quantitative and qualitative ways to measure the success from the outcome of delivery, practices, capabilities, security, team morale and other perspectives.
Capability - Capability here not only refers to technical capability, but also includes non-technical capability, for example tasking, estimation, communication, etc..
This diagram shows the relationship between sensible default practices, measurements and capabilities which are interrelated and need to improve continuously.
The above three elements form the golden triangle as they are interrelated. The adoption of best practices and cultivation of capabilities can make the measurements more mature. On the other hand, the outcome of measurements could be used to identify the problems when applying those best practices and areas for capability improvement. Furthermore, applying best practices relies on its corresponding capabilities, whereas uplifting capabilities could support you to better apply those practices.
How to implement the framework
A big question you may ask is about how to implement this framework. The value map below could be used to demonstrate what the ‘excellence’ looks like, in order to identify the gap between the current situation and the ‘excellence’. Once the gap is identified, you can then aim to continuously improve engineering productivity via the five principles of problem solving in Ray Dalio’s book “Principles”.
Each delivery project may have its own process. The value map below is an example of demonstrating what you could do to improve engineering productivity at the coding stage, where the green block represents the step in the development lifecycle.
This value map demonstrates what you could do to improve engineering productivity at the coding stage, from the perspective of sensible default practices, measurements and capabilities.
If you drill down to a specific development step, you can find its desired Software Development Sensible Default Practices in the pink block, relevant metrics in the dark blue box, and capabilities that can support the development step in the purple box. Although this value map is designed from a developer's perspective, you can use the same pattern to design value maps for other roles. Different teams may have different value maps even for the same role, but we hope the pattern and some level of content could be consistent, especially for those deemed as default or standard practices, metrics or capabilities, so that your distinctive values or secret sauce can be inherited.
According to Ray Dalio’s five Principles, once the goal is defined, you will need to assess the team’s current situation, identify the problems and gaps, then develop an improvement plan and take actions. Some teams may start with a low bar, some may have done well already, but it doesn’t mean the low-bar team has little chance to catch up and the ‘good’ team has nothing to improve. What you want to see is the journey of continuous improvement and the outcome of each team. The diagram below is an example of demonstrating the improvement over a quarter. Although the improvement is not significant and the metric is still yellow, this is exactly what you want to see the change. The low-bar team can have its own pace to improve based on the priority. What’s important is to continuously improve and ensure that what you are changing is always aiming for North Star goals, whereas small incremental improvements are totally acceptable. The good team may already be close to the goals, but it doesn’t mean you have achieved the level of excellence. Even though you have achieved excellence, you can still think about what your next goal is, whether or not you can create new values via innovation.
This diagram is an example of demonstrating an improvement of code quality measures over a quarter
Measures of success
How to assure you are doing right things and doing things right? Although delivering values might be your ultimate goal and measuring delivered client values could help you understand whether or not the goal is achieved, you should consider other measurements to evaluate the improvement of engineering productivity, including but not limited to:
Outcome of North Star goals - you need to find relevant metrics to measure the quality, speed of delivery and feedback, waste of cost, resources and processes, in order to ensure you are doing right things.
Capability improvement - you can use radar chart to represent desired and current capabilities, which can easily tell how successful you are and where to improve.
Team engagement - you can use a combination of quantitative and qualitative questions to assess team’s engagement which is an important part of engineering productivity.
Maturity of sensible default practices - you need to understand the team's awareness of default practices, how well they are being adopted and whether the adoption is consistent over time, the ability of continuous improvement, etc.
- Outcome of leading/lagging metrics - monitoring and analyzing the outcome of leading/lagging metrics is important to understand the effectiveness and productivity of the delivery, which could inform further actions.
- Innovative ideas - while following standards or defaults, each team should be encouraged to think about what else they could do to improve, is there any innovative pattern, capability or metric that can be assessed, experimented and adopted
This diagrams summaries different ways of measuring the improvement of engineering productivity with the aim of ensuring that you are doing right things and doing things right.
Summary
We hope this framework can support you to have a level of consensus on the improvement and governance of engineering productivity in Agile delivery, more importantly finding a practical way of implementing this framework and forming relevant governance programs. Although distributed Agile delivery creates more challenges than Agile delivery in general, this framework offers you some ideas that you could leverage to overcome those challenges based on our experience.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
