Effective teams -individual focus with Daily Goals
- The daily goal was too big to be accomplished in a day- if so then we need to work together on setting up smaller achievable goals (“baby steps”)
- We had an impediment and couldn’t solve it or trigger action in a proper time – that means we will need to work on our communication flow and or the mechanisms we use to unblock teams or it also could be related to how important (priority) or not it is for the organisation to unblock the team.
- The daily goal had unknown work associated to it – this will be a great opportunity for us to work on improving our Requirements Workshops (or Grooming) and/or start using more spikes (investigation tasks) so that we can understand a little better the depth of our committed goals.
- People start thinking a bit more on which work should be picked up next (paying a more attention to any possible critical path and reflecting on the overall goal)
- They also sync a bit more as a team – because when thinking about what one should pick up next, the team member normally asks the team what they think would be best.
- Everyone has a greater feeling of achievement, and everyday feels like real progress towards our objectives.
- Becomes easier for team members who don’t have depth of knowledge in a certain area to still understand the progress towards the common goal – example is if rather than explaining with detail (jargon) the technical progress during last day, one says simply that the goal of “Getting the user details from the database” is done and can now be tested with real data. This is an important piece of information for everyone in the team and as it is, it will be understood and known by everyone attending the daily standup*! [including the poor scrum master :0)]
- Lots of brainstorms and conversations around best architecture/solution to task ahead – with everyone genuinely interested and participating, maybe because the talks are around the goal so everyone understands the topic being discussed – (just make sure it does not disrupt the stand up, if a brainstorm/conversation needs to take place, them suggest it is done immediately after daily standup)
- When not achieved, team is supportive and jumps in to help if the delay is due to bigger workload than expected or even lack of knowledge.
- Because each members writes the goal in front of the other team members, they all become a bit more vulnerable to each other, which helps out with building trust!
- When the goal is not achieved due to impediments outside the team, then as a Scrum Master, or Product Owner, Team leader, Manager or any other process/structure related role, you have real data and facts to help you understanding what is blocking the team progress and productivity – this is really important information when it comes to start changing the whole organisational system towards it being a supportive structure for the development teams (development teams as in the teams that are developing the company core business, not exclusively software development teams)
So, give it a try if you feel that your team sometimes goes too technical and some common ground is missing. And let me know what you perceived, how it worked out and of course improvements! :)
And remember: there are no such things as ” The Best practices”, what we have is good practices in a certain context, so keep inspecting and adapting!
Have a awesome day :)
*This is really really an important point, because sometimes we all assume that everyone understands every jargon but actually the opposite is more of a fact. Product owners not always understand the bit language from developers, or even testers, and when this happens it may also happen that tests will not start immediately because people didn’t understand that the functionality is ready or even decisions may be delayed by Product Owner, because he/she did not understand the progress, hence did not trigger some needed action.