Software engineers can often find themselves working on an island, but this isn’t an effective route to success. Here’s how to build a raft, FaST, and get back on the mainland.
Working on islands isn’t what it seems. There is no piña colada in hand while you take a few calls from the cabana. Instead, you have isolated teams of highly-specialized experts, struggling to coordinate across an ocean of missed opportunity. This is what working on an island in a software engineering department is like, where silos get in the way of meaningful progress.
Having led software teams that are divided into feature teams, stream-aligned teams, and everything in between, trust me: The level of coordination involved is no vacation.
In my current role, I have been trialing Fluid Scaling Technology (FaST) to work towards meeting the evolving demands of the work we do, and create a happier, more productive engineering environment.
Traditional teams aren’t as independent as they think
Many engineering departments are built upon a network of vertically-structured feature teams, horizontally-structured component teams, platform teams, stream-aligned teams, and other siloed entities. There are specialized back end teams, front end teams, and everything in between. As James Shore states in his recent analysis of component teams, “they live in an illusion of independence.”
Separate teams think they can complete objectives without relying on others, but as initiatives grow in complexity, they require outside dependencies. This creates coordination issues, delays, and it seriously limits the scope of manageable work.
Knowledge is rarely shared between separate teams. The further they specialize, the harder it is to see the big picture. If there’s ever a piece of work that is bigger than just one small, specialized team, it rarely gets done.
Let’s say your experimentation team has the opportunity to iterate on a feature that affects a data pipeline. They can’t do that without depending on your data infrastructure team. But, because an in-depth handoff takes too much effort to get both sides aligned, the project is never fully prioritized. Instead, team leaders default to the task-master initiatives they know they can finish within their silos. This only creates more asynchronous work and keeps the important, value-based work in limbo.
To truly deliver software that matters, the question shouldn’t be, “how do we get these tasks done?” The question should be “how do we solve our biggest challenges?” Following through takes a cultural shift. It also requires optimizations made at the individual team level.
Breaking down silos with FaST
What if there was a more fluid way to organize software teams? What if we weren’t a collection of knowledge islands, but one body of shared wisdom? FaST has emerged as a new approach to bring software engineers together as a part of a larger collective, rather than smaller, independent teams. It focuses on owning the big picture, not individual specializations, and it breaks down knowledge silos to inspire a culture of shared learning and collaboration.
Teams merge
FaST starts by breaking down silos and merging cross-functional teams into a single collective.
They self-organize
On a regular cadence – ideally under a week – various specialists come together to talk about the big picture challenges they’d like to tackle which will drive business outcomes. Once these challenges are identified, team members self-organize into small, integrated groups that are fully equipped to tackle work from start to finish. If it’s for a new feature that affects the data pipeline, a data infrastructure specialist might join a product experimentation expert to work through the challenge together.
They visualize
In a FaST engineering team, visualization is a key principle for breaking down knowledge silos. Every time a FaST team comes together as a collective, progress and learnings are tracked, documented, and shared. This can be on a physical wall, or a virtual one. Leaders capture progress, but everyone is responsible for understanding what’s on the wall. This is where solutions appear, new challenges emerge, and the big picture is illuminated.
They collaborate
FaST facilitates collaboration at both the collective and self-organized team level. As work changes and learnings unfold, so does the scaling makeup of teams along the way. Dependencies rarely create holdups, because everyone is on the same page as they work. Some of the self-organized teams can choose to disband and re-form if they identify dependencies between themselves. Problem solving and creativity tends to flourish in this fluid environment.
They synchronize
After one cycle completes, a new one begins. The collective returns to synchronize on what was accomplished. Not everyone worked in the same, self-organized team, so here’s a chance to report back on key learnings. Just like with most software engineering work, new projects uncover new challenges, which then get added to the wall. In a FaST method of synchronization, there is little planning and scheduling involved to keep the greater collective on the same page.
Too much work in progress is a work against progress
To maximize utilization in traditional engineering departments, we divide and conquer. The reality is: We’re being conquered when divided. In this approach, every engineer is heads down, so they can make concurrent progress on several things at once. This assumes that the features they release actually cross the finish line every time. As we all know, there are no guarantees in software engineering. More often than not, the work continues to ensure the stability of the project and close it out. What this creates is a backlog of work in progress.
The more work in progress we create, the more interruptions occur, the longer the queuing time becomes, and the greater the dependencies grow between team members. Eventually, the jobs become impossible to finish and the work in progress becomes a “work against progress”. Imagine if you were building five houses at once and ran out of money in the process. In the end, you’d have 5 unfinished houses. What good is that? Now imagine an entire team of contractors doing the same thing on their own private islands. What you’d have are oceanfront neighborhoods without roofs on the homes.
Finish more, start less
Engineers are asked to multitask even when they can’t move forward and drop what they’re doing to meet last minute requests. The key to getting more done is by doing less. If we can decrease the work in progress, then we can increase throughput.
Frequent interruptions happen in solitude
In most circumstances, solitude lends itself to focus. However, in software engineering the more you work by yourself, the more you are liable to be interrupted. Take Pull Requests (PRs) as an example.
The PR process comes from working on islands. When you’re on your own, and making a bunch of feature changes, you eventually want someone to double check your work to ensure nothing was missed. It makes sense to increase quality by getting extra sets of eyes on things, but most likely, the person you ask for help is already buried and lacks the full context you have, so how helpful is their extra set of eyes really? And was it worthwhile to break their flow in the process?
Mob and pair programmers never break focus
Mob and pair programming, also known as ensemble programming, is a development approach where teams ideally never break their focus. Whether testing and releasing software, typically between two and five engineers working together simultaneously on a piece of work. Ownership is shared, which promotes camaraderie and prevents burnout. Plus, there’s extra sets of eyes available at all times, providing feedback in real time, which means there’s no need for a disruptive PR. This leads to fewer errors, improves code quality, and faster delivery speed. By the time teams ship, rarely do they have to roll things back and try again.
To some engineering departments, the cost associated with putting a group of engineers on one task might seem ridiculous. But, a recent study by Sardinia strongly suggests that the benefits outweigh the costs. With mob and pair programming, knowledge sharing and communication skills improve across the whole engineering department. Staffing risks are reduced, technical skills grow, and the end product is better digital products.
Pointing at problems doesn’t make them any smaller
We’ve all been in scrum meetings, attempting to measure the future against what we delivered in the past, comparing and assigning numbers to the complexity of projects in a weekly ritual we call “story pointing.”
Breaking down problems makes them disappear
Story pointing in scrum meetings just creates more tasks that don’t actually solve your problems. It’s additional effort and complexity with no measurable benefit. Rather than attempting to quantify the challenges so specifically, let’s aim to break them down into smaller, more manageable tasks. When everything is dismantled into small and equal parts, it’s easier to understand how long things take and it’s easier to build a delivery cadence and stabilize your throughput. Then, focus on the big picture, and optimize solutions that get features out to your customers as soon as possible.
The right tools help accelerate team learnings
Moving from knowledge-based work to learning-based work means empowering your teams with the right tools. Feature management platforms with measurement and learning capabilities are a must have in a FaST team’s toolkit. The best ones connect feature flags to data, so you can get real-time feedback on everything you release. They gather insights behind each feature flag and compile data in a way that’s highly visible and shareable across teams. The valuable insights captured help accelerate learnings, promote open communication that breaks down silos, and unifies decision-making based upon empirical evidence.
Collaborative environments create satisfied teams
The days of working in silos, or isolated islands, are fading away. Software engineers are realizing the power of collaboration and the immense benefits it brings. They no longer want to toil away in seclusion, but rather thrive in an environment where they can freely exchange ideas, knowledge, and expertise.
What they learn from different perspectives and technical expertise is inspiring. When they are free to collaborate in fluid teams, it sparks innovation, fosters creativity, and leads to quicker, more effective solutions.
