Functional teams: lack of Systems Thinking understanding
Hi guys, since summer is here I decided to invite my friend Herman to spend a weekend with me in Portugal, I was super happy to know what is going on in SuperSoft.
For the ones that follow my work for couple of years know that Herman is an Agile Coach at Supersoft. Herman is a person with whom I discuss several topics, mainly organisational subjects. Also, you should know that Herman is a fictitious character, so any kind of similarity with reality is a pure coincidence.
We stayed in a very nice part of Lisbon: Alfama. It´s an old part of the town, I highly recommend it, you´ll meet awesome people and see very nice architecture, I am sure you would love it. Alfama is very close to a fantastic restaurant that only serves a seafood: “Cervejaria Ramiro“. I decided to take Herman there to enjoy the fantastic Portuguese seafood.
When we arrived, we order a fantastic bottle of white wine and some delicious shrimps with garlic sauce. That´s when the conversation started. I asked him what´s new in SuperSoft, what is he facing currently in his company. He was very frustrated again! Couple of people have decided to create specific functional teams that would have a very specific knowledge in his company.
I was shocked because at this point I would have thought that everyone would have a good understanding why we should not create functional teams. After all everyone in the agile community mentions that we should build companies on top of cross functional teams.
For most of our companies this is a true challenge. For many years companies worked in a way that teams were functional and highly specialised, therefore breaking this paradigm can be very difficult, yet I thought this was clear for everyone so I asked Herman why they would do this.
Herman:
Well I believe they have the best intentions, they think they can be much more efficient when they have functional teams specialised in a specific part of the product.
Unfortunately, they do not have any understanding on Systems Thinking and they do not realise that what they are doing is local optimisation, harming the company as a whole.
Luis:
Can you elaborate more on that? I fully understand but I would like you to explain your thoughts better.
Herman:
Sure, let me draw this on a paper as it´s much easier to understand. This is the team setup:
Luis:
Looking at this picture I can already see the “Front End”. Product Owners - in order to get their stories done, they must write their stories just covering front end, which in reality are useless because the final client cannot use just the front end.
Herman:
Correct.
Luis:
Ok so how can they “get their” backend functionality?
Herman:
This is the funny part, these people think that it´s as simple as asking to the tech lead. So every time they want something new they need to ask the tech lead to see if it´s already implemented on the backend, if not, a discussion between the front end tech lead and both POs start.
Luis:
Are they nuts? Do they really believe this will work? I can already see tons of problems! The conversations between everyone involved, conflicts, priorities and above all frustration from PO´s side. They will take ages to implement their ideas.
Herman:
Of course, Luis. Let´s put all these things on the paper, just to have an idea.
The Product Owner has an idea, he contacts the tech lead for clarifications. More than a week will pass until the tech lead figures out all the technical implications and the PO can only present their ideas during the next sprint.
The explanation is done and the Front End PO explains what is needed to the other PO. Another week will pass until all the requirements are clear and understood
At this moment the PO (Backend) understands everything but he does not agrees with the priority, therefore nothing will be implemented during that sprint. The decision must be made on the weekly product steering committee. CTO, CPO and Product managers will need to meet every week to discuss about priorities and decide what will be implemented.
In the best case the feature is implemented during the next sprint on the backend, but of course not on the front end. So to have everything implemented on the frontend and backend it will take 2 more sprints - four weeks.
Luis:
So what you are telling me is that in the best case you will take around 11-12 weeks or 3 months from an idea to implementation???
Herman:
Yes, but do not forget the frustration, the miscommunication and time wasted in Product Steering Committees defining priorities and so on… The cost for the organisation is tremendous but these guys really think they will be faster with functional teams.
Like I said in the beginning, I truly believe this! People do not have any clue about Systems Thinkings, WIP, throughput and cycle & lead time.
Product Owner will prioritise towards all teams and we will have weekly product steering meetings to decide what priority we should give to each stories.
Luis:
The outcome will be a mess and people will spend hours in meetings and getting into political fights… But tell me Herman, if you were in charge what would be your approach?
Herman:
Simple, my friend. Since there is enough people, I would just split those guys into different teams and create truly cross functional teams. Teams that can deliver end to end. If you do this, the Product Owner does not need to spend days talking with tech leads and other POs.
The Product Owner can only talk with the team tech lead to see if the functionality is available or not. If it´s already available, that´s awesome, if not, he will just create the user story where part of the story will touch on the back end…
Luis:
Yes, indeed this is what companies should do, but unfortunately few of them really understand the problem of assembling functional teams. I would like to add something. I see the value to assemble functional teams when for example the team itself produces a product.
I worked in a company where some of the teams were assembled to tackle the platform, even when external teams were dependent on them, this approach made sense. Because this company had their platform as a product itself, they were selling the platform to clients. So we need to be very careful when we think about these kind of issues.
___________________________________________________________________________
The conclusion of this story is simple. I do not want to generalise but I start to believe that when managers build companies around functional departments they really do not understand systems thinking or theory of constraints.
Maybe, and this is just an idea, companies should start to invest and provide these kind of trainings for all employees when they join the company. I believe these trainings will be useful for many other things too!
So next time you need to assemble teams, be careful how you assemble them - are you going to enable local optimisation or are you aiming to improve the end to end system?
Did you like this post? So please leave rate it below :) Big thanks :)
Picture Credits to: Doc Searls
I would love to get a star rating for this post:
Hi Luis,
In the company I work for, we are in the transition from Waterfall to Scrum. We build our system over our own NET framework given the flexibility required. While we have created “Application” teams, which basically generate the application and in some few cases change the framework. We mostly still depend on Framework team, which is very small, in order to implement functionality that is needed in the framework. The main problem we are facing is that because the framework creates these functions but they test it in some scenarios but the rarely implement them in real life screens, in many cases when first team consumes the features usually there are errors that in some cases stop team progress, which by the way generates a lot of frustration between team members. Also we have scenarios where changes to the framework are implemented and one more time, because they are not too much working in the application the changes break functionality that has been already programmed. My question is, is this a common company setup? Or as part of our agile transition we should try to move all the framework work to be done as any other feature in a scrum team? What is your opinion in this matter?
Hi Luis,
Thanks for your question and sorry for my late answer :)
Yes its very common approach, but this does not mean this is a good approach :) some times makes sense some times does not make sense.
For example some of my clients have use this approach but their “framework” is a product :) They have other products that are built on top of the framework but the framework itself is sold to the market, so in this case I believe it makes sense. If your case is not like this one you should try to move the framework people to all different teams and create true end to end teams.
I need to make you aware of something, people will tell you that is more efficient to have a central team than a bunch of people separated in different teams, and they are right, but the speed that you get brings a much higher benefit than the cost savings ;)
If you want to discuss more about this drop me an email :) I will be glad to have a skype call with you :)
Luis
I couldn’t agree more with this post! I’ve worked in such an environment and there was quite a lot of churn as we’d identify issues, write specs for a piece of it, prioritize with others…it actually led to my organization’s adoption of Scrum which we have been using for about a year now.
Currently we still have teams that are more application organized (a team for application A, a team for application B) but with devs/UX/PO/analysis within each team we can span multiple environments somewhat, or given enough time to learn the new application (spike), can work with it. Still a bit of a work in progress.
Thanks Amy for your comment :) I believe we all saw this kind of setup ;)
Luis