The beauty of agile software development is breaking traditional rules. Ever since the birth of software development methodologies – waterfall to begin with – engineers have been fond of identifying various roles to share their workload. The first ever to be identified was obviously a programmer, closely followed by a tester to provide unbiased opinion about working software. As development and quality teams evolved there was a need for team leaders, followed closely by project manager handling multiple projects, and delivery managers handling multiple customers. In today’s IT organisations, one can find departments of complicated roles performing specialized tasks, within a complex organisation hierarchy.
Then came along Hirotaka Takeuchi and Ikujiro Nonaka (always expect great things from Japan) and they decided to simplify things with their ground breaking “New New Product Development Game” [1] which was later refined as Scrum. Now scrum as a process identified just three core pig roles that worked towards having generalists rather than specialists on the team (somewhere a mixture of the two). I like to call these roles as Scrum Ducks since these resemble the skills and responsibilities of some of my favorite characters from DuckTales.
These ducks can be found in any scrum team and their actions speak for themselves.
Scrooge McDuck aka the Product Owner:
Scrooge McDuck aka the Product Owner is the visionary. He is the one responsible for the new ventures which can be his own or the voice of his customers. He may (not) be the gold digger, but he is definitely responsible for the return on investments. He discovers the needs of himself and his customers and decides what his team delivers.
He is DRIVEN to deliver – Decisive, Realistic, Informed, Visionary, Empowered, Negotiable.
He is often faced with the challenge to achieve multiple targets which he handles by ranking and prioritising each in his backlog. He facilitates the detailed planning of each (ad) venture and leads the teams to create software in small iterations (sprints) with features prioritized as per the vested interests.
Please bear in mind – there can be only one Uncle Scrooge in every Scrum team who is responsible for accepting or rejecting the delivered end results.
Launchpad McQuack aka the Scrum Master:
Launchpad McQuack aka the Scrum Master is responsible to land the aircraft safely by tackling every problem that comes his way. He is responsible for removing impediments so his team can deliver the desired results.
He makes sure that the scrum process is followed correctly and chairs many of the important meetings to enforce the scrum rules agreed by the team. He is responsible to ensure full productivity of the team, shielding them from any external interference and tracking the progress.
Since this role is very demanding and quite different from a project manager, an ideal Scrum Master has to be RE-TRAINED for this job – Resourceful, Enabler, Tactful, Respected, Argumentative, Integrity, Networked, Empathetic Listener, and Determined.
Please bear in mind – considering it’s a small air-plane there can be only one pilot in every Scrum team with the navigator Product Owner by his side.
Huey, Dewey, and Louie aka the Development Team:
Huey, Dewey, and Louie aka the Junior Woodchucks aka the Development Team is a group of 3 to 8 cross-functional individuals; generalists playing multiple roles as demanded by the situation (with a little help from their Junior Woodchucks Guidebook).
The Development Team is responsible for specifying work results and negotiating goals along with the Product Owner. These are self-organising teams that define the processes (monitored by the Scrum Master) to achieve the committed goals.
An ideal Development Team is motivated, collaborative, communicative, experimental, team player, and above all – Courageous in every situation.
Real-life Scenario:
Real world scrum teams might have other chicken roles associated with these which are crucial to solve other management problems like resource allocation and onshore-offshore setup. This might lead to roles like the Project Manager popping up and a Development Team which is not truly cross-functional. It’s not a failure to implement agile in cases like these, rather these challenges are fun within itself to be solved creatively and demonstrate the courageous ducks in us rather than duck out of using agile.
On one hand I’ve played the part of a Programmer & a Business Analyst within a Development Team; on the other, a Dual / Proxy Product Owner setup which is highly frowned upon. The trick is to take these simple core roles and not complicate it further, but don’t hesitate to introduce some new ones in case it’s absolutely essential. While doing so, log your experiences in a Woodchucks Guidebook that can be utilized by other (sometimes lost) ducks like us.
References:
[1] New New Product Development Game, Harvard Business Review 86116:137–146, 1986; January 1, 1986.