Scaling agile seems to be a very hot topic this days, with the introduction of several techniques and frameworks that aim to
help you achieve that.
However, too many management teams jump ahead and dive into the various frameworks without first asking themselves the most fundamental of question:
Do we really need to scale?
Recently, several of my meetings with new organizations started with:
We are very successful growing company and we already grown by XX% and we plan to increase in size by YY% by the end of the year
where XX & YY are in the areas of 30-40%. It then continues with:
Yes we do have some issues and we are totally aware that what worked for us so far will probably stop working/need change. How can you help us?
Which kind of making me think on why companies start this growing up adventure when, when clearly they are not ready for it just yet.
So, if you are managing a growing team/Group/company, here are some things you might want to consider:
The need to do more
The main drive for growing up is the simple need to just do more. The natural state of any company is “growing”. The minute we get into a state in which the current team is functioning more or less ok, or when the product seem to be quite successful, we instinctively try to grow. it’s a basic business assumption, Companies that don’t grow shrivels and die. In fact, its so ingrained into our DNA that it’s the most natural thing we think of. Problem is that growing in size is not always a smart move. Throwing more people at the problem will not always help. Brooks Law told that to us about late project. But even when we are not there yet, increasing our size is never a trivial process.
Maturity before growth
My youngest daughter started to walk quite late, in fact we got quite worried and started to consult with doctors about it. The general answer that its quite common for tall babies to start walking later and since she is very tall for her age (in the 99%) we just need to wait. Same holds true for organizations, if you grow in size beyond your maturity level you will have issues “walking”. A statement like “we know that things we did so far will not work” which is not followed by “but we know what we need to do” is in many case a good indication of that. Hiring more people will most likely cause things to just move slower, which will naturally increase the need to hire even more people which will just make everything even worse.
Another thing to consider is the growth capacity of a team over time. Using Tuckman Stages of Group Development terminology we know adding more people to a team takes it back to earlier stages. For most teams adding just a single member means there’s a period in which their speed will decrease until they get back on tracks. If you add another in that time, the decrease will become even more significant and I suspect the effect is not linear. try to add a third member and most likely you will just create a dysfunctional team for a very long time. What’s more, for some reason It seems that this is never see that reflected into actual plans. While management acknowledge the fact that new people are not productive on their first weeks, the fact that introducing a new member disrupt other members work is just ignored.
Sometimes Less is More
what is better having two small teams (3-4) or one big team(6-8)?
while there is no simple answer, in most cases we do know that there is definitely an overhead the minute one switch from a single team mode into working with multiple teams. In most case if we only consider the short term and we don’t need to grow beyond this, a single bigger team will be more productive and effective. The down side, is that a theres a limit to how big a team can grow. above 8-10 members things just get too hard to manage.
Do we really need to be big?
In this blog post Ron Jeffries talk about SAFe, in the section about “SAFe Fundamental Assumption” he describes assumptions which I encounter inside and outside the context of Agile. People wants to be big (the basic need for Growth) they like to work on big and complex system (basic need to feel important) and sometimes this make them ignore the simple truth that while they are “Many” they are no “big”. What looks like a big company working on a big system is actually a collection of small systems worked upon by small groups which may or may not need to be in complete synch.
But we NEED to do more
I agree trying to get more done is always a goal, however if I quote Ron Jeffries again:
Finally, many of your multi-team projects can turn into single team projects once you get your teams competent in really doing Agile Software Development. You don’t need to build a big process because you don’t have a big problem any more.
We can see an alternative:
Before you start increasing in size, Get you team really competent in developing software. In some cases that will be enough, and even if not. before you do that you are just not ready to grow