As a manager you probably recognize the dilemma of composing your teams. What competencies should be in each team, what roles and responsibilities, leading ultimately to the question: who? Fat chance that nowadays you’re working in an organization that adopted (to some degree) an Agile way of working. You might even already have some multi-disciplinary development teams. Probably you composed these teams by yourself, maybe with some input from some key players. Great, you’re done now, and let them do their thing.

Multi-disciplinary, yet unable to deliver

Your teams are applying Scrum and have had their first successes. Local improvements have been made, and now it has become clear that the biggest impediment is the hand-offs that are still there. Upstream of your Agile development teams there is still this preparation vehicle, which does most of the requirements gathering and functional decomposition of big ideas. They might even have created a planning to go with that. At the other side, downstream, there is the functional and technical maintenance department, and after that the operations and infra departments. Your development teams are faster now, but your business partners are still unsatisfied about the time it takes for their idea to get into your client’s hands.

Problem solving

So your natural reacting is to go into problem solving mode. You’ve heard about DevOps, read about the Theory of Constraints and have peeked at scaling frameworks like SAFe and LeSS. Inspired you ask yourself: “What if I add the business consultants to the development teams? And let’s also divide the maintenance guys over the teams. And maybe there should be a System Team. Of course, the teams should be balanced. A right spread of junior, medior and senior employees is critical. I think Gus should definitely be in the Mortgages team. And Margaret should definitely not be paired with Jane.” Before long, you have sketched out a new org chart with names and numbers. Great, just implement this and you are done! I wish it was this simple, but it’s not.

Complexity

This is a complex situation. Which calls for an empirical approach towards coming to a solution that works. Many variables play a role in this problem: what types of activities need to be done, what types of work are there, which platforms are involved, which clients are targeted, and so on. The Law of Requisite Variety comes into play, which states that anything that controls a system must be at least as complex as the system being controlled. Which you might guess is impossible for one person to embody. So the first realization you should have is that you will not come up with the perfect solution at the first go. Second, you are acting on assumptions and imperfect information. So involve the people that are experiencing the problem the most. Of course, it helps to give them a direction and constraints. You and your organization hired smart people, right? So tap into that collective intelligence and let the most optimal organization emerge from the ideas and hypotheses of the collective. You will be surprised by not only the effectiveness of this approach, but also by the engagement this brings from the people involved. Of course, regularly reflect on and evaluate the composition of the teams. Let the teams do this themselves, restrict yourself with providing a clear purpose and advice. Be a true leader.

Leave a Reply