Self-organising Teams in Software Houses

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.

Golden rule: Trust

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:

1. Do what works best for your team and what leads to the most constructive discussion,
2. Be constructive: don’t let the Retrospective turn into a blaming game,
3. Don’t believe “all is good” feedback during retrospectives: always dig deeper.

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.

Golden rule: Empowerment

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:

1. Always keep the development team in a communication loop with client (and encourage developers, designers and QAs to be very active in the communication).
2. Keep the communication transparent to everyone in the team (clients’ and ours), so that everyone has the space to discuss, and everyone has the same knowledge about the project they are working on.
3. Create balanced teams: more experienced developers (sometimes working as tech leads) tend to be the leaders of change and have the soft skills needed to start a discussion, but less experienced ones give them the fresh eye, and the excitement of discovering something new that brings sometimes crazy ideas (that turn brilliant!) to fruition.
4. Keeping team roles slightly open with room to expand helps our talents grow and keeps a healthy balance between what needs to be done and what is exciting

Golden rule: Iterative approach

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.

Roles

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.

1. Developers (specializing in different technologies)
2. Designers (UX, UI)
3. Quality Assurance Specialists (responsible for manual testing and also for creating automatic tests)
4. Project Managers (working in many different roles, depending on the project: as Scrum Masters, proxy-Product Owners, traditional Project Managers and many variations in between)

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).

Challenges

Of course, there are challenges and difficulties preventing our teams from being self-organised by default.

The key challenges are:

1. Short term projects: not every project has the time to iterate or improve processes. It’s hard to self-organize if the deadline is super short and the Client’s budget doesn’t allow for challenging the specification.
2. Maturity of the team: it is no surprise that the longer a team works together, the more improvements it can provide to processes. The projects we deal with have their business goals and time is money, so there might not be enough opportunity to iterate with this group of people.
3. Lack of initiative to self-organise, in teams or from the Client. Not every Client values feedback and expects consultancy.

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.