This article is not about the Scrum Master, Product Owner, and Dev Team. Curious? I’ll explain what I mean.
If I ask you to propose a way to organize a team that allows the team to be as independent as possible and is also capable of enabling self-management. Which approach would you suggest?
I have the feeling that suggesting Scrum as an approach for this particular situation came to your mind. Although Scrum is a very good framework to introduce the agile way of doing work it doesn’t perform very well when it comes to helping your team to be agile. It tells you what, but it doesn’t tell you how.
I’ve seen recently many teams moving away from this standard way of setting up agile teams to a more tailored solution that takes into account the company’s culture, regulations, the type of industry. I believe that agile coaches or change agents with a certain experience have acquired sufficient knowledge to create or suggest a tailored solution that will fit better the organization’s needs.
Following a generic recipe, which is essentially what frameworks are, is not your only option when it comes to enabling an agile mindset and structure. Instead, you can think and use these generic tools as a reference, cherry picking or adapting what is there according to your environment’s needs.
For instance, you should take some time to analyze and understand where are the bottlenecks, communication ruptures, etc. Understand first the environment you’re in and after think of a solution that will survive on such conditions.
Different perspectives are what you need in order to create different experiments that will allow you to really leverage agile practices inside your teams in order to get better results. I’ve thought a lot lately about many agile related learned concepts that aren’t making much more sense anymore considering the different scenarios I saw. Contexts and people changed and I believe this is one of the reasons why I’m having such thoughts and feeling.
Having the abovementioned in mind, I’d like to share a different perspective to take into consideration when trying to build an agile team. Forget about which framework you’ll use, just make sure you have three voices inside your team.
The Three Voices
If you’re serious about autonomy and self-organisation and you really want a team that “is” and not just “do” agile than pay attention to these voices.
A team without one of these three voices will not be balanced and will most likely depend on external people that speak one of the missing voices. Still, even having all the voices, there’s no guarantee that the team will be able to self-organize because voices are just one part of the equation that results in autonomous and self-organizing teams. However, having the voices will increase your odds of success.
1 – Voice of Viability
Who takes care to check if what’s demanded is viable or not?
This voice is responsible to say to the team what are the market and business needs and what are the potential solutions to fulfill these needs.
A rough example: A company that produces software designed to manage cargo ship construction, will not likely decide to add smiles to the app’s chat because that’s not what the market is demanding. It’s not a viable solution for that particular business.
2 – Voice of Desirability
Who takes care of checking if a solution is desired?
This voice inside the team will be responsible for saying if something is being desired or not but customers. In order to do that, this voice has to understand the customer world.
It’s not very hard to imagine some viable solutions, but which ones will custorems be more willing to buy? Which ones have higher changes to succeed? These are questions that the voice of desirability is reponsible to answer.
3 – Voice of Feasibility
Who takes care of checking if what’s is viable and desired also feasible?
This is the most technical of the three voices. Usually, the people that will transform the idea into something concrete – that can be consumed by users – are the ones that can express this voice and say if something is feasible or not from the technical perspective.
Make use you have these three voices inside your team, and your problem regarding autonomy and self-organization will be half-solved or at least will have higher changes of being solved.
If you ensure that your teams have these three voices inside and those voices can talk to each other frequently and in synergy, you’ll be able to build the framework you need for your team and your organisation.