How achieving the right balance of people and process can unleash the potential of your development teams.
Meet Drew, the team lead for an exciting new SaaS product in the collaboration space. The chance to work on this product was what attracted him to this company and now, after years of hustling his way up from junior developer, he’s finally in a position to unleash its potential.
But Drew isn’t feeling any of that passion or potential today. Instead, he’s sitting in front of his Zoom screen waiting for his development team to connect. As each user tile goes live, Drew can practically see the thought bubbles over their heads: Great, another meeting.
As a team lead, Drew would never admit it, but he’s feeling the same way. He straightens up, tries to look motivated, and hopes that more of the participants follow his example once their company director Jill joins.
Right on schedule, Jill hops on the call. Pressed for time, her goal is to pop in, assess the situation, deliver some necessary decisions, and move on with her busy day.
But as soon as she connects, Jill can tell that’s not how this meeting will go. The slumped posture and wandering gaze of the participants tells her that they are barely paying attention. Half of them don’t have their camera turned on—are they even present? For what feels like the millionth time, Jill wonders what the hold-up is all about. They have the tools, the processes, and the expertise. Why does she have to be involved at this point? Why can’t they just do the work?
Over the previous several months, both Drew and Jill believed that every meeting would be the last one. But at this point, they know it’s far from over. They’ll do the same things at this meeting that they always do: go over expectations, reiterate processes with some add-ons that promise to improve efficiency, wait through the crickets after they ask if anyone has any questions, and send them on their way. In two weeks, they’ll be back in the virtual conference room, doing it all over again.
Drew and Jill are experts in their field, and have a lot of passion for this product—they want to see it done right. They also know that their team has all the structure, skill, and creativity needed to execute this project successfully.
So why isn’t it happening?
Over the past 20 years, we’ve worked with a lot of people just like Drew and Jill. Tech leads, directors, individual developers—they’re all feeling this same frustration…and if you’re in software, there’s a good chance you’ve felt it, too. All the right elements are there, and so is the proof that your company can be successful. So what’s getting in the way?
The answer is actually pretty simple. But to understand it, we have to go back to where it all began.
Where It All Started: People Over Process
Back in the 90s, the software industry was struggling under its own weight. Projects were stumbling along behind schedule, burdened by inflated budgets or stalled by ridiculous attrition rates. Needless to say, this internal conflict didn’t result in successful products. Half the time, a product was already obsolete by the time it was shipped. Developers, project leaders, stakeholders, the market in general—everyone was unhappy.
In the midst of this chaos came the Agile Manifesto, offering streamlined efficiency and creative empowerment to everyone who embraced it.
Suddenly, project timelines got ahead of the rapid changes in the industry. Developers were at last free to plan out their work based on the priorities from the business, while directors could look forward to release cycles of just one to two weeks. Finally, the future that software promised seemed to really be within practical reach.
The most widely adopted Agile process was Scrum, a process that promised to be the only one developers would ever need. Based on the Agile premise that people come before process, Scrum revolutionized the industry by offering a minimal set of practices that gave project leaders the results they were looking for, while offering developers control over their work and protection from the tyranny of schedules, deadlines, and micromanagement.
At last, the software industry seemed set free to do what it came to do.
Yet here we are, 25+ years later, still deadlocked in the same old conflict between people and processes. What happened to the minimalist approach that was supposed to set us all free?
For one thing, our projects have grown a lot bigger over the past few decades. Agile processes like Scrum were designed for small teams, not for scale. While these processes gave us great collaboration and productivity back in the old paradigm, the SaaS scene is getting more competitive every day, and as a result, organizations are building platforms and comprehensive software products and services in a bid to dominate the market. The “bare bones” model has started to look a little shaky under the weight of our ambitious new projects.
The conventional fix is to support Scrum by adding on new processes, such as:
-
- Planning multiple sprints at a time, in an effort to coordinate dependencies between teams
- Long planning and requirements sessions, which require everyone on the project to participate.
- Multiple daily status meetings with individual groups to elicit feedback and establish accountability
The problem is that these additional processes and planning come at the cost of productivity and project agility. In other words, we’re coming into the same problem that Agile was supposed to fix.
It’s too easy to see this as another inevitable instance of the age-old conflict between management and workforce. The knowledge workers (UX, developers, testers) want to have lightweight processes that allow them to focus on their work. Directors (C-suite, managers, project owners) want predictability and the ability to coordinate work on different project components. Each side sees the other as the obstacle to getting their desired results.
In reality, though, they’re on the same side.
The real enemy is the same it’s always been: the tendency to put process before people. The more people we’re trying to coordinate for a project, the more processes we prescribe…but the more processes we bring in, the more difficult coordination becomes.
It’s only natural to assume that achieving ambitious results requires a lot of structure. How else do we ensure consistent quality and timely delivery? How else do we track progress and improve from one project to the next? Processes are the only way to hold people accountable to the standard of work we expect…right?
In fact, no.
The Team Is the Answer
Retrospectives have been part of Agile since the beginning. They were built into the Agile processes to give developers the ability to voice what is not working and the freedom to change it.
However, these retrospectives have been effectively smothered by our instinctive reliance on process. In many companies, the retrospective has turned into more of a therapy session–developers are voicing their frustration, but those frustrations are either not being heard, or not being treated seriously. Actionable items are not captured, followed up on, or owned.
For over two decades, people over process has been the mantra of the software industry. Yet somehow, processes are once again in the driver’s seat, while the people are hanging on for dear life. We’re doing the thing where we keep doing the same thing but expecting a new result.
Maybe we should have seen this coming. After all, when work culture functions a certain way for hundreds of years, it’s a little crazy to expect a single good idea to change it forever. There are years and years of “muscle memory” around fixing productivity by adding new processes.
But if we really want things to change, it’s time to stop treating processes as though they live outside of what can be changed. Yes, it’s been over 25 years since Agile was introduced, but even though so much has changed technology-wise, the fundamental principle of Agile—people over process—still applies. By returning the focus to teams and what they need to be effective (not the least of which is enjoying the work that they do), we can help project leaders get the results they are looking for, while also giving developers the fulfillment that they naturally desire as creative knowledge workers.
How do we know this?
Because it’s what we do every day here at Creative Mines.
As software development consultants, we specialize in bringing developers, senior leaders and stakeholders together. We understand that though these two sides often feel like they’re working against each other, they’re actually on the same team.
In fact, that single word–TEAM–is the key to bringing developers and stakeholders together.
The team is the fundamental unit of organization that does the work. It’s the piece that has fallen through the cracks in the push-pull between people and process. The team is always running up against things that slow it down: unclear requirements, dependencies on outside collaboration, and of course, too many processes.
No process is ever going to work if the team doesn’t own and adopt it as their own. But by taking the team unit as our perspective for everything we do, we can simplify processes down to their roots, eliminate inefficiencies, and reboot the creative freedom that fuels successful products.
In our next blog post, we’ll show how a simple retool of your team dynamic can lead to wins like:
- High productivity
- Quality end product
- Developers deeply enjoying what they do
- Stakeholders having the satisfaction of seeing the results they’re looking for
- Quicker decision-making
- And yes, fewer meetings
In the meantime, if you have a project that just can’t wait, reach out to us! We’re here to answer your questions, bounce around ideas, or design a customized strategy for getting your product out of gridlock and into the world. Email us at hello@creativemines.dev or call us at 906-370-8876, and let’s get to work.
