Tasks, Teams, and Performance

Teams exist to complete tasks. Completed tasks are a measure of a team’s performance. It is reasonable, then, that individuals are in the business of completing tasks. However, this doesn’t happen all the time on a team. There are some legitimate reasons for this. A task may not be completed because there is a lack of ability to complete it. If this is the case, your team isn’t really an agile team. As the scrum guide suggests here, your team should have all the abilities needed to bring something to your customers.

So, if you have all the abilities to deliver something of value to your customers, why do tasks get neglected? One of the reasons for this is the priority the team sets on a role. This isn’t the only reason why performance suffers, but it is certainly one of them.

The (Traditional) Purpose of Roles

Back in the industrial revolution, factories and the assembly line changed everything. Production increased, supply increased, prices decreased, and efficiency was the holy grail of assembly lines. Divisions of labor were created to ensure that lines were operating at peak production. Each member in a factory had a specific duty or role. To keep everything in order and efficient, hierarchies were formed to enforce the roles and to divvy out the tasks to the right person. Production and profitability depended on each person performing their tasks simply, and quickly. That mentality dominated and translated to a number of different agencies. It makes sense too, there is a lot of order in that system. Each person knows exactly what they are supposed to do.

In traditional software development, that order persists. An application or software is designed by a person or team specializing in design. Once completed, the design is handed over to developers specialized in building things. Code emerges from the design and then sent over to the a quality-assurance person to make sure everything works. Once the solution has been “validated” it is then handed over to the originators of the solution. Each has their role and tasks that they are to perform on a project. See? Order. But is it efficient?

Where Roles Become a Roadblock

Although the traditional approach to development offers a lot of order which you can measure, calculate, and plan, it also yields a lot of inefficiencies and dependencies. I can’t build anything, under traditional means, until it is designed. Once built/coded, that thing won’t be seen until it is tested and packaged with the rest of the solution. If you are familiar with the different types of waste in the Lean framework, it is evident to see that the traditional way is fraught with waste (waiting, transportation, and processing to be specific).

All of this inefficiency, however, is created by the concept of roles. If I am a designer, that is all I do. I design. I don’t code, I don’t test, I don’t elicit. So the tasks I can complete are automatically limited. Moreover, if I’m done with my design tasks, I’m sitting until my queue is filled with another task or tasks. My role has now dictated what I can and can’t do. I’m on a team of specialists, that operates with other specialists. There isn’t a concept of a cohesive team. thus, the role is a roadblock to completing tasks efficiently.

The New Purpose of Roles

An agile team is cross functional and cohesive. Team members should be actively seeking out tasks that can/need to be completed. Roles matter only to the extent that tasks are created, reviewed, and completed and team performance is inspected and reviewed. They shouldn’t be used as an excuse to not do a task.

The thing to remember here is that tasks don’t care about your roles. On an agile team, you should be focusing on getting things done regardless of your role. Don’t have a particular set of skills? Learn and grow so that you can help your team out in the future. Do you have a set that are consistently sitting untouched? Find out what needs to be done, and get a person on your team that can do those tasks or bring in someone that can.

The point is, be task-oriented not role-oriented and you will enhance your and your team’s performance.

Thanks for reading.

Being > Doing

David Bjarnson

David Bjarnson

David Bjarnson

David is an agile practitioner for 6 years in various capacities working specifically on software development for a number of different companies. David has his CSM, CSPO, CSP-PO, CSP-SM, and PMI-ACP certifications.

Leave a Reply

Top