Dev-ineOps: The Design and Development Operations You Were Looking For

If teams aren’t purposeful about the way they work together, the default is always naturally going to be waterfall.

By: Trish Lamanna

(Watch the video of this content presented at the TNW Couch Conference from March 2020 and the follow up article here.)

When it comes to building the best digital products and experiences, design and development teams need to work together in way that allows them to drive meaningful impact. A team that works together cross-functionally will drive exponentially more value than a single domain ever can. However many organizations struggle with putting this insight into practice. Why is it so hard to get development and design to work together? There’s a few reasons. For starters:

Design was never taught to be Agile and agile wasn’t designed for Designers.

You can’t tell a designer to be agile with development and walk away, especially with a domain like design that was never taught to be agile, nor was agile designed for it to be. Designers are commonly taught in design school to solve for all problems today, tomorrow and in the future, which leads to a need to achieve perfection before handing anything off to development. Anything less means a loss of marks and credibility. This paradigm leads to immense churn in solving for the wrong problems and a huge gap in the learnings that iteration will bring to teams.

If teams aren’t purposeful about the way they work together, the default is going to be waterfall.

Quick iterations and pivoting quickly are natural to how development works. You are not penalized for making mistakes where in design school, mistakes mean costs. However the agile system embraces the ability for rapid change. There is a disconnect between the dev and design paradigms that leads to great friction when building digital products and experiences. Considering the teams are meant to be building the same product, they are often treated as two different delivery processes. When the system has us set up to fail, fail is what they will do.

“…stop looking for who’s to blame, instead start asking, ‘What is the system?’. If you want to understand the deepest malfunctions of systems, pay attention to the rules.” — Donella Meadows, Thinking in Systems (2008)

If we can be purposeful about how we operationalize development and design teams, and if operations are just another type of system, what steps would we take to operationalize for the outcomes we want to see emerge?

Operationalizing for outcomes

The definition of a system is a set of rules, an arrangement of things, or a group of related things that work toward a common goal. Systems require purposeful definition, and operations enable outcomes we wish to see. On our teams we’re operationalizing for:

• Cross-functionality between all domains in design, technology and business
• Highly performant, self organizing teams with minimal resources
• Highly predictable delivery velocities and organizational transparency

Once we know what kind of outcomes we want to see be produced out of our system, we need to think about what our rules are to support and enable them. This is where communication, collaboration and co-creation takes centre stage. These are the rules that help us achieve our outcomes, but we still need to go a step further with our implementation of the rules. What does communication, collaboration and co-creation look like operationalized?

The answer to that question will be different for any one person or company reading this. Every problem, project, and context is different, and there are no silver bullets. In this article I will be outlining my experience in solving these problems based on real examples. However the recommendations I outline are not meant to be taken as gospel. Instead, they should act as a springboard for discussions with your own stakeholders around what you need in order to enable the big three C’s within your organization. So let’s take a look at some approaches we have taken at Rangle in the past based on team size and project scale.

Size matters

Before any project begins, it starts because a problem needs solving. For design systems, the problem started off as a misalignment between design and development teams. For proof-of-concept apps, the problem started off as a bet on an unmet need in the market. The project itself is often a bet made on a potential solution to the problem, that may or may not be the real problem but that’s a different article for a different day (read more my article on the banality of innovation here). The solutions to these two problems as an example, vary in size and would require different sized teams, different seniority levels and different ways of working to address them.

Here are some contextual examples of t-shirt sized solutions to digital problems:

Small Sized Problems

Problem: Ongoing content improvements to a website

Needs: Small team to leverage and build on existing CMS and design system to produce pages with low cycle time

Team composition: 0–1 sr. producers : 1 sr. poly skilled designer : 2 sr. developers : 1 sr. quality analyst

• A poly skilled designer is someone who feels comfortable solving both user experience and visual design problems.
• You want to use more senior team members for smaller engagements and projects. This allows for minimal oversight required, less risk over all for quality and enables more possibilities for a secure solution foundation.

