How to improve your team performance using agile practices
Teams are one of the most important elements of an organisation. Sometimes, a team works well together, and other times, they struggle. Therefore, it is important to identify the practices that help to shape optimal ways of working and unlock performance.
A team will not be productive by chance, or by default, let’s walk through some of the practices and ideas that can help to foster productivity from day one.
These practices are based on the ways of working of my current team, which is based on Scrum. They can be easily adapted to your agile flavour of choice.
Sense of purpose — the journey
We work better when we know that our efforts are contributing towards a meaningful goal. A team that has a clear understanding of its own goals, and how they align with the company strategy, is likely to have a strong sense of purpose.
A best practice is to always keep the goals visible, and consult them frequently. This can be achieved by having a clear product roadmap where the items are understood by the team, in both priority and strategy wise.
The items in the roadmap are the team mid/long term plan. A team has to keep in mind that plans may change and the backlog doesn’t need to be detailed. Items are explored close to implementation, the next mile.
Planning ahead — the next mile
Once the team has a clear understanding of their journey, it is important that they align the upcoming work (in the next few weeks). This short term planning will help the team to refine and understand smaller batches of work without requiring them to deep dive on the entire vision.
A best practice here is to have weekly meetings on both the business, and the technical aspects, looking at the prioritised items in the roadmap.
The next mile items can then be materialised as Epics, which will be shaped and prioritised with the product managers. If the team is working with the concept of sprints, they could be shaping one to three sprints ahead.
The Epics stories are spotlighted during meetings to clarify what and how things need to be done. Backlog refinement and grooming are common names to these meetings. At least one “what/why” and one “how” meeting per week should be enough.
What & why — immediate
Establishing a weekly what/why meeting (backlog refinement), brings the product manager closer to the engineers and is where the features and requirements are made clear. The engineers can understand what needs to be done and the value that is being added to the customer.
The primary goal is to prepare stories for the next sprint. However, it can have a secondary goal as well, which is to plan ahead (short term). When the team has cleared stories enough for building the next sprint, the time left can be used for shaping future sprints. The team can play with it. Sometimes the meeting can be more focused on planning ahead and, other times, used to prepare items for the next one. Experiment to find your team’s sweet spot.
How — immediate
Once the team now understands what needs to be done, it is time to see how to do it.
In the “how” session, the engineering team gets together and discusses technical details at a finer granularity. It is important to understand all of the tasks involved in the implementation phase, and to identify the tasks that may require a design document before implementation.
This is where the team tags tasks to be ready for development, and therefore, ready to be selected in the sprint planning. This meeting may happen weekly after the what/why, but perhaps not on the same day.
Planning a sprint — the joy
At this stage user stories are understood by the team in both technical and business aspects. The only thing that needs to be done is to do a last minute review and an estimation.
This meeting should be a lightweight one once there is nothing else to discuss other than priorities and sizing. This should represent no challenge, once the team is aware of how things need to be done. There are many things to explore here in terms of understanding the team velocity and story sizing.
Checkpoints — the health check
So the sprint is running and the daily meetings are happening as usual. From this point, the team could select a particular day of the sprint to do an extended checkpoint. At the checkpoint, the current sprint board is carefully analysed by the team to assess the sprint health. It will help to create awareness about the current state of the sprint and and highlight any issues that may prevent the sprint goal to be reached.
The daily meetings itself are checkpoints already, and people speak about highlights and blockers. But, checking the sprint board every single day can be too much. This could be done once in a mid-sprint extended daily meeting, with an extra 15 minutes.
Knowledge sharing — immediate
During a sprint many things can happen, good or bad. A meeting dedicated to sharing things like technical achievements, a new tool or framework, how a task ended up being implemented or anything that is worth sharing technically will help to spread the knowledge across the team.
A weekly meeting for engineering catch up improves collaboration and sense of ownership.
Autonomy and trust
People should be empowered to do the work they judge necessary. All the time invested into understanding a user story, from business and technical perspectives, should not go in vain.
Autonomy must not be confused with “no questions”. Autonomy comes with responsibility and a mature team would know how to identify when to regroup, clarify and proceed.
Retrospective
Few meetings may offer so much potential for transformation than the retrospective.
A good retrospective comes after a good team environment, a safe one. People must feel comfortable to be open and this is not hard to accomplish. Team must highlight the things that are worth continuing doing and reinforce all the wins from the previous sprint, especially things that are related to processes and practices, once they are reusable artefacts.
This is the place where the team sheds light on things that need attention or did not work well. For example, one of the meetings mentioned above may not be running so well, and team members may raise that and start a discussion towards an improvement, a change.
The outcome must be action items which are prioritised for the next sprint, however, they do not need to be formal tasks unless they represent a considerable amount of work. There are nice resources out there that may help with the task. A good resource can be found here.
A safe environment to be yourself and express your thoughts is key to enable productivity. This article, can give you a good introduction to psychological safety.
Celebration
A project is likely a long running thing and it has an end. To celebrate a long running thing sounds reasonable at minimum. However, the gap may be too long between the start and the end. The team needs to celebrate more frequently. Try to break the project in smaller phases and squeeze a celebration in between.
It is important to make sure that the team celebrates its accomplishments, and the project end is just one of them, the big one. A single story may deserve a celebration of any kind. A celebration may be simple and informal. However, some milestones deserve a proper celebration like a lunch or dinner.
Celebration is important because the team feels valued and re-energized for the next challenges.
I hope this article has helped you with insights for creating or improving a productive setup for your team.
