The Agile Preconditions for Full-Stack Development Teams

I spend a lot of time talking about the underlying preconditions for Agile. Because of my background in project management, process, and org design. I usually talk about the necessary preconditions from that angle. I beat the drum pretty hard on the idea of teams, backlogs, and working tested product increments as the fundamental preconditions to do Scrum well.

That said, my education is in computer science, I’ve been working in the software industry for the past 30 years or so. I think I understand a lot of about how systems are architected, and how good code is written. I say things in front of really smart developers and don’t get thrown out the door. But because I’m not a hands-on keyboard guy, I tend to keep my mouth shut where I don’t consider myself a deep expert. I know just enough to be dangerous.

Keeping that in mind, I want to talk about a conversation I had last week.

I was talking to a group of leaders, leaders that were super deep, knew their product backward and forward, and very committed to doing Agile well. We were talking about the idea of full-stack developers. Feature teams that could work anywhere in the code.

It wasn’t really working for them. They were struggling to make and meet commitments. They were struggling to keep the code defect-free. They were having a hard time knowing when things were broken. They were struggling to see why it wasn’t working.

Let’s look at why it’s not working.

The Ideal Full-Stack Team in Agile

An ideal Agile team would be relatively small. Maybe five to seven people. It would have everyone and everything necessary to produce a working tested increment of software on regular intervals. And it would have close contact with customers and be able to get rapid feedback. That’s what the ideal team would need from a management perspective.

But what do they need from a technical perspective?

Again, not a hardcore technical guy here, but I think they’d want to have sufficient unit test coverage. They might want to have the ability to rapidly do a build. They would want to deliver frequently into that build and instantly be able to know if anything had broken. They would want frequent customer feedback.

That is a HUGE part of what makes Agile teams faster. They can move fast and furiously through the code because they always know if they broke something. They always know that, if they refactor something, they didn’t break anything else. That allows them to keep the code clean, defect-free, and well-architected.

Now imagine a full-stack team moving fast and furiously across the code. Working on small user stories and committing often. Since we have shared code ownership, we might even imagine we have multiple teams making changes into said codebase simultaneously.

Now, imagine that team doesn’t have sufficient test coverage. Imagine they don’t have unit tests. Imagine they can’t do frequent builds. Imagine they can’t continuously integrate and deploy. What if they can’t get rapid feedback from the customers? What if the testers are on a separate team? Maybe they don’t see it as their responsibility to test at all. Maybe that is the responsibility of the QA team. What would be the result?

It’s not just the management practices of Scrum that have preconditions. The technical practices (of let’s say XP) have preconditions too. You can’t move fast and break things if you can’t tell it’s broken and can’t fix it immediately. You can’t have shared code ownership and multiple feature teams working simultaneously if you can’t prevent them from stepping all over each other.

So, I want to encourage everyone to not just understand what to do. But to understand why we do it. What the practices are and how to do the practices. And most importantly, what preconditions must be in place for them to really work.

Applying Principles Over Practices

Here’s the deal. If you go back 25-30 years and you read the literature. You go back 20 years and read the early Agile literature. There was a lot of underlying theory behind the evolution of Agile principles and practices. Over the years, it seems we remember the practices, but don’t always appreciate why we are doing them. What problems we were trying to overcome, and what conditions had to be changed to make those practices effective.

It’s like knowing sprints should be the same length without understanding the underlying principles of empirical process control. Managing variation and throughput through consistent sampling intervals. If you don’t understand what is going on, you don’t know when to break the rules or stick to them.

Anyway, principles without practices can be applied universally. Practices can never be applied without understanding the principles without creating a high likelihood of failure.