Shifting Left to a T-shaped Team
What’s going on in this picture?
On the left, we have a developer. On the right? A tester. Witness a duo in flow.
They are working together in a mob programming session to write test automation code for a story that was “completed” downstream. The developer is getting a lesson on how test automation works within his team and the products they support from his co-creator (who happens to carry the label “SDET”). Opacity is decreasing!
What you can’t see or hear, what’s off-screen, is the rest of the team offering advice or listening attentively as their turn to drive or navigate the mob is about to come up. This is a central part of the mob programming technique where everyone crowds around a single laptop plugged into a large display and takes turns writing code and tests.
Mob programming creates an environment where skills transfer can happen. It’s something teams may do periodically or even full time. It is a weird idea. It’s counter-intuitive to the productivity-focused people (i.e. most of us). That’s OK. Just try it and you’ll probably come around to the idea that flow beats multitasking every time. I'll have more to say on this in a later post.
How did we get there?
As part of our dojo approach, we create a skills matrix for the team coming in to a 6-week challenge. We open the process by defining the term “T-shaped” and asking teams what becoming T-shaped mean to them in their context.
A T-shaped individual is often described as a “generalizing specialist.” They are someone capable of a lot of the typical duties any individual on a given team would need to perform. Full stack also works, if you want a more aspirational (or aggressive) synonym.
In the case of this team, calling themselves “Free Folk” in the dojo as the “Game of Thrones” series finale was upon us at the time, developers identified an interest in learning more about the end-to-end testing toolchain. Aside: the word “Free” comes from the team’s understanding that their dojo challenge is theirs to direct.
The red columns show you the developer stack (column one and two) and the SDET/tester stack (column three). This team has an opportunity to become more full stack. I see pairing opportunities!
In the dojo, we believe highly social and collaborative teams create T-shaped individuals. That is, the team needs to be self-sufficient and autonomous before the conditions for things like cross-training and co-coaching can really make a difference. Step one: eliminate external silos. Step two: remove internal silos.
SHIFTING LEFT BY DELETING INTERNAL QUEUES
Another term we see more and more these days is “shift left.” It originally comes from the testing world and boils down to something like “test earlier and more often in the development process.” This can be a shakeup to traditional, more waterfall testing approaches where QA sits as a kind of bottleneck to delivery at the end of a group’s pipeline waiting to inject defects as backflow in the system.
A cool thing about Free Folk: they were very transparent in sharing and explaining their current process. This is another key aspect of the dojo; you have experienced coaches to provide suggestions on subtle tweaks that could help the team accomplish their goals. In this case we suggested deleting internal handoffs and pairing through story delivery.
A cursory look at their sprint board in Jira revealed a number of wait states internal to the team:
We had a brief discussion about value streams and wait states and the waste of context switching (another post for another day) which lead to a consensus: let’s try collapsing these activities into one state within their pipeline. This means that they may end up pairing developer and SDET so every story can be worked as a vertical stack in a single pipeline that looks like this:
FOCUS AND COURAGE
Having a goal in mind is important.
"Free Folk” identified several goals to focus on in their dojo challenge, two of which lead us to the experiment of deleting wait states and trying mobbing and pairing:
Improving team dynamics and overall agility.
Become more T-shaped individuals.
David Hussman used a quote in his e-mail signature, "if you don't know where you are going, it's easy to iteratively not get there." Checking on what you're doing and experimenting with how you're doing it helps your team understand if a given practice yields an intended outcome. In this sense, the dojo model differs very much from classical teacher-student training with lectures and labs. We lead with identifying target outcomes and only then select the practices and tools we believe will help us get there.
We try not to do a lot of selling in the dojo. Challenge teams identify goals based on discussion and common understanding we help to bring to the fore. As coaches we are there to offer up suggestions for things we've had success with within the past — practices we feel comfortable teaching, coaching, and demonstrating. But it's the team's choice. The team sets its goals through a series of facilitated events that bring strengths and weaknesses into a shared light. Only then does the coaching begin.
The courage it takes to try new practices should not go unmentioned. I mentioned mob programming seems counter-intuitive at first. Propositions such as that can create friction against our internal instincts and conditioning toward personal productivity.
We propose some radical practices in the dojo, some seem bizarre at first (we ALL write this ONE piece of code) or even slightly scary (EVERYONE IS LOOKING AT ME TYPE). This is where courage comes into play. It takes time and reserved judgment to objectively decide if a practice that seems strange at first isn't for you or your situation. The courage comes in trying it before you reject it on principle alone. That's a good reason we choose longer periods of time for dojo challenges (4-8 weeks); it gives a team time to find the value in the practice for themselves, develop comfort, and adapt it to their workflow.
HERE TO HELP
Your dojo coach should always have your back. We are there to work with you side-by-side. We pre-negotiate delivery commitments and capacity down so we have the time for this kind of learning and experimentation. You will also see us suggest and fail in our own experiments and move on to the next one.
It's nice when everything lines up like this. My hunch is that these experiments, with this team, will open up new possibilities for their workflow, a workflow they're making their own. This team agency is one of the common and great meta-outcomes a dojo can help promote.