Skip to main content

Prevent cross-functional Silo thinking teams

Last post 06:29 am April 29, 2014 by Himadri Bhattacharya
7 replies
Anonymous
05:47 am April 25, 2014

Let’s say you’re a scrum master within an Agile team that is creating a large complex web application. It’s the companies global policy that front-end development is done with .NET, backend with Java and content is managed by Tridion.

Your team consists of 8 members (most of them are external consultants from different vendors), all specialised in their own domain.

For example:
1 Java Developers
2 .NET Developers
1 UX Designer
1 Tridion Developer
1 Business Analyst
2 Tester

Yes, you have a cross-functional team as in “the entire knowledge is available in the team to produce potential shippable increments”.

How do you make sure that your team doesn’t go into the so-called 'silo thinking'. The 'design guy' will take care of design, the ' Java developer' writes the backend and the 'tester' does the testing. If the 'design guy' can't get his work done on time, this will impact the tasks that follow the design. Because team members can't help each other out, every delay, problem or interruption will impact the entire sprint. And this will happen;


05:02 pm April 25, 2014

It's quite unlikely that the scope and the tasks for every sprint will be as same balanced as competences in the team. What would happen, if it will be a lot of java tasks and none for UI designer?

I don't believe that .NET developers couldn't write a piece of java code. Java developer could still take care of all critical java task, but the rest might be assigned to every member and be finished with java expert's help.

Probably every team member is T-shape person, ie he/she is an expert in his/her domain, but still have a little knowledge about other technologies.

> Because team members can't help each other out...

why? they are not co-located?


Anonymous
05:29 pm April 25, 2014


Posted By Xebord on 25 Apr 2014 05:02 PM
It's quite unlikely that the scope and the tasks for every sprint will be as same balanced as competences in the team. What would happen, if it will be a lot of java tasks and none for UI designer?


Yep, that is a big chance that this scenario can happen.



I don't believe that .NET developers couldn't write a piece of java code. Java developer could still take care of all critical java task, but the rest might be assigned to every member and be finished with java expert's help.


I believe that .NET developers can recognize Java syntaxis and vice versa. But recognizing the syntaxis is 1 thing, coding alongside is something totally different. Especially if both domain uses their own specific IDE, frameworks, tools, libraries etc.
I've worked in many Scrum teams in the past and never once have I seen a Java developer starting doing .NET development and vice versa.


04:53 pm April 26, 2014

Fully agree that Java != .NET. But they are still developers. Most of coders are used to learn constantly. If there is no task for java developer what s/he can do? Can install specific .NET IDE, frameworks, tools, libraries etc. and try to learn. It's better that do nothing. Even if java developer must assist the rest, it will be an investment for the future.

I also believe that some members of the team would like to try something new. Once I had to become a tester, but I was a developer, because there too few coding task. And finally I really enjoy the testing.

Did you talk about it with the team?


Anonymous
06:08 am April 28, 2014


Posted By Xebord on 26 Apr 2014 04:53 PM
Fully agree that Java != .NET. But they are still developers. Most of coders are used to learn constantly. If there is no task for java developer what s/he can do? Can install specific .NET IDE, frameworks, tools, libraries etc. and try to learn. It's better that do nothing. Even if java developer must assist the rest, it will be an investment for the future.

I also believe that some members of the team would like to try something new. Once I had to become a tester, but I was a developer, because there too few coding task. And finally I really enjoy the testing.

Did you talk about it with the team?


This is a hypothetical situation. I’m lucky that we only do PHP development so no other languages are required. (for now)
Let’s say we remove .NET so the team consists of the following members:
3 Java Developers
1 UX Designer
1 Tridion Developer
1 Business Analyst
2 Tester
Now the UX and Tridion domain are totally different.
So again, how do you make sure that your team doesn’t go into the so-called 'silo thinking'.
I’m sure a lot of teams has been facing these kind of issues. Just wondering what others would do.


09:03 am April 28, 2014

> How do you make sure that your team doesn’t go into the so-called 'silo thinking'

Unfortunately this isn't just a matter of "silo thinking". Developers, designers, BA's and testers can have their titles in their job descriptions and employment contracts, and it may also reflect their career expectations.

The first challenge is to build a willingness to cross-train in such conditions. That means change, and change involves a certain level of risk. Some people may have a very low risk tolerance for good reason. Imagine for example a recently qualified tester who is just finding their feet after (say) becoming a single parent. If that person changes their skill set, it could have implications for their employability and consequently upon their ability to meet family responsibilities. Silo busting gets even more complicated when part-time workers are thrown in the mix, as their opportunities to partake in the effort may be reduced.

I don't think there's any real solution to this. The important thing is to be aware of the constraints that people perceive as affecting them. I don't like the term "silo thinking", as it implies that the problem can be reduced to the elimination of some sort of mental block. While a mental block to cross-training can exist in some individuals, the true story behind organizational skill silos tends to be more complex than that.


04:47 pm April 28, 2014

ScM is also a coach. Hence I try to introduce T-shape people concept and bus factor. And how it might impact the team and work.

Usually in the team there are a few people are willing to learn new technologies (and few aren't because the prefer be an expert in the narrow area).

Also the team members understand if there is no work in their specialization they can't add anything to the increment. So better to even shadow the overloaded mate (pair programming) and learn something.


06:29 am April 29, 2014

How do you make sure that your team doesn’t go into the so-called 'silo thinking'.



I believe if we keep the team together and help them learn from each other using pair programming techniques then over time the 'silo' thinking should break down. Scrum master should help with mentoring and coaching the team to achieve this. There is no silver bullet, you will need to work at it and help bring the change in behaviour.

Best of luck with your Scrum team :)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.