Waterfall is hard, and agile is confusing, so why should you put your team through them? Instead, you are probably already using some of these alternative development techniques! You won’t learn about these in a text book, but you’ll find them in use all over the software industry. Let’s learn about how we manage small teams:

1. Whack-a-mole development

This is the most common development methodology around. Almost all small teams do this to begin with, and businesses can grow huge off the back of Whack-a-mole development. So what is it?

Whack-a-mole development is a process where your developers frantically bash around, attempting to knock as many bugs, feature requests, and code changes on the head as possible. They focus fully on whatever has just popped up, and anything that’s missed is ignored (because if it’s serious, it’ll pop up again). Sure, long term planning is impossible, and the fixes tend to just introduce more bugs, but you can sleep safe at night knowing that no single developer has any clue how the whole system works. That’s security, right there!

2. The Big Room of Developers (BROD)

The Big Room of Developers can coexist with Whack-a-mole development, and often will. It’s a great way to handle a growing team to support your growing business. So what is it?

BROD is basically what it sounds like. You hire a bunch of developers, put them in a room, and shout features you want through the door. These are all experienced developers, so I’m sure any one of them could help you equally as well. Developers are an entirely interchangeable resources, after all.

Because there’s no management overheads, the BROD model allows every developer to just work however they want, without concerns like "consistency", or "documentation" weighing them down. It also means that you can just hand your task to whoever looks least busy. Being that they’re all professionals, any one of them is fully capable of requirements discovery, planning, and maintaining the project. Sure, they might waste hours or days trying to find, understand, test, and work on other developers code, but a healthy dash of imposter syndrome will prevent them from ever bringing it up.

3. Walled Castle Code

When you’re ready to start building bigger projects, you have to start thinking about abandoning Whack-a-mole development. Instead, you should look at working with Walled Castle Code. So what is it?

Walled Castle Code is what happens when you get a number of talented developers together, and don’t encourage them to collaborate. Instead, individual developers get to go off, and make their own projects from scratch, using whatever tools they see fit. Eventually, another developer will be asked to change something on their code, and that’s where you’ll see Walled Castle start to shine. The original developer will jealously defend their own projects, and won’t allow anyone else to touch them. I’m pretty sure that that’s the "Single Responsibility" part of SOLID code right there.

Sure, if one of the developers leaves, no-one else will be able to pick up their projects properly because they’ll take all of the business knowledge with them, but generally developers who participate in Walled Castle Code aren’t interested in going anywhere where that style of development might not be tolerated. That’s some commitment you can count on!

4. My Favourite Developer

What if you have a large non-coder team, and you want them all to request changes or file bugs? This is another way that you can run the BROD model. So what is it?

In My Favourite Developer, each staff member who can request features or report bugs picks their favourite developer, and talks directly to them all the time. No matter what the task, or how busy the developer is, they’re the initial and only point of contact. It’s like giving those people their own personal coder support staff! You may lose oversight as to what is being worked on, and new features may start appearing all over the place, but you’re letting the users give direct feedback on how your system should work. It doesn’t matter so much that different developers will unknowingly break functionality that other developers just built, because My Favourite Developer will be on hand to change it back again.

Building teams with these methodologies

As you can probably tell, everything up to here is pretty tongue-in-cheek. These aren’t really advised methodologies, but they are common. It’s hard to grow a team, especially from just one or two developers to five, or ten, or twenty. Understanding what development methods exist, why, and how they operate is important if you want your team to succeed in the long term.

Some of it comes down to process management - ensuring that developers, management, and users all follow a consistent process when reporting bugs, adding features, and working on code. You can ensure that a lot of this happens correctly by using the right tools, such as a decent task tracker, CI environments, and automated testing. These all require someone in the organisation to have the knowledge and will to manage and control the team, otherwise the developers will fight the systems which make their lives more difficult (i.e. wrest ultimate control of the code from their hands, while enforcing accountability for the changes they make).

Making a change to your development processes takes time, and it takes buy-in from all sides, which can be difficult to manage. In short you have to strike a balance between benevolent dictator, and open democracy. You need to allow the ability for your team to comment on, or suggest process changes, but you also need the authority to veto changes which are bad for the company. If your team feels that they can’t participate, they’ll get frustrated and either ignore the changes or actively work against them to prove a point. If they’re included, and given the opportunity to shape the changes, they’re more likely to accept the ones they don’t like. Having the opportunity to say why you don’t like a change is a powerful tool, so long as your feel that your opinions are actually being considered.

Ultimately growing a team is difficult, especially if you don’t have people who are experienced with team development. It can help by breaking the team into smaller groups of 2-3 developers who are comfortable working together, but you still need to maintain oversight on what’s being developed (hopefully without micro-managing).

If you look at your team, and recognise one or more of the development structures above, maybe it’s time to start working towards something better. Don’t expect change to happen overnight, but working towards a better, and more sustainable team is well worth the effort.