Mutual Agile Client-Dev Teams

While this is not strictly a Structures of Work post, it is a relevant post given my current gig as an Enterprise Agile Coach at EnormoBank.

In an Enterprise Agile Transformation each Agile team has several clients, most of which are other Agile teams within the organization. Perhaps they are within the same segment of the org, and maybe you are lucky and break the silos an work with Agile teams in other areas — if so congratulations — but in any case what that means is that at some point you are going to have an Agile Dev team working for you.

As any dev team member knows, the success of your work is relative to the success of the way things ran before you started working using Agile. Your client team might remain stuck in the waterfall days, the command-and-control days, and therefore not really understand the value of quickly closing feedback loops, or providing tech-agnostic descriptions of the business process that they want to improve, or defining done in testable ways. But your team works through all that with Agile to make the client’s lives better even though they are terrible Agile clients.

What if they were not terrible Agile clients though? I’ve taught many business teams how to make full use of the Agile development teams that the IT org has made available to them, and they become really good at all of the skills listed above. Then a 2-week sprint becomes a real shared moment of throughput and engagement, with all feedback loops closed quickly, all results evaluated in business and not in technical terms, and with permanent process improvements proven with unit test automation rather than simply smiles and emotional good vibes.

In enterprise transformations, where Agile Teams are Dev teams by day and Client teams by night, the skills to behave properly in relation to other Agile teams become even more profoundly effective because as a Client team with insider knowledge of Agile you can accelerate the Dev team’s processes exponentially.

So for instance: your team in Dev mode refactors business logic code to separate data movement and storage concerns (aka “the plumbing”) from data transformation and algorithmic concerns (aka “the business”). The business benefit is that eventually your company can focus their development efforts strictly on the business-facing data processing, and outsource the plumbing to a systems integrator for far less money.

One of your issues is that for every module that you refactor, you have to create a test set for the business functionality and a test set for the plumbing functionality, in order to ensure that neither has been broken by your refactoring efforts. The business functions are fairly straightforward to assess but the plumbing functions are really quite difficult to parse. Not only does the plumbing have structural criteria to meet, it has longevity criteria, security criteria, timing criteria… none of which are documented and so must be inferred. What your team needs is help from an Agile Data Plumbing Criteria Determination team, an elite squad of mindreaders who can tell what the Original Coders were trying to do when they extruded their spaghetti in the first place, and who can craft valid and repeatable tests for plumbing acceptance criteria for any module that you give them.

Here you are, an Agile Dev Team, enlisting support from another Agile Dev Team. In this context, you are an Agile Client Team, and have certain obvious responsibilities towards your Agile Dev Team. The more skillfully you discharge these duties the faster everyone’s work will go.

First you must agree with your counterpart team what constitutes success in your eyes. In this case, let’s say that success means delivering a suite of plumbing-centric TDD assertions which your team can use to steer the refactoring of the module in question. The faster they can deliver the full suite to you, the faster you can use it to steer your coding. Your criteria are: it must be in Python, it must be loaded into the Jenkins project for this module, it must pass when the old code is run and fail when the refactoring begins. Also a complete state diagram of the plumbing, abstracted from the data itself, must be delivered so that your team can design the refactoring effort to replicate it outside of the business processing.

Next your teams must establish a cadence for interaction, conduct a series of MVP experiments and home in on the correct deliverable suite. Then, your team must begin consuming the deliverables from the counterpart Agile Dev Team and complete their own work.

How well is your Agile Team trained and coached to behave as a Client towards other Dev Teams? How quickly do you close feedback loops with them, establish cadence, provide tech-agnostic requirements, and assist them with their work when necessary?

Teams that behave this way towards each other are Agile Teams with simultaneous Dev and Client roles, often working on behalf of one another in turns from epic to epic or sprint to sprint. That’s why I propose to call them Mutual Agile Client-Dev Teams. It will be a rare team that never has to act as another team’s client.