How many hats do you wear?

Projects using a traditional waterfall methodology follow a series of separate, sequential steps: requirements, design, implementation, verification and maintenance.  This tends to lead to team members also slotting into defined roles: business analyst, architect, developer, tester, project manager.  When teams first move to Agile it is common that people continue to follow their traditional roles and this allows time for everyone to find their Agile feet.

So how should the roles in an Agile team be allocated?  The Scrum guide says “Scrum Teams are self-organizing and cross-functional” and this is sometimes interpreted as meaning that each team member should be equally capable of filling every role in the team.  Great in theory, but in the real world that can often lead to individuals being “jack of all trades and master of none”.  Additonally, suggesting that everyone can do every task as well as a specialist, denigrates the skills of that specialist.  A more realistic approach is team members able to fill more than one role – a developer might also undertake some UI design, a tester could write unit tests to support the developers.

Whilst working on larger projects, the cross functional aspect can be overlooked as there is enough work to occupy each role full time.   However, over the last year, our teams have been working on a number of smaller projects which in turn has led to smaller teams.  This forces the team to look at how best they can organise themselves to ensure successful delivery.  Part of our approach has been to go back to the cross functional team by getting each person to fill multiple roles.

Another option would have been to retain the larger team of specialists but only involving individuals when required.  This is both a nightmare for staff scheduling and keeping the full team up to date, whilst they work on other projects, is extremely time consuming.

One benefit of this approach is a reduction in cost.  A large part of this comes from reducing the lines of communication – there are five times as many permutations for one to one communication with a team of eight vs a team of four so a reduction in team size can make a real difference here.  Other savings are from reducing the overhead of getting all team members up and running at the start of the project.

With Agile, the role of the Project Manager is often seen as unnecessary.  In Waterfall projects, they are responsible for managing cost, scope and quality; reporting to stakeholders and allocating tasks to the team.  With Agile, the Product Owner is responsible for scope and cost; the team are collectively responsible for quality; end of sprint demonstrations are a key means of communicating progress and the team self-organise the work.  With larger projects where there are multiple Agile teams or where there are other factors such as the needs of heavily regulated businesses eg finance or pharmaceutical industries, the Project Manager’s skills are still needed.  However, even in these industries, for smaller projects, a full time Project Manager is not required (nor commercially viable) and whilst a good PM can juggle multiple projects another option is for the PM to wear some other hats within the project.

Purists may dislike the thought of the Project Manager taking a more active role, but for a small Agile project, it allows us to reduce the team size.  In recent projects, in addition to handling the normal duties of the Project Manager of managing risk, issues, change, scope, resources, and communications, I have also been responsible for functional testing.  Being closer to the coalface gives me an excellent handle on progress, issues and quality without the need to constantly seek updates.  On larger projects, outside daily stand-ups (which still take place), I would often need to have catch ups with individual team members to get greater understanding of issues we are facing.  Being an active part of the team (and not just an overhead as the developers would see it!) allows me to get real insight into progress without the need for more meetings, calls, emails.

How many roles one individual is capable of will vary but knowing team member’s secondary skills and using them effectively in projects to manage the team size can significantly reduce project costs without sacrificing the quality of the output.

Author: Malcolm Reid

A Senior Project Manager with over 20 years’ experience, Malcolm initially trained as a Chartered Accountant but decided that computers looked more fun than tax! He has worked with customers in a wide variety of industries from retail to finance, utilities to technology and most things in-between.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s