Organisations can benefit significantly from self-directed work teams in software development, but what do you need to keep in mind when working towards this model? Julian Holmes, Co-founder of UPMentors, presents an industry viewpoint.

Agile principles have always required self-organised teams, but there has been recent debate over whether these teams also need to be self-directed.

In my opinion the discussion shouldn’t be about self organising or self managing teams. Surely it should be more about what is going to work for your individual organisation and how you will achieve it.

What is a self directed work team?

Unlike software tools you can’t buy a self-directed work team and configure it for immediate deployment. The level of independence a team has will depend on the organisational constraints placed on it.

A company should define what it means by a self-directed work team up-front because at its purest level a team like this could potentially select members, determine remuneration, discipline team members, agree holiday leave and the list goes on.

Whilst some organisations may be comfortable with this, on the whole most would take the view that this way of working only results in anarchy.

It is therefore not appropriate for all organisations to aspire to, and it also takes time, experience and a particular culture to get to this level of maturity. For a team to achieve self direction it will follow an evolving and maturing development process, taking time and careful management.

There are the following various stages in the team development process:

  • Managed team - a group of people working together toward a common goal. The ‘what will happen’, ‘where will it happen’ and ‘how will it happen’ is set by the organisation and/ or the manager.
  • Self-managed team - a group of people working together in their own way toward a common goal, which is defined outside the team. The team decides their work schedule, in what order, when to deliver, how, to what standards, and by whom.
  • Self-directed team - a group of people working together in their own way toward a common goal, which the team defines. They will perform all of the above but in addition also have input on recruitment to the team, training, compensation, performance management, discipline, and acts as a profit centre by defining its own future.

The very nature of an industry, its complexity or its legal constraints will prevent most organisations achieving this pure level of self-directed work teams; however this is not to say that organisations shouldn’t aspire to create a roadmap for teams and the level of self management that is acceptable to the organisation to deliver business value.

So how can it be achieved?

The recommended approach is to start off with directed work teams and develop through the team lifecycle, increasing the level of responsibility as the team demonstrates its capability to handle the broader responsibilities of self management and not just the task at hand. Here are some things to consider:

  • What responsibilities will the team have?
  • What are they accountable for?
  • Do they have the support, resources and control to deliver?
  • Should all the responsibility be given on day one or should this be a staged programme based on how the team develops?

The job of management is to understand and review the development of the team within defined parameters of self management. It is also their role to support them when challenges arise, facilitate the team to overcome these obstacles and to keep external distractions at bay.

What are the challenges?

The move to an empowered team-based approach to software development is a huge change for the industry and will not be without its challenges.

Not all employees will welcome this change as it will be perceived as a threat to some, and as with any change programme it is to be feared. Many people prefer to work on their own the way they have done for many years - they may not want to learn new skills or collaborate with others.

By the nature of the industry, specialists who are highly skilled often operate in discipline silos, working in isolation to produce software that often works for them but no one else. In fact the way in which development work has traditionally been organised has been a huge barrier to the concept of a ‘one team’ or ‘whole team’ approach to developing software.

The approach now is to form teams of ‘generalising specialists’ working together across disciplines, who are highly collaborative, task-orientated, responsive to change and organised to deliver quality software quicker with cost savings - a huge plus in this current economic environment.

Such methods as agile, lean and scrum will offer a framework and principles in which to assist an organisation looking to ‘up their game’ in producing better quality software. However, it will place new challenges on individuals, teams and the organisations in terms of defining their approach, culture change, skills change, the way they communicate and their relationship with the customer.

What are the benefits?

Whilst the challenges are not for the faint-hearted, the benefits to an organisation, teams and an individual can be hugely beneficial. An individual has an opportunity to become an equal contributor, learn new skills and disciplines, interface with the customer, take responsibility and be accountable.

This all adds up to increased job satisfaction, leading to a greater retention of talent in the organisation and less churn. The team benefits from learning to address together issues such as estimation, the risk value lifecycle, prioritisation of tasks and collaborating between themselves and the customer.

The organisation will be able to deliver usable software early in the project, which can have instant benefits for their client and early commercial return for the developing organisation.

Delivering business value

Teams will focus on delivering what is important and essential and not waste time on developing software that is a nice to have, saving time and money for the developing company and the client.

The trust levels between the client and the organisation significantly increase as confidence is developed over time when workable software is produced at regular intervals and the client gets exactly what he/ she wants because they have been involved in the process of development and delivery. An enhanced relationship between the organisation and the customer will increase the level of customer satisfaction and lead to further working opportunities.

So should your organisation be contemplating this change or have started on the road to change already? My advice to you in solving the self-directed team conundrum is to be conscious and clear about what self direction means for your teams and your organisation.

Organisations that do this well will have a competitive advantage over those who prefer to take the traditional route or only dabble in a team-based approach. The benefits are there for the taking, but it takes leadership and commitment to make it work. Are you up for the challenge?