Starting a Teams Transformation


Where to begin?


For the past 7 years I’ve been working on large scale transformation projects, more often my role requires me to go into development teams that are not delivering to their stakeholders expectations and fix ‘things’. A broad remit and as you can imagine, every team will have their own problems, bottlenecks, frustrations and external pressures.

I have found however a pretty standard analysis phase that I use to gather quantitative and factual data around a teams current performance. This relates to pipelines, engineering agility and team structure.

Pipelines Value Stream Map


Breaking down the teams 'route to live' via a value stream map gives me an understanding of the phases and allows me to quickly pinpoint any bottlenecks that would be affecting delivery times. It also uncovers information on the phases, the high level engineering process, any system and team dependencies that make up a release to live. 

An example diagram of a simple VSM for an application is below:



As you can see from the simple example above the E2E test runs have been highlighted as a bottleneck so this would be an area of improvement we would look at more closely. VSM maps can get quite complex and long, the above is merely to illustrate a point and is focusing only on environments and deployments. I would also recommend looking at how user stories/features flow through the map and include metrics such as lead time and cycle time. 


Engineering Agility 


When an application changes you must be confident that the changes have not broken anything else and that you can get the modified application into the hands of users as quickly as possible. This is especially true when that change solves a defect. 

When looking at engineering agility, the two key areas I focus on is Testing and Automation. For testing I look at the teams testing approach, their test coverage, the method in which they execute the tests (manual/automated) and the reporting/alerting/feedback of those tests. When looking at automation I concentrate on automated environment provisioning, IAC, test automation and how synchronized their pipelines are. Ultimately what im assessing is how far the team is from achieving Continuous Delivery.  Again I try and visualise the results after I have scored the application like in the graph below:



The above graph details a three sample applications:

  • App 1 - Has high test coverage, however little automation this would mean that changes are still labour intensive with a high manual overheard for both test execution and application deployments.
  • App 2 - Scoring in both testing and automation is high meaning that application team can get code out to end users in an highly automated way, with confidence that they have not broken it. 
  • App 3 - In my personal opinion the worst state you can be in, they have high automation around their environment provisioning but no testing, meaning they can get broken code out to their end users very quickly!. 

Team Structure and ceremonies


The final initial analysis is taking a deeper look at the team, members roles and their development process. I look to gather information around their ceremonies, their inputs and outputs and the time they allocate per sprint for each ceremony they conduct.  I have my own idea of what a 'good' agile development process is and use that as a comparison.


Depending on what information you gather, you can do something more clever than a simple data table. The above tables indicates that the team is not conducting a '3 Amigo's' session, which would indicate they are not following an BDD/ATDD approach to building software.  The key here is again is to try and map causes to symptoms, uncover a story in the data that can help us better solutionize. 

Summary


My focus on the initial phase is to engage teams and extract factual data. The conversations and interactions that I have with the team members also helps me build rapport and get an idea of how the development team members feel. It can be quite an eye opener exploring real data with team members. Observing their reactions and understanding the reasons ‘why’ the data paints the picture that it does. In these conversations you also get an idea on how to solve these issues.

This analysis is always my first port of call, it helps me understand the landscape and gives me a good foundation to start looking at the high value transformations that can be implemented to improve the team performance.

I would love to hear what others have in their toolkit, and how they approach the initial stages of a teams transformation. 



Comments

Popular posts from this blog

Android Device Automation with Calabash

Breaking the Rules, Pushing the Limits