Team approach: Swarmed problem solving

• Swarmed problem solving is when 5 or less direct team members solve problems and make decisions together, because they have a deep shared team understanding of the project context in real time.

Division of work: 1 track — 1 team

• A track represents a line of work being completed, if the team is swarming problems, then there are no divisible tracks.

Medium Sized Problems

Problem: An unmet need in the market for an app that allows you to control a medical device

Needs: To design and build a functional MVP for an app

Team composition: 1–2 sr. producers : 1–2 sr. polyskilled designers : 5 int.-sr. developers : 1 sr. quality analyst

• For medium sized engagements, enablement teams should skew more senior, but there is some opportunity to grow intermediate and junior team members being placed on medium sized teams

Team approach: Semi-swarmed track team problem solving

• Semi-swarmed problem solving is when two tracks of the same team meet periodically throughout the week to solve problems together, and execute the solutions separately according to their domain.

Division of work: 2 tracks — 1 team

• Design and development will be solving their own problems in their own tracks of work, but will come together and align on problem solving and sharing their work in progress
• There is only one team devoted to solving one problem

Large Sized Problems

Problem: Misalignment between design and technology product teams

Needs: A Design System MVP with a documentation site

Team composition: 2–3 int.-sr. producers : 2–4 jr.-sr. UX designers : 2–4 jr.-sr. VD designers : 10 jr.-sr. developers : 2–3 quality analysts

• Large problems are a good opportunity to pair juniors with seniors to train them up
• The enablement team seeks to maintain delivery quality and project oversight

Team approach: Tiered tracks problem solving

• Tiered problem solving works best with large teams solving segments of a larger problem. There are repeatable scheduled touch points between tracks to allow for feedback and communication to flow freely.

Division of work: 3+ Teams: Enablement team + Core team 1 + Core team 2 etc. / 3+ Tracks: UX + VD + Technology etc.

• The team is big enough that there are different core teams composed of multiple disciplines trying to solve different parts of the same problem that are dependent on each other. Coordination becomes key and senior team members will become an enablement team that attempts to look ahead and unblocks the core teams before issues arise

How to communicate: What’s your team approach?

When I say communicate, I don’t mean slack or other ways of transferring messages. I mean what’s the plan of attack for solving problems? This will influence how teams make decisions, the pace at which they distribute information and pass on feedback between disciplines.

Small sized problems: Swarmed team approach

At the small to medium end of the spectrum, swarm team models are highly effective and the need for structure is very loose. Typically five or less direct team members are solving problems and making decisions together, because they have a shared team context. They can have real time design sessions, code reviews and design quality assessments. The team is able to move swiftly because there is a lower likelihood for rework later since the whole team is involved in every conversation as a voice that contributes to the complete throughput of problem solving. This type of team communication requires the highest level of enablement and trust from stakeholders, as the deep context they have allows them to build, measure and learn relentlessly. They are able to make quick decisions, gather informed data and insights, which allow them to figure out what needs to get done next and quickly.

Medium sized problems: Semi-swarmed team approach

The larger teams become, the more tired their pacing becomes, and communication will require purposeful and planned weekly touch-points where the team can come together to problem solve and share work in progress which I will go over below. For medium sized teams, a semi-swarmed model starts to make more sense as more members are included on the team, forming a divide between enablement and core. The enablement is meant to be looking ahead on the problem so that their work can inform and be informed by the core team.

Large sized problems: Tiered team approach

For larger teams, a tiered approach allows for tracks to be spaced out by a per track, providing some breathing room in between the flow of their artifacts. This enables each track to take small bites out of big problems. However the tracks are making sure to have touch points for getting rapid feedback on whether or not the team is going in the right direction, and surface any dependencies that will be coming down the line.

Here’s a breakdown example of what this kind of tiered system looks like during a typical sprint cycle:

