You hear a lot about scrum rituals and artifacts. People write books on how to transfer their theoretical frames into reality. Yet sometimes striving for excellence in inspecting and adapting might lead us to losing sight of the very essence of agile software delivery, which is the self-organising team. A culture of openness and creativity, which results in a true understanding of agility, can only be built based on trust and independence.
Easy to say, much harder to implement: rituals and artifacts have rules and best practices we can follow and which allow us to at least stay on an operational level. Creating self-organising teams, though, is a process with practically no shortcuts. The way to achieve that might be different for each team, project or Client, but regardless of the means, the ultimate goal is to give your team the confidence to consult, question and test. There are a few steps that need to be followed in order to initiate and strengthen independence in your team. The first is following 3 golden rules: trust, empower and iterate. Secondly, traditional project roles should be redefined - especially regarding challenges that might prevent your team from being self-organised.
The first step to even think of a self-organizing team is to create an atmosphere of trust between team members. No shortcuts here, no keeping skeletons in the closet. As Project Managers at Netguru, we have the tools to initiate discussion and question the status quo in our teams. The first one, of course, is provided by the Scrum framework: the Retrospective.
In most cases, we are the ones initiating the meeting and giving it some basic structure, but how it evolves should depend on the team.
There are only a few rules which apply to most teams:
Of course, there are plenty of great sources to read about leading retrospectives. I’m not going to go through the whole process, as the most important conclusion here is that a good retrospective is the first sign that your team is going in the direction towards being self-organised.
The next tool we use is direct feedback. As simple as it sounds, it is a part of our organisational culture to provide feedback to each other: as a basis for quarterly evaluation, but also as a tool for improving our communication. I personally always choose open feedback: only if we are straightforward to each other, we can keep the cooperation effective and free from conjectures. One of my colleagues once said that if you don’t feel confident about providing open feedback for someone, it’s not the feedback you should give. Only if we are mature enough to give and accept constructive feedback, we can think of real trust and teamwork.
There is no confidence and independence in a team that doesn't feel empowered. This feeling could come from the client, but also from a Project Manager/Scrum Master encouraging team members to work more like consultants than just coders. As odd as it may seem: most clients really appreciate constructive feedback (but beware of only criticising!) from development teams. Start from small points (like processes, perhaps some communication errors) that could be improved and then move on to the role of a real consultant.
Of course, not everything can be questioned. After all, we are working for our clients, and our ultimate goal is to keep them satisfied about the solutions we provide. There is much less margin of feedback for business goals than, for example, technology solutions (which we might have more expertise about than our client).
Quick wins for team empowerment we use at Netguru:
Rome wasn’t built in a day: neither will be a self-organising team. It’s great to have trust and empowerment in the team, but only by constant improvements can we grow really strong and feel confident about being self-organised. We also need to remember that the path to succeeding in self-organising is not just joy and good decisions. We fail, experiment and learn. But the key goal is to constantly improve, be brave, sometimes even crazy, and test ideas.
The team doesn’t feel good with the Jira flow? Change it for one sprint and check whether it works better. The client is not providing us with enough business background for the project? Let’s have a separate call once per sprint dedicated only to business-related questions from the team. The client is very technical and wishes to consult the technical solutions we implement? OK, let’s discuss his doubts. And this way, step by step, we achieve our ultimate goal: processes and solutions come from the team to the Client and the Project Manager, not the other way around.
Scrum knows no roles in the development team other than developer. Each team should be able to provide the complete expertise needed to meet the sprint goal. The software house reality is a bit more complex, as our teams (and skills within the project) are combined based on both needs (business goals and technical requirements) and often strict limitations (like budget and scheduling).
Therefore we are not always able to create a team with all the experts who could potentially support the project goals. What follows: our teams are by default more creative and cross-skilled than ones not determined by, for example, budget limitations. Still, the business model of a software house is based on delivering talents for our Clients’ projects, so we need to stick to some (at least formally defined) project roles.
Each role comes with its challenges and is more demanding within a self-organising team. Let’s start with developers: in an externally-organised team, their only responsibility is to write code according to the specification provided in the task by the Client/Project Manager. In a self-organised team, developers are responsible for all that + creative thinking about the implemented solution, providing expertise, challenging already existing solutions and finally for organising their own work (self-organised teams work on sprint goals and solutions to be implemented, not on a detailed pre-defined list of tasks to be closed by the end of an iteration).
Next, we have designers: our designers are UX/UI experts, but also people who provide our Clients with the user’s perspective. Their work needs to be not only creating designs, but also communicating about requirements and goals, defending ideas, and transferring feedback into design. I must say that any of our designers could easily be a key person in a self-organising team, because the specifics of their role and the Client’s expectations make them specialists in independence.
Quality Assurance Specialists are key figures in every team. Nothing should happen without them knowing about it. The difference in handling this role in directed vs self-organised teams is as crucial as it is in the case of developers. Traditionally, a QA’s goal is to test tasks according to a specification. In a self-organising team, it’s that + challenging solutions, suggesting UX improvements, tracking technical and functional inconsistencies in projects, and underlining priorities for the team.
Project Managers: even though the role itself doesn’t sound too agile, our duties may vary between teams and projects. From non-agile management through activities like time tracking, dividing tasks between team members or managing the whole communication, to 100% scrum methodology, like facilitating communication and scrum rituals, suggesting improvements, and educating about scrum. Of course, we aim to be Scrum Masters, but the reality is that our main goal is the success of the project and, for some teams and projects, the path to self-organizing is a bit longer and pebbly, and requires an experienced guide (at least for some time).
Of course, there are challenges and difficulties preventing our teams from being self-organised by default.
The key challenges are:
Summing up: a self-organising team is the ultimate manifestation of Scrum, and I strongly believe that self-organisation is a goal every team should try to achieve. Yet the reality of software houses might not always allow us to do everything we’d like. Even in an open and agile organisation like Netguru, some changes may require more time and effort. Still, we should always be trying, because the full potential that lies within our teams can bear fruit only if given the proper soil of independence, trust and encouragement. At Netguru we strongly believe in the creative power of our teams - both when it comes to creating cutting-edge technical solutions, and constantly improving our process.