Scaling out microservice scrum teams

The majority of software products I’ve contributed to tend to start with a couple of developers keen to get on with the art of making working software, whilst the rest of the organisation focus on the high level design. The daunting task of establishing the foundations of your product development factory falls into the hands of these two pathfinding developers.

I’ve been one of those developers four times round now, and would like to share my top three recommendations for large scoped software products where you’re going to have to scale.

1. People will always be your largest success factor

Shift focus from high level design to getting the right people in who will be hands on to do the fundamental job of making your software product, and more importantly, think big. However, it is criminal to throw anyone at it.

You can do all the up front design and planning you want, but execution eats strategy for breakfast. And for great execution in a scaled environment, you’re going to need exceptional people with hands on experience that also think big. The next three to five developers you bring in, combined with your founding developers will have the most impact (for better, or for worse):

• Whether you can scale to deliver all the features that turns your product into something your target audience *has* to buy
• Whether you deliver the above at production-grade quality considering security, performance, resilience and other fundamental operational aspects
• Whether you deliver the above on time and within budget, before your competitors get there first

You’ll probably take an agile approach as per trend, meaning that you can avoid making lots of technical decisions up front, and flex your architecture as you try things out for real to see what works and what doesn’t, perfect! However, your five to seven pathfinding developers are going to be steering that ship. Here are three personality traits I would look for when building a pathfinder team:

• Those that have cross-functional production experience across the stack, over those that have technical depth in a particular area
• Those that value team contribution, togetherness and helping others shine, over those that thrive on individual heroic success
• Those that hate repeating manual processes and complexity, and continuously seek more efficient and simpler ways, over those that accept painful process and never challenge the norm…

2. Avoid up front decisions that will constrain your team, and ultimately your product

My next recommendation is to treat your development organisation as first-class citizens. Seek their guidance before making any concrete decisions that you *think* you need to make. They will help you formulate an approach that doesn’t fix you down a particular path up-front, or as a last resort, help you make the decision, bringing first hand experience to the table. If you are making a technical decision or a decision that will constrain the ways of working, the consequences will probably hit your development organisation the hardest, so get them involved.

To bring this to life let me share some examples of things you should avoid:

• Fixing the platform and languages to be used
• Fixing the agile and devops tooling to be used
• Fixing work products and deliverables to be produced
• Making technical decisions entirely based on theory

Your developers are probably the most creative people you have so feel free to get them involved in the business side too. They’ll probably spot opportunities with your product that you have overlooked.

As a side note for large corporates, you should really have an exceptional and respected board level executive developer. Your development factory are going to need someone to raise killer issues to who truly understands and has the necessary clout to nip these in the bud. This is not an executive architect who hasn’t coded in years.

3. Scale with confidence using a development factory

The development factory is a term that I’ve coined on a few projects. Getting this in place early is super important if you are going for a microservice style. Let me describe this concept with some characteristics:

• Automate as much as possible to increase the time your development organisation has to deliver true product value (e.g. automate the creation of your continuous delivery pipelines for your multiple microservices)
• Continue to get in the right people. Use a developer challenge that is not prescriptive on approach, TDD, documentation, appropriate use of design patterns, etc. You can now understand the natural approach that candidates take to develop working software. Compliment that with a Google hangout
• If you are developing microservices, consider sharing reusable building blocks between them (e.g. develop a UI SDK that brings your UX design language to life)
• Don’t knee-jerk scale too quickly. If you don’t have the fundamentals of your factory in place your new team members are going to go off on tangents and deliver a right beast
• Restlessly improve your software product, even after it has gone live

I’m interested in whether you agree with my top three recommendations, or what you would swap in and why.