The above chart is meant to demonstrate a typical week for how dev and design will overlap with one another in a sprint. The exact moments of collaboration is employed between dev and design are exemplified by the literal and metaphorical feedback loops in the chart. The labels on top of the chart are meant to give you a suggested structure for the swimlanes in your JIRA board, as a ticket will move through each lane to spell out the status of the work at any point in time. If a ticket is grabbed from the backlog, moved to in progress, and hits its first review cycle with the internal team approximately in the middle of the week. But we may be getting a head of our selves. What are these events during the sprint cycle and why are they helpful?

How to collaborate: What are your rituals?

As the size of your team grows, the need to have weekly repeatable rituals to connect, share work in progress and problem solve becomes essential for multiple reasons. Working transparently across tracks that allow teammates to see what you’re working on so that they can provide input and feedback, allows everyone to share the same narrative, and feel like they have contributed to the solution together. An added benefit of shared ownership around solutions is that each team member shares a sense of ownership to seeing the solution move in the right direction. When stakeholders ask questions about why certain decisions were made, each and every team member can answer the question in the same way because they helped make them.

Ritual: Weekly Bet Review

A weekly bet review is a less formal type of sprint planning that allows us to review the data and insights on features we launched, to see what we can learn and how it will inform the next week of work.

When the team is swarming problems together, the need for structure is very loose, because they are constantly in contact and communicating about the problems they are trying to solve. A simple kanban board acts as the central repository for the team to capture ideas, enhancements and bugs that come up when making over all bets to drive impact. This looseness is purposeful to allow for unknowns to come up and take priority as we learn more about the data that comes in based on the bets we made with features we built. When we observe how our analytics are performing, it can push us into a direction we were not anticipating, but needs further support and enhancement. This way when tickets land in the “review” category, it’s used as an agenda item for the weekly bet review meeting that allows us to review what we’ve learned and how it can inform the next week of work to drive even more impact.

Ritual: Weekly internal team review

These meetings are meant for the design team to show work in progress in order to source further feedback and insights from the rest of the team. This review will include not only design and development, but also any other relevant parties not limited to your scrum team that should be involved in enabling the team to solve problems. I like to include Product Management and BQA in all internal reviews to ensure the entire scrum team are actors of the solution together, and collective owners of the result. Excellent feedback comes from these meetings and great ideas will come from anywhere. These feedback meetings are also excellent opportunities to include external consultants to the scrum team, like getting a legal, security or privacy eye on more sensitive projects that include financial or medical applications.

Ritual: Weekly PO touchpoint for gutcheck

Once we have reviewed the work in progress with our internal team, we have achieved internal alignment so that when we bring our work in progress to show our PO, it has been vetted and verified that the work being shown is technically achievable. In this feedback cycle with our PO, this also gives them an opportunity to feel included in the solution, where work is being shown early, lacking polish, somewhat uncomfortably so. This requires a very specific mindset to get familiar with, one that is comfortable being uncomfortable by saying “I don’t know” and “what do you know about the problem that I’m not seeing?” while unsolved problems lay on the table. It gives everyone an opportunity to own the solution, have their voice heard, and create more robust solutions to complex problems.

Ritual: Demo

By the time the weekly demo comes around, where design and development showcase the artifacts they have been working on during the sprint, the design work being shown has been seen multiple times in multiple iterations throughout the week. Minimal feedback will come in since it’s already been captured so early and so often from the beginning of the sprint cycle, and everything being reviewed is a final wrap up on work being reviewed and talked about all week long.

How to co-create: How does your work flow?

Now that we’re communicating, collaborating, and tickets are flowing what’s the deal with co-creating? To me, I define this as the connective tissue between all three, that shows how we’re pulling the results of collaboration and communication into reality. How is the team dividing the work up and breaking down tasks in ways that dependencies are informing and enabling each other? The answer to this will be highly contextual, as we can see in the examples. But remember, the creation of artifacts is never actually the goal, the goal is any activity that will help inform a conversation to best evolve the artifacts in the right direction.

Small sized problems: Swarmed marketing website optimization

