A helping start when moving from Silo'd working

cancel
Showing results for 
Search instead for 
Did you mean: 

A helping start when moving from Silo'd working

tbagnall
Active Member
0 1 1,228

I often find when teams move from working as a collection of individuals with a shared purpose, but in different silos that they needs a helping start on when to communicate with each other.

Naturally there are points in time where Scrum creates the opportunities, but those opportunities are not enough for a performing team.

I don’t intend on going into how to communicate in the Scrum ceremonies, but rather share some thoughts on how to start teams effectively talking.

Here are the guideline I give teams:

When you are about to pick up a new user story have a quick chat with the team - all the cross functionals (Coding, testing, documenting, deploying, user experience, etc.) to:

    • … ask if there is anything you can do on a currently in progress user story to help get that completed first.
    • … make sure the story is still good - incorporating anything we may have learnt so far in the sprint. Include the PO in this.
    • … make sure the plan on how to complete the user story is still right - it might need updating based on what we have learnt so far in the sprint.
    • … make sure the tasks represent he plan to complete the user story and have enough information to enable anyone to pick them up.
    • … ensure there are the right people available to work on the user story. If you have specialisms in the team make sure there is someone from the cross functionals to work on the user story, such as a tester to ensure a coder knows what to produce to pass tests.



This conversation would normally be anywhere from 30 seconds to 5 minutes, unless we have learnt something that causes he plan to change considerably.

When you are about to pick up a new task:

    • … ask other team members if they need any help on what they are working on, to help them get their task completed.
    • … check that your approach is going to be correct for the task at hand with another team member. For example
      • a coder may check with a tester before implementing code to ensure they understand the tests, edge cases, negative paths, etc. that they need to cover.
      • a tester may check with coder or user experience to see how they are thinking they would add a button to a user interface to ensure their automated tests would capture it


This is a start for teams, and once they get into the flow they will adjust and improve, probably without even thinking about it.

1 Comment