It can be scary to devolve a lot of managerial and planning responsibility to teams but we’ve found lots of positives in changing the way we approach time management. Allowing teams the ability to plan their workloads, holidays, working location and client engagement has resulted in a greater sense of ownership on projects.
As a result of these changes we’ve noticed:
- Better quality of work through sense of ownership
- Better value in engagements for our clients
- Better relationships with the clients
- A reduction in the overhead around planning for holidays, etc.
It’s essential however that management are confident enough in their teams to place this trust in them.
Communicating with clients
Before a team is about to start development, having introductions with the client will prove beneficial during the development period.
Traditional approaches have been for there to be a project manager to act as the go between from developers to clients and vice versa. This has always added extra time into a project – usually time spent waiting on responses. This can lead to stop-start interruptions which normally result in developers downing tools, and starting other work to fill the gaps.
What harm is there in empowering the team to communicate directly with the client and enhance the relationship?
For starters it’ll save a bunch of time. When a developer is unsure of something, rather than risking development time that will potentially need to be backtracked later, give the client a call or IM them to get faster feedback or clarification around the work. It’s essential that the team and client can create a fast feedback cycle to reduce the potential for interruptions to the development process.
Developers will better understand client priorities if they’re communicating directly, rather than being shielded unnecessarily from them. It helps that a team is conscious of these, so that they can make decisions that add better business value for the client.
When holding standups and meetings with clients the team should keep in mind what the client’s level of technical understanding is and make sure not to just use lots of technical speak. If people walk away from a meeting not understanding what’s happened then that’s a big failing in the communication process. Potentially this can cause misunderstandings where clients and developers aren’t on the same page.
Through identifying the client’s priorities, and the constant communication, the team is well placed to shape the work for each iteration without outside guidance.
Establishing work process
Early on in building the engagement with the client, the intended work process should be discussed and explained to the client so that they’ll be on the same page as the developers when they’re introduced. Clients need to be sold on the advantages of devolving management to the team while also knowing they can reach out to others in the business if they need to.
One of the main advantages gained through this process is the ability for the team and client to plan short iterations that allow for showcases of the work throughout development. The team should be able to identify the priority for each iteration through this close relationship with the client and be able to depend on the client throughout iterations to provide feedback and guidance around any ambiguous areas.
On longer running engagements this should mean the stakeholder on the client side participates in the team’s standup and is available via the communication formats outlined above throughout the day. It’s important that developers can contact them quickly with any queries or concerns. This also helps foster a closer relationship between the client and the business.
Ideally showcases ought to be run by the development team, extra points for rotating chair duties, who should focus on the work that was defined as being part of the iteration following the last showcase. Any feedback that comes from this showcase should be part of the next iteration rather than being added to a backlog where possible. If feedback is left open you run the risk of it getting lost, the client feeling ignored, or the original issue becoming unusable and not providing any value to the client.
Establishing the business process
Clients are onboard with this new way of working. But is the team? Do they really have the freedom to do all they need to self-organise? Do they feel trusted?
We have a handbook that the entire world can see, and allows us to keep our processes repeatable and transparent.
The handbook outlines how the business expects individuals to organise things like holidays and remote work (to be discussed later on in more detail) so that the team can effectively shape their workload.
By making holidays and remote work visible to everyone via shared calendars, these decisions can be easily made by the team, and also allow the individual to make a quick judgement call on the viability of a request.
For example while we might let everyone know we want to take a week off or work from home, we only require our team mates to ok it.
Let team members communicate with one another
It’s equally important for team members to be able to communicate amongst themselves without barriers.
Where a team member is shouldn’t increase friction in communicating with the rest of the team. Our office is spread over three floors, and people are often spread out over the entirety of it and others are working remotely. Team communication needs to work for all these scenarios. This is where tooling is important for it to be a success.
Day-to-day the team need to be able to attend standup no matter where they are. Them being out of the office shouldn’t be a barrier to participation. After all, a client is going to call into these, so the team needs to too. Test out the various tools to see what works best for your team and clients and use this wherever possible.
Remote work
Lots of business are against remote work, as they’re worried they can’t see people working but it’s important when switching to self-organising teams to trust your workers to do their jobs without being watched.
When working remotely it’s key that team mates and the clients are unaffected, the individual assumes the responsibility or maintaining the everyday standard these people are accustomed to. This means both the quality of work and the actual process, you don’t want to be calling your client from a noisy place where the communication will suffer.
We feel we’ve got the correct toolset to allow for the entire company to be remote on a given day. Recently we had to contend with constant construction noise next to the office and all worked elsewhere for a day or two with no impact to the clients, workload or our day-to-day process. One of the things we do to increase people’s presence when out of the office is to drop a quick message into our chat when we’re going to be away for a period of time like at lunch.
Holidays
Beyond what we’ve outlined above the main thing with holidays is ensuring that enough of the team is still available to maintain momentum. As the team is scheduling their own holiday, make sure you don’t forget to let the client know too if there are any changes to the team. In some cases other developers can be brought in to cover.
Holiday time must be taken into consideration when planning iterations so that they can set realistic goals/targets.
On the flip side, it’s as important that the client lets the team know if they’ll be away on holiday. In these cases an alternative stakeholder should be introduced to the team who’ll be a point of contact.
Hackdays & learning days
As with holidays, since these are usually at least a day in length, the client needs to be made aware of these well in advance and reminded the day before during standup.
These normally involve the whole company, so whoever organises them is conscious that the company as a whole needs quite a bit of advance notice, at least a month.
We try and balance the frequency of these days. While we see them as valuable to the company as a whole, we don’t want clients to feel like they’re constantly taking a back seat.
Dojos
These are often recurring hourly sessions that happen weekly. These are self organised each time and if no one has an idea we don’t run them as they’re encouraged, but not mandatory.
If there is one scheduled, anyone participating is conscious of their current work load, and will only take part if it’s not going to affect any the work due to be showcased. We also try to avoid scheduling client interactions when these are taking place to encourage maximum option to participate across all teams.
Knowledge sharing
It’s essential to foster knowledge sharing as a cultural norm when enabling teams to self-organise. When people go on holiday, are ill or otherwise unavailable the team need to be able to keep functioning. To promote this we encourage frequent pairing throughout the company.
The constant switching of roles during pairing greatly facilitates technical, domain, and business knowledge to be quickly shared between teammates. It’s also a great way to bring a new team member up-to-speed with an ongoing engagement.
Before a team member goes on holiday they should be sure to handover anything that only they have had sight of, although try not to let that happen. If this information isn’t recent it’s worth looking at how communication is working across the team.
On the client side, it can be difficult to fully envision and grasp the use cases without going on site and working alongside the end users and stakeholders to understand their goals. Teams should feel empowered and encouraged to go to the client or bring them into the office to facilitate this transfer of knowledge. At the end of the day our clients know their business better than we do and that value should be leveraged.
Testing and phasing of processes
Depending on your business, introducing self-organising teams might be quite a drastic, big change to the business. There is no harm in trialling the introduction of this to a single team to begin with.
We tested this process with a single team, giving full visibility, control over holidays, scheduling iterations etc. to see how effectively it worked. This allowed us to make changes to the process, building confidence in it, before rolling it out across the company.
With processes that have been rolled out company wide, we still experiment and make changes. We’re never afraid to change processes if we think they can be better.
Don’t be against something until you’ve tried it!
Management
Devolving this power to teams doesn’t mean that management can’t be there to assist and guide teams. There is still a lot of valuable knowledge and insight that the teams can benefit from.
With the teams directly communicating with clients, it’s still important for them to know the long term roadmap of work. It’s just nice to know so there are fewer surprises for developers day-to-day.
If a manager sees that a team is struggling, then this is a good time to assist, not taking control, but offering guidance on how to proceed and communicating with the client if need be.
Hopefully the points we’ve covered will help you apply this to your teams. We’ve learned it’s essential to be open to change, realising what works for you and what doesn’t will be an important part of forming your own processes and norms around self-organising.
We’ve found these to be a good basis for Made but don’t feel that any of these are hard rules. As part of empowering your teams, allow them a say in shaping how best to find what works for them.
About the Author
Senior Technology Adviser at Made Tech
Code, coffee, cake and Eurovision. In no particular order.
