As a company, we often talk about efficient, self-organized teams. We say it’s one of our competitive advantages on the market – the fact that we have an efficient team culture.
What happens most of the time is that people just nod their heads. They’re probably thinking: “Yeah right, everyone says they’re efficient.”
Having a group of talented and smart individuals doesn’t make an efficient team. It requires time and processes they must go through to become a fully performing team.
That is why I decided to explain how we turn our group of fantastic software engineers into highly efficient teams. This way, you can learn how to do the same thing for your team, and you can see what we mean when we say that we have efficient team culture.
This way, you can learn how to do the same thing for your team, and you can see what we mean by “efficient team culture”.
First, let me explain the concept of self-organized teams as we see it. It’s one of the qualities of the efficient team.
This means that, as a company, we give our teams only the general framework of work, and let them decide their specific way of work.
If your company is big and/or well organized, you probably already have software development processes and methodologies you use. In that case – we will adjust to your way of work and implement it in our project team.
However, if your company is only software-dependent (but not a software company), which is usually the case with most of our clients, you don’t want to be bothered with software development methodologies and processes. You just need your product developed.
In this case, our team’s responsibility is to set the minimum processes for work.
I say the minimum because that’s the best way to start. If we make the processes too complicated from the beginning, we’re adding unnecessary complexity. Because we have a continuous improvement culture (I’ll explain it more in detail later), we’ll be adding more procedures over time. We’ll be adding only what we need, and what we as a team agree is helping us deliver the project.
We don’t like to use pre-defined templates, procedures and ways of working because every project is different, and we want to tailor the way of work for each specific project.
Our procedures are continuous, meaning that they all happen regularly, in agreed time spans.
What are the procedures needed to turn a group of people into a highly efficient team?
There’s no magic involved here. Only good cooperation and structured communication processes. So, here are the regular activities we go through when working on a project:
Biweekly project meetings
People attending these meetings: Project Team lead, Chief Engineer (that would be ) and KAM for that project.
Before the start of this meeting, the Project Team Lead fills and sends us a biweekly project report. First, we go through the list of existing action items from the previous meetings. Then, the project KAM informs us of any new client needs or comments.
We all go through the project report together. We look for and talk about the project problems (if there are any), opportunities and risks and we make a list of project achievements. Then the project KAM reports this information to you – our client, and checks if you’re okay with it.
Each project team has a communication group in Teams, so we also have communication history to go through, when needed.
At the end of the meeting, we create a project status document that includes what is done so far, our conclusions, the list of things that we need to improve and the list of action items with defined deadlines and responsibilities.
Monthly project report
People attending this meeting: The Company’s management team (CFO, COO, CEO, CE, CKO)
This is a management meeting with the goal our keeping our management team always fully aware of what’s going on with each company project.
Before the meeting, CFO, COO and the Chief Engineer (as you already learned, that’s me) fill out a template report. It’s an excel file with many tabs – with each tab representing one project.
Thanks to this meeting we’re able to track if projects are going as planned, prevent bigger problems from arising and help teams when needed.
At the end of this meeting, the goal is that everyone is well informed, and we assign action items and set deadlines.
At the end of this meeting, we check if everyone’s well informed, and we assign action items and set deadlines.
SEMAT quarterly workshops
People attending these workshops: Chief Engineer, entire project team with their TL
This is a special and extremely useful procedure we have, so I’ll spend more time explaining it. It’s a workshop and not a regular meeting, because everyone is equally involved and we’re playing the SEMAT game. We did not invent this game, but it’s been helping us live one of our core values – continuous improvement. When we’re continuously improving, we’re improving our team’s long-term efficiency (step by step).
SEMAT is a retrospective game and it’s structured in a way that makes us analyze every part of the project. We like to say it presents a project’s DNA.
It’s crucial for the team to periodically make a pause, zoom out and get away from development to be able to see the big picture - the entire project. This game allows that, and it helps us set the right project priorities we’ll be working on in the next 3 months.
How is it done?
We have a board and a set of cards grouped in 6 alphas. Each alpha represents one aspect of the project we’re going to evaluate.
Each alpha has a set of stages which further have one or many sentences related to that project stage. Our task is to analyze each sentence and check if it’s true. Each team member must agree the sentence is true for us to be done with the card and to set it on the other side of the board.
To move the card to the other side of the board (which means that we’re done with it), every team member must agree the sentence is true.
If we don’t have a consensus about one or more sentences, we leave the card on the same side of the board and write down the spotted issue. At the end of the game we return to all the cards and sentences we hadn’t agreed on to decide priorities and set action items.
The six project aspects/alphas we go through are:
• Software system/solution
• Work implementation
• Way of working
• Team & People
As an example, alpha “Stakeholders” has a stage “Represented”. When we go through that card, we analyze these two sentences:
• Stakeholder responsibility defined, agreed, and authorized
• Way of working supported and respected
One more example: alpha “Software System/Solution” has a stage: “Architecture selected”. When we go through that card, we analyze these sentences:
• High-level architecture defined, accepted and shared
• Hardware platforms selected
• Technologies selected
This way, we analyze all aspects of the project in detail to make sure every member in the team is aligned, informed, and involved.
After we’ve gone through all the alphas and stages (through all the cards), we return to those where we had one or a few sentences, we didn’t all agree on. Those are our spotted issues.
Now we get to the most important part.
Here, our task as a team is to rate all the spotted issues based on how important they are. Each team member is assigning 3 points to the most important issue and 1 point to the least important.
This allows us to find the issues that are giving us the biggest problems. We like to say: we first like to tackle the heaviest, 100kg issue, and leave the smaller ones for later.
Also, if we were to turn all the spotted issues into action items, we might end up with 6, 8, 10 or 20 action items and we don’t want that. It’s not efficient to work on 20 things at the same time.
We want to work on 3 most important things first, to fix them fast and move to the remaining ones based on priority. Everyone must agree on the 3 main priorities for that quartal.
This is the point where most people – in work and in life – make mistakes. We often pick too many things to work on and we’re unable to set clear priorities, so we try to do everything and that leads us to burnout. Doing it this way, we avoid that common mistake.
How long does this workshop last?
When we do the SEMAT game for the first time – on the project we are starting to work on, it can take up to 3 hours. But when we do it the second, third or the fourth time (after 3, 6, 9 months) it takes less time so we’re able to finish it in 45 minutes.
When we do this workshop the second time, we have a list of the previous action items, so we first go and check what’s been done (which problems have been solved). Also, we check if something else stopped working or if a new problem showed up because it was triggered by the things we solved. This can happen and it’s important to notice it.
What happens if we don’t do the SEMAT workshop?
We didn’t have this practice from the beginning.
One of our teams was working on a project without a clear and structured retrospective meeting. They were really motivated because they were working with new, fancy technologies but they didn’t have clearly defined project processes. They weren’t setting clear priorities and were working on too many things at the same time. This way of working led our team to burnout, and we had to stop cooperation and leave the project.
It was a huge lesson for us that inspired us to make our retrospective meeting more structured. The SEMAT game proved to be a great solution.
This game can be used in other industries and with other teams as well – it’s not only relevant for software developers.
Combined with the biweekly project report meeting and the monthly management report meeting, this process is what helps us create the “efficient team culture” and live our value of continuous improvement.
If this has been useful, feel free to implement similar procedures in your company. Or if you would like our efficient teams to create software for you, feel free to contact us using this form.