Each of the Agile methods includes defined roles.  Some have more, some have, less.  DSDM is the only one of the methods that makes a big deal of making role responsibilities explicit but I think this is important. To work effectively as a team people need to know what their role is and the roles of their peers. I have often had to coach teams on the demarcation between key roles on the team – typically the leadership roles, i.e. project owner, agile project manager (or scrum master) and technical lead.

Small Cross-functional teams

Agile teams are small and cross-functional.  Cross-functional means that all the disciplines are represented in the team, e.g. developers, user experience, testers, product owner, project manager, whatever is necessary. Small means there are less than 10 people of all disciplines. Bigger can work but smaller is better.

The following table outlines the roles and team composition suggested by the different methods, “Generic Agile” being the method described on this website:

I’ve described a few of these roles below. I’ve described:

• the Agile roles that are different from the traditional equivalent
• the traditional roles which are unfortunately often left out of Agile projects

Business Sponsor owns the Cheque Book

The Business Sponsor is the most senior person involved with the project. They are the project champion in the business, own the business case for the project, and are responsible for delivering the benefits back into the business. They also have the cheque book so they are the person who can terminate the project if it looks like it isn’t fulfilling its goals. They get directly involved when issues are escalated to them, but more normally they let the project team get on with delivery without interference.

Developer: Life in a different world

As an Agile developer you undertake a variety of tasks (analysis, estimating, design, coding, testing) and generally do what it takes (which is pretty much all Scrum uses for a job definition). You are Client facing, in fact client facing every day as the customer is one of the team. There is less documentation to write, unless you want it. There is stress, e.g. short time frames, but this is managed (for example, XP’s sustainable pace). On the other hand there is more visibility of your own work and progress: Pair programming (XP), Peer Reviews (DSDM), User Reviews (XP, Scrum, DSDM), Daily meetings (XP, Scrum). You work faster and produced better quality. You’re part of a team with a shared aim and shared responsibility.

Technical Lead

Most organisations I’ve worked in have had a Technical Lead for each project.  Where the organisation hasn’t acknowledged this role I’ve suggested they do so. This person is one of the Developers but has additional responsibilities.  The key responsibilities of a Technical Lead are:·

• Agree the technical architecture and ensure the architectural integrity is maintained
• Ensure adherence to standards of best practice (e.g. source code control etc)
• Co-ordinate the team’s day-to-day technical activities
• Mentor the other technical staff

This role is similar to that of the Technical Coordinator from DSDM (2002).

Product Owner: An Active Role

The Product Owner is the customer.  You are part of the team and must actively participate. You are responsible for the requirements. You must talk to other users and get their agreement, Write up the requirements (if necessary), and explain them to developers. You have a planning role too as you must prioritise and trade off requirements. During development you provide input into design and prototyping sessions. As the software is produced you must review and accept delivered functionality; you must also organise, control and do user testing. Finally you must provide user documentation and handle user training.

Agile Project Manager as Shepherd

The role of the Project Manager is subtly different when using an Agile approach. From my fairly biased view an Agile Project Manager is more a shepherd (or sheep dog) and less a military officer. There is lots of rushing around the edges of the development team but relatively little direct control of what the team does. If you merge together a description of the Project Manager, Scrum Master, Coach, and Tracker from XP, DSDM, Crystal Orange and Scrum you get:

Gather information from all stakeholders and integrate into workable plan; log estimates; advise programmers on their estimates using historical figures; log task assignments; sustain high rate of progress; make decisions; remove impediments; build and sustain team culture; ensure team sticks to process; liaise between management and team; manage customer relationships; fend off “feature creep” and other project hazards; get agreement on the prioritisation of requirements and detailed content of Timeboxes; track progress against the timebox goals/plan; collect information without disturbing the process; update plans; communicate progress; ensure that the lessons are learnt; log defects; stay calm.

Things like “remove impediments” and “build and sustain team culture” aren’t normally seen in traditional PM role descriptions. Then there are the softly, softly items like “collect information without disturbing the process” and “get agreement on …”; and notice we “log task assignments” we don’t “assign tasks”. However, when the crunch comes we must still “make decisions”.

UX Designer

My domain is the Internet and good User Experience (UX) is crucial to product success.  I use the term UX Designer to cover two related disciplines: Interaction Designers and Visual Designers.  If you’re lucky you’ll get them in the same person.

The key responsibilities of the UX Designer are:

• Understand the Product Owner’s vision for this product
• Propose a technical feasible UX design that supports with product vision with a good user experience
• Test the proposed UX design with real users in user research

UX Designers are heavily involved during Agile Pre-project, Agile Project Initiation and Agile Project Execution. The UX Designers work closely with the Product Owner to define and refine the User Stories.

The UX Designers must also collaborate with the Developers to ensure that the proposed user experience is technically feasible. A good way of achieve this is to use the Developers as the first users in user research.

Although very involved at the start of the project the UX Designer’s direct involvement may decline during the development Timeboxes.

Agile Coach

An Agile Coach helps members of an Agile Team to apply Agile practices in the context of their specific project. The coach provides feedback on the Agile Team’s current practice and helps them improve.  The best coaches have experience in applying Agile in a range of projects, organizations and industry types.

References

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.

DSDM Consortium. (1997). Dynamic System Development Method [3^rd ed.]. Tesseract Publishing.

DSDM Consortium. (2002). Framework for Business Centred Development: Handbook for DSDM Version 4.1. Author.

Schwaber, K., & Beddle, M. (2002). Agile software development with Scrum.. NJ: Prentice Hall.

Stapleton, J. (1997). DSDM – Dynamic System Development Method: The method in practice. Harlow, England: Addison-Wesley.