Build Trust, Openness and a transparent culture of respect and value across all teams.
Have team working agreements setup on the ways of working and how they work and the flow of value.
The Scrum Master is the coach for the team to guide and help them discover ways in how they align and continual delivery the flow of value whilst relentlessly improving.
Do check the SAFe House of Lean and agile manifesto.
Get the teams and leaders to agree on what the skills gaps are within the teams and build an improvement backlog from 2 areas.
Team retrospectives and Agile Assessments
Team retros for the teams and by the teams to voice out how they feel and what they need.
Agile assessments for the business and owned by all to align teams improvement goals with growth opportunities and aligning all expectations which the Product Owners should include and own as part of the teams product back
Thank you for the ideas Daniel.
Skills gap and growth opportunities probably need to be less of a hit and miss on my train, will start there. Retrospectives could generate better output too. Will bring the team agreements to the next one.
I have missed what your real issue is… do you have 2 separate teams that arent cooperating or two factions in the one team? The two faction situation is probably slightly easier… bring in mob programming so that the two factions learn from each other
Though your question is phrased very broadly it suggests you have members of different departments on your team, and - as Scrum master - focus on the technology parts of a project.
If these teams are as separate as you suggest, it might be worth to consider tackling some of the underlying organisational issues first.
Let me explain: engineers/developers are likely to do a lot of testing themselves. A good test team will likely be involved in solving problems i.e. quite often develop code and/or test racks.
Ideally, this is done through a DevOps approach.
So, when you have a (largely) common platform and tool chain in place and understand how this streamlines the necessary information flow, collaboration almost becomes a non-issue. You will basically use a shared understanding of how (agile software) development projects are being executed.
Build the foundations first. You don’t want to fix the wall of your house when you know that your foundation is built on quick sand.
Hi there Isabelle, hope that you are having a great day so far. I would like to answer your question from my experience. Working with our CTO, Dev architects, testers and Scrum masters, etc (ranging from 15 - 100 people on the team) is that they feel comfortable working in silos. While that is always the “golden Idea” it never worked well when it came to launch as there was always one thing in most cases overlooked. An open channel must always be inplace and constantly updated (make this a liability if not applied) in real time, daily or every 8 hours whatever the time frame allows.
Stand-ups are important even if it is via zoom (not that secure…) Skype or what we used at Naspers “BlueJeans (similar to those mentioned / more secure). I recommend having a standup on shift changes (in short pipelines) or at 8am in the morning, It shows accountability and most importantly sets the expectation for the task ahead.
At the end of the day everyone has a part to play in development and launch, nobody is more important than the other guy on the project. It is up to the lead to instill this methodology and maintain the highest level of transparency.
In our team I was present in every (where physically possible) development meeting or stand-up. Not to interfere in anyway but mostly to learn and understand turnover time / progress / delay and churn.
After a few months I understood so much more and was able to close my deals in record time as I had an idea of what it took to start and complete projects. I even recognised attributes in our API that were built but used that I could sell.
These sales value added items gave us a huge advantage over our competitors and only because I took the time to be present. Later was even trained to actively support during our sandbox and live testing and integration processes. ????
It freed up time for my team to focus on development and built reapore amongst the guys. Not to mention I was able to close 90% of my deals as I understood the technical questions and would provide answers then and there.
My answer may not directly pertain to your exact situation however I have found it really works. Its a living hell to start, you will see after a few weeks of moning, and groning from several team members, this will become a habit and the production speed will be evident.
Look there is always one that will try sabotage the time frame of the meetings by asking repetitive questions. In this instance let the question be heard and if its a “stupid, or “repetitive question” because it was already answered, point it out!
Refer the answer to that of memos in previous meetings in light hearted way, use the same phase every time it happens. You will soon see this behavior will occur less frequently.
Oh yes, in stand-up meetings, end the meeting with praise of one of the members that completed / improved a task before the time. This is a great way to start or foster friendly competition amongst members. It is a really simple method and worked 100% with all tech teams in my experience. If you asked this question because your tasks are being ignored then suggest this to the team lead, explain why you would like to be included in everything. Get involved in all meetings as an “ear” you will soon see the guys come around. Good Luck ????
Hi there Isabelle, hope that you are having a great day so far. I would like to answer your question from my experience. Working with our CTO, Dev architects, testers and Scrum masters, etc (ranging from 15 - 100 people on the team) is that they feel comfortable working in silos. While that is always the “golden Idea” it never worked well when it came to launch as there was always one thing in most cases overlooked. An open channel must always be inplace and constantly updated (make this a liability if not applied) in real time, daily or every 8 hours whatever the time frame allows.
Stand-ups are important even if it is via zoom (not that secure…) Skype or what we used at Naspers “BlueJeans (similar to those mentioned / more secure). I recommend having a standup on shift changes (in short pipelines) or at 8am in the morning, It shows accountability and most importantly sets the expectation for the task ahead.
At the end of the day everyone has a part to play in development and launch, nobody is more important than the other guy on the project. It is up to the lead to instill this methodology and maintain the highest level of transparency.
In our team I was present in every (where physically possible) development meeting or stand-up. Not to interfere in anyway but mostly to learn and understand turnover time / progress / delay and churn.
After a few months I understood so much more and was able to close my deals in record time as I had an idea of what it took to start and complete projects. I even recognised attributes in our API that were built but used that I could sell.
These sales value added items gave us a huge advantage over our competitors and only because I took the time to be present. Later was even trained to actively support during our sandbox and live testing and integration processes. ????
It freed up time for my team to focus on development and built reapore amongst the guys. Not to mention I was able to close 90% of my deals as I understood the technical questions and would provide answers then and there.
My answer may not directly pertain to your exact situation however I have found it really works. Its a living hell to start, you will see after a few weeks of moning, and groning from several team members, this will become a habit and the production speed will be evident.
Look there is always one that will try sabotage the time frame of the meetings by asking repetitive questions. In this instance let the question be heard and if its a “stupid, or “repetitive question” because it was already answered, point it out!
Refer the answer to that of memos in previous meetings in light hearted way, use the same phase every time it happens. You will soon see this behavior will occur less frequently.
Oh yes, in stand-up meetings, end the meeting with praise of one of the members that completed / improved a task before the time. This is a great way to start or foster friendly competition amongst members. It is a really simple method and worked 100% with all tech teams in my experience. If you asked this question because your tasks are being ignored then suggest this to the team lead, explain why you would like to be included in everything. Get involved in all meetings as an “ear” you will soon see the guys come around. Good Luck ????
Beware of unintended consequences. I can ‘finish’ work quickly by taking shortcuts, bodging, not testing all scenarios, skimping on process etc etc. I shouldn’t be praised for that because it will come back and bite in the arse later. Engineers do take pride in their work and get motivated more by being seen and acknowledged as an expert in at least one field, so make sure over the weeks you ask people a meaningful technical question relating to a possible use of something they know about. The acknowledgement that they know about it, that you as a form of leader (servant or otherwise) is asking them puts them as an expert. Even better if you get (under a controlled situation like a backlog grooming or planning session, not as a random interruption) someone else to ask them all the better.
Haven't found a solution?
This will mark this comment as best reply and close your question.
Are you sure?
This will close your question without a Best reply.
Are you sure?
This will report this content as inappropiate to the moderators.
Are you sure?