Let’s imagine that there is a team that has never worked together who has a goal to achieve, so this is the scenario:
- Team A, who works in a product called B, wants to show the weather forecast in one of their dashboards, therefore the team needs to connect to a third party product API who will give them the information needed so they can show the weather forecast.
Let’s also now imagine that there is a team where the teammates have been working together for a long time already, and they also have a goal to achieve, so this is the scenario:
- Team C, who works in a product called D, wants to try during one month a new technology that could improve a lot the performance of the product D, so the team will start a trial & error phase where they will be trying new things, so there isn’t going to be a release or something that will be delivered to a specific customer.
Notice that I don’t mention any framework here, and that is the intention, I don’t pretend to be saying this is better than something else.
Team A
The team, who does not work in any framework, is supposed to deliver their goal at the end of the week, so, before they start creating all the tasks needed, we first could visualize which is their plan in terms of what they think they will be doing each day of the week. The reason for doing this is because if the team needs to think on what they will be doing, they will internally plan the week so therefore the team together will be aligning on the steps they need to follow to achieve the goal, which in consequence should reduce the uncertainty.
Team B
The team, who have been working together for a long time they are going to be starting a new “project” which is to experience during one month with a new technology that could improve the performance of the product. Again, before they start creating all the tasks needed, we first could visualize which is their plan in terms of what they think they will be doing each day of the week.
The team in the past maybe was working with Scrum, or maybe Kanban, or maybe nothing, but the thing here is that they are going to be working in a phase where the trial & error will be very present and there isn’t going to be an official release of a product for a customer.
Weekly Goal
What you see is a drawing that aims to represent step by step our week, like climbing a mountain we need to go slowly step by step till we get to the top and celebrate success.
How does it work?
How to fill up each square?
Each square represents one day of the week, the teams need to define together what they think they will be working on each day of the week, this is not a commitment, this is just the direction they would like to follow in order to achieve their weekly goals:
- “Show the weather forecast in one of their dashboards”
- “Migrate current contact form from Laravel to Symfony”
Stand Up?
You can call Stand Up or something else, but as we would do in Scrum, the team every morning take some time and do a health check of the weekly goal, we don’t want to report here, we just to make sure that the team is still aligned with the initial weekly goal and they still believe is achievable.
Oh! This is harder than we expected!
Let’s now imagine that we are on Wednesday, we are having the Stand Up and the team is still struggling with what they thought they would be doing on Monday, is this a problem? I don’t think so!
As soon as we can catch this then the better, this will be a good opportunity to really get the team together helping each other to fix whatever issues they have in order to continue working towards the weekly goal.
Should the team modify the weekly goal if it can no longer be achieved?
I don’t think we should modify the initial goal, setting realistic expectations is always a hard thing to do, we always can miss information that can affect our plans, so achieving the weekly goal will be something difficult and probably even more at the beginning, we just need to continue working in order to try to achieve the weekly goal.
It’s Thursday and we could achieve the weekly goal if we decide not to cover the code by tests.
This does not work, when I said before “need to continue working in order to try to achieve the weekly goal” of course implies to stick to our principles and values, we can not sacrifice quality for instance only because we want to achieve the goal, that is not the point, so our principles and values about how we do the things should remain intact even if we see that is not going to be possible to achieve the weekly goal.
Not achieving the weekly goal is not a failure.
Don’t get it that way, we all have expectations and wishes, if we are not able to do what we thought we would do we just need to learn from it and try to avoid the same mistakes happening again.
We achieved the goal!
This is great and we should celebrate it, take some time and celebrate together that the team was able to achieve what they wanted, it’s such a good feeling when you succeed with your plans, so it deserves a big celebration.
Retrospective
As we would do again in Scrum, we will get together and retrospect about the week, how it went, which problems we had and how we could prevent them from happening again, also very important how we can improve what we did well during the week.
Schedule
Conclusion
It might happen that there are teams who are not willing to start with Scrum or a different framework, and this is fine you don’t have to create a fight, however, somehow you need to define expectations of work and be transparent with the progress.
This weekly goal is full of common sense, and for a team that wants to achieve their goals independently of if they have been working for a long time or not, is going to be very hard to disagree with this idea.
Many thanks to Ester that has helped me to finish the post with a really good feedback!
