Good practices to bring the team to full potential
No one can whistle a symphony. It takes a whole orchestra to play it.
H.E. Luccock
In an agile world, having a team that is fully autonomous, self-organised and efficient is the way to go. But not all teams share those values. From the moment of forming the team until its full potential, it can pass months, even years. Every team has a different pace on this road, some will not reach the end of the road, and the majority will, eventually 😄
In SHARE NOW, my team is just one of dozens of mid-sized development teams that are collaborating closely and taking full responsibility for the part of the product that they design/maintain. The team is responsible for payment and billing part of the product (hence, we call it PayBill — very innovative, right 😄). It is 3 years old and works in agile setup, with developers, QA, Product Owner and Agile Coach on demand. During the time we faced a lot of impediments and factors that slowed us down. We worked very hard to try to find the practices that would speed up our work and reduce over-communication, that was pretty common in general in the IT market. During the time, we acquired some good practices that are more or less general for any development team, so from there came the idea to share them with others 😉
Manifesto
One thing that makes the team remarkable is the manifesto. This is a long-term vision of the team, and is helping it keep the direction and alignment. You usually put major postulates of how a team is working in a manifesto, and all decisions inside the team should comply with the manifesto.
Example of our manifesto is the following:
This visual representation of the manifesto is, of course, just a highlight, which makes it more recognisable. We have also detailed version in more textual form, used to deep dive inside topics of how our team work.
Mission
Mission is something that the team plans to achieve in 1–2 year period. It is good practice to prepare/revisit this document every quarter or half year and modify it accordingly. Also, nice visual representation is good for other teams and stakeholders. One important thing: this is not a definite goals list for a team, and it is normal in an agile world that priorities and projects change, so a mission is just a rough plan of where to go, and not all of the goals should be aligned with company goals. Also, when the team has some extra time, it can focus on some of the not finished goals from the mission document.
Similar, like for the Manifesto, we also have a more detailed mission document with an explanation of all the goals.
Decision log
Decision log is something very common for various teams. We applied this common practice and just modified it for our purposes.
In short, this measure is reducing unnecessary long discussions and infinitely returning to an already closed topic.
Whenever we have a big decision to make, affecting at least a big part of our domain, or even full domain, we create a decision log on Confluence and schedule a decision meeting for the whole team. All team members are invited to fill in their ideas on the Confluence page, and to vote for different options added there. This sparks discussion even before the meeting itself. The major thing is for everyone to prepare for the meeting, and then in the meeting we have strict structure on how long we discuss ideas and then in how much time we should make a decision.
The final outcome is to make a decision that we clearly follow, create follow-up tickets, and in future, for similar problems, we have the decision properly documented..
One of our decision logs examples:
Domain coverage matrix
This is one of the most important methods for a team with such a huge domain (we are in charge of the payment and billing part of our system). We create a matrix where we show which people are considered masters (owners) of different domain parts (services). This removes the need that the whole team needs to know the complete domain and also gives freedom to people to choose what they like, so they can focus more there.
Of course, there are some constraints:
- All domain sub-parts need to be covered by at least half of the team.
- For crucial services (or SLA1 services), at least ⅔ of the team needs to be experts.
This helps us have flexibility in choosing our mastery, and also making every part of the domain covered.
We are doing a revisit of the matrix every quarter when we add new services, talk about affinities (if someone wants to jump more in some other direction), and identifying when some part of the domain is weak (not covered enough) -> so we dedicate person(s) who will jump in more in that part.
Following, you can see the part of our matrix:
Traveling to each other
Today, a lot of teams encourage working remotely, so a large number of them are not majority of the time together in the office.
As the first distributed team in our department, we established a routine of traveling to each other as soon as we became distributed (3 years ago). We made it in the form of a workshop. The workshop usually lasts for 3–4 days and the complete team would be in the same place (one of the SHARE NOW offices, and we switch those each time).
What is important to make a meeting successful:
- We are planning an agenda to discuss beforehand.
- We create a confluence page for the upcoming Workshop at least 2 weeks before the Workshop.
- Team members are adding their ideas about possible discussions.
- We take roughly half of our visiting time on workshop items.
- From the Confluence page where agenda proposals are made, we choose some or all of the topics (depending on the number of proposals) and schedule the time slots during visiting time to cover all of them.
- We document the outcomes of each discussion and create follow-up tasks if necessary.
- Other working time is spent on “regular” pairing activities, various discussions etc.
- Team activities are mandatory 😊
Conclusion
The practices described above are not a magic bullet that will bring the team to new heights. They are just measures which, if implemented properly, can really bring the team to a better position. Of course, it is not applicable to all the different IT teams, but at least some of those practices could be proven to be useful in your organisation 😊