In this example, we can see that the team members are tackling things they are passionate about which relate to each other, either presently or in the future. If a page on a website needs to go up quickly, then there’s a way the swarm team can start to iterate on it as more information becomes available. With a fully functional CMS and design system, a developer with a keen sense of the shared context can immediately start putting together their best assumptions on what a good first past would look like, freeing up the designer to look more forward on the best ways to tell a more complete story on the page, or to design better visuals for things that don’t exist yet. By moving quickly, pages can begin to generate valuable behavioural data that can be measured against, and will inform the best way to tell a better story.

Medium sized problems: Semi-swarmed app design

In this example, the designer is pulling in development at critical junction points for making solution decisions in the experience layer of the project. They are identifying high level user journeys on a whiteboard together which will allow them to then separate to flush out the high level thinking they did together. Designers will begin to produce wireframes while developers work on getting their environment set up and the architecture needed to best support the solution they defined together. The next time they discuss work in progress again is to review some proposals for wireframes that get verified for functionality by the dev team. The teams are always informed on what’s happening, even though the flow of their artifacts is staggered. The key is that they solve problems together, and execute separately.

Large sized problems: Tiered design system component production

In this example, we are looking at a chart that outlines how components are being fed into development late in a design system project. You can see that design is working two weeks ahead of development because this is a large team that requires a lot of coordination to keep both teams producing smoothly without delay. We can see that design has produced pages with components ready to be defined in one week, and on the following week begin to define exactly what those components are. As design continues to move on to their third week where they begin to design all the added complexity that comes with fully defining components, like their variations and interaction states, development was able to get started laying the technical foundation with the intitial details they were provided on what components they were to start with. Each step in the process is meant to do two thigns: make sure design has enough time to come up with the details that development will need, while making sure to give development something to start on while design continues on slightly ahead of them.

The outcomes

When we’re patient, calm and open to learning through the experiences of others, innovation makes a jumps to light speed. The list of outcomes from working in these ways have large emotional benefits along with tangible client benefits. When the whole team feels like they are working together harmoniously, there’s nothing that can get in the way of a highly performant team. Some of the outcomes I have experienced working on these variously operationalized teams over the years include:

We solved problems as a cross-functional unit

• I was taught how to run the development branches locally
• Development was empowered and learned how to spot UX improvements

We became incredibly self-organized

• We eliminated the need for a delivery manager on some projects because we knew how to work together, saving our clients money
• We understood how to unblock each other, get ready for demos, and plan and refine our JIRA board

Our velocity was like clock work

• We delivered in predictable weekly sprints at maintainable speeds without any burnout or surprises
• Our work was properly socialized with minimal feedback in reviews
• Each person had the same understanding for what was happening and why

Dev-ineOps in summary

There’s a lot to unpack here which was the key motivating factor in me writing this article. Ultimately you will need to experiment and find what works for you and your team. We need to consistently be skeptical towards ourselves and constantly ask what outcomes we want to see and how to enable them through your approach, rituals and workflows.

Coordinating different disciplines to drive innovation and problem solving is a big hairy problem that requires friction, patience, perseverance and a relentless willingness to change (read more about working with vulnerability here.) We can’t be so quick to isolate ourselves at our desks to continue doing the things we always did. Newer problems with new contexts will require you constantly reimagine a new way to work with your team, pooling collective intelligence to produce the most effective ways to move value forward. If you are not seeing your teams drive the value you would hope, you need to define the rules and operations of the system they work in, in order to enable outcomes you want to see.

Above all else, we must consistently learn through the experiences of others, and bring together a wide diversity of perspectives to understand if the system your team is operating within is enabling the best outcomes you want to see on your teams. The struggle is real, and if you’re uncomfortable then you are doing it right.

“Growth and comfort do not coexist.” Ginni Rometty, IBM CEO.

(Watch the video of this content presented at the TNW Couch Conference from March 2020 and the follow up article here)

Originally published at https://himynameistrish.medium.com on January 13, 2021.