Effective teams -individual focus with Daily Goals

Hi :)
When it comes to effective teams, there’s always lots of things one should experiment, and from my experience implementing small consistent changes in both the team and also in each individual, has been the most successful approach.
I believe from my experience that one cannot expect to change the whole system without first influencing parts of it.
So, one small practice I experimented  before to keep team the aligned on the Sprint goal was trying to keep the  individuals focused on a small step towards the sprint goal, all I did was to ask each team member to write down his Daily Goal. Of course the daily goal needed to be in alignment with overall sprint goal (through the tasks), and we aimed for measurable, understandable  and achievable goal.  Examples: “I will test the user login” , “I will ensure the user login is password protected”, ” I will create the connections to the mock user database”, ” I will create the connection to the real database”…
So everyday, during stand up, the team member would also review his goal from previous day and explain if it had been achieved or not.
If not that means one of these 3 things:
  1.  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”)
  2.  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.
  3. 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.
In regards of the team emotions and reactions when using the Daily Goals, what I have noticed with using the Daily Goals practice was:
  1.  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)
  2. 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.
  3. Everyone has a greater feeling of achievement, and everyday feels like real progress towards our objectives.
  4. 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)]
  5. 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)
  6. 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.
  7. 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!
  8. 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.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s