Common Sense Scaling: The 10 Do’s and Don’ts for Delivering Value with Multiple Teams

09 Jan, 2024
Xebia Background Header Wave

Today’s world requires continuous adaptation. Legislation changes with each new term of government, the competition is always right around the corner and customers constantly voice their opinions about products through social media—so the products better be good! How do you deal with all this changes, uncertainty, risk and complexity? A way to cope with this is to embrace it, not try to predict or to prevent it. Embrace that it is there and the way to deal with it is by using an empirical approach. Inspecting the reality around you and reacting on it in the best way you can at that moment. The Agile way of working is build on empiricism.

But when it comes to becoming Agile, there are many different approaches. Some organizations and departments like to perfectly plan out their transformation in detailed steps, numerous descriptions, and extensive slide decks. Others prefer to leap right in, with one or two teams, just to see how it works. Regardless of your approach, how you choose to structure and organize the roles and events of multiple teams working on the same or different products makes all the difference in the success of your Agile transformation. So, to help you out, we’ve put together a handy list of do’s and don’ts for delivering value with multiple teams.


  1. Don’t scale if you currently can’t deliver value. If itis difficult for you to deliver value in your current situation, scaling up will only make this problem bigger. By scaling you will increase the number ofdependencies, communication lines and tuning of the work done. Your chance of success will be very small.
  2. Don’t start with writing a big plan on how to scale your whole product delivery. After writing comes the execution, and so, the end of the plan. You’re likely to encounter the same challenges as in waterfall development—unnecessary delays, failure to deliver or to deliver the right thing, too expensive, among other traps.
  3. Do not scale in a way that is appropriate for an organization that is completely different from your own organization. Every organization has a different structure, culture, feeling, change appetite and is different in much more ways. A scaling method that works for one company might not work at all for another one. Take Spotify, for example—or rather, don’t. Too often, organizations think they can simply copy and implement the “Spotify model.” But this model is the result of five years of experimenting, adjusting, adding and deleting, and changes are still constantly being made. Don’t copy it.
  4. Do not scale with an elaborate prescribed method if you really want to change. Using a very prescribing method is a safe way to disguise your reluctance to change. In these prescriptive methods structures, processes and roles don’t change much. They are justrelabeled.
  5. Don’t “buy” a scaling framework by hiring experts of a certain framework or model. Hire experts who can help you by making an honest evaluation and determination for what best fits your organization.


  1. Start small, inspect and adapt and let your Agile organization grow naturally. Learn what works for your organization and what doesn’t before pushing it across(or down) the company.
  2. Involve the people actually doing the work, support them in experiments and create an environment where failures are seen as learning opportunities. Using this bottom-up approach will give you better insight into what works and what doesn’t and it will make people feel more involved. Thus taking more ownership in being the change.
  3. Changes in habits, behaviour and culture also impact the leadership. If you want your organization to work more in an Agile way, the leaders probably have to adjust behaviour along the way. Learn more about servant leadership and Agile leadership.
  4. Measure. To get insights in the contribution of the changes you made, measure the results of the improvements.
  5. Seek knowledge and experience, find organizations who are similar to yours and learn from and with them. Share your knowledge so other organization scan learn from it and let stories of other organizations make you aware so you will not make a same mistake.

Scaling your product delivery does not mean scaling your success directly or linearly. It means that you go into a learning process—one where mistakes, experiments, failures, and dawning realizations are all allowed. It will require effort from the people on the work floor as well as the people managing the organization. Scaling won’t be easy, but you’re up for the challenge—if you use your common sense!


Get in touch with us to learn more about the subject and related solutions

Explore related posts