Grab your opportunities while scaling agile
Many of us are considering how to use agile and lean methodologies in a growing organization. I want to explore some dream scenarios and perhaps inspire to work towards these or similar scenarios. Warning for outrageously amount of bullets below.
You are starting up with a single backlog and a single team. Simple. Then you grow and some point you have to decide how to split your work. Some alternatives start to emerge:
i.) Multiple teams on single backlog
ii.) Split product in components and have teams working on components
iii.) Multiple feature teams on different collection of features but joint code base
iv.) I’ll leave my preferred alternative for a while.
Well each of these has it’s problems. Common problems discussed in agile communities could be:
On i.: Works with few teams, but not scalable. With too many teams you are forced into advanced branch handling and messy merges.
On ii.: Teams do not work with actual business values and you need team deliverables to be integrated with other teams and handover mess in your hands.
On iii.: Feature teams with joint code base do not care about the product life cycle and thus you usually end up with component teams that guard and care for the components. The feature teams also need to hand over and get changes approved by component teams which causes dependencies in delivery flow and is thus slow.
When exploring alternatives it makes sense to find out what is important in your organization. I will assume certain wanted properties:
• We want teams with product life cycle ownership. A single team without handovers that take responsibility for life time of code base. This support speed as well as has automatic incitements for quality.
• We want teams that have few dependencies to other teams or instances when moving requirements to production where the features can be used and explored by customers. This enables speed.
• All deliverables shall carry a customer value. Enables full understanding of how your features are used and you really learn how to build products that customers love.
Let’s try this. We have a company vision. Preferable we also have a company mission or purpose. I will assume you can split your purpose in several business areas that are all important but from a business side separated to a decent extent. Consider the separation that it must make sense to explore values and deliver these values in this business area without the need of a joint delivery from another business area in the most common situations. Teams working with this set of properties can be called full stack teams, application teams, end to end teams and what have you.
As you scale you can start creating separate backlogs for each of these business areas. Each maximizing performance and value in its area. By creating organizations around these areas, not only in IT but entire company, you have rather self running businesses all striving to accomplish the overall company purpose and vision. Remember that independence is never complete in a single area and it shouldn’t. Make sure to establish collaboration points across these areas when applicable and nurture these collaboration points. No one loves a silo!
So far this looks very similar to alternative iii. above. Let’s look at one additional property. Here comes the punchline friends. This require smart adaptation of your architecture. Let’s say that we are early on very conscious that we will grow and take the cost and time to continuously evolve our code base to match these business areas. Or that we at some point realize that we need to refactor our system and then mold our code base to match our business. Alternative iv below would then be a dream scenario, at least my:
iv. Multiple feature teams on different applications working on customer facing features and owning separate code bases.
This enables many fantastic benefits. Teams will be able to work on customer facing features without major dependencies and own product life cycle of the code base. It also scales in most reasonable cases. As you continue to grow also make sure to let the business areas branch out and create subdomains again freely living as its own organism. Keep following this approach in architecture as well as you grow.
Fig2. Gradually evolving your business areas and make sure your architecture follows.
Fig3. Completely new business areas (in this case “E”)can also be supported if the company moves in such direction.
Not an easy task since it requires a simple and small architecture that can be molded to whatever the company steer towards. On the other hand much easier than ignoring the fact that your code must follow your business. The SOA approach with microservices can be a possible solution that is fairly light weight to refactor and reshuffle in the sense of creating clusters of services serving a certain business area. If only we were so lucky! But then again, there is no such thing as luck. “Som man bäddar får man ligga” is a suitable saying in Sweden. (“As you make your bed you will lie”).
Grab the opportunities and steer your architecture to support descaling of your challenges.
Take control of your destiny, friends!
