Search This Blog

Loading...

19 November 2009

The Scrum Team and old roles


As you know, in the scrum world there are only three roles; Product Owner, Scrum Master and Team. From observing the conversation on the internet, discussions with colleagues and observation, many teams also find a place for testers and QA people.

Business analysts seem to fall outside of the “team” into proxy Product Owner roles, or into Product Owner assistants. System analysts seem to be migrated into the team as QA or dogs bodies.

Project managers appear become product owners, team coaches or shields from organizational politics.

There are two things in this context I am reflecting on right now: My role and its changing nature, and the flat structure and generalist nature of the team.

My role began as traditional project manager, shifted gear to be about shielding the team from organizational politics (aka remove impediments) then to coaching on team processes and practices (No we can’t abandon the sprint retrospective!) and now is sliding towards requirements management.

This shift seems to be one that others have trodden before. What’s interesting is that it brings me back to where I would naturally play as a project manager; let the team do their development thing and focus on managing requirements (and the stakeholders who advocate them.)

Scrum and Mike Cohn’s planning and estimating techniques give some improved practices around team management and reporting, but I suspect that the benefit is in the order of continuous improvement rather than step change productivity.

Where I have seen the biggest improvement to team performance is in requirements management.

Firstly I love the simple elegance of prioritizing requirements with a ranked list. I can’t think of a better way of sorting and prioritizing requirements. And if you have several products in development at once (i.e. a system of systems) then your solution is a bunch of ranked lists of requirements (WBS/PBS anyone?)

Secondly, permission to release a less than optimized solution goes a long way to getting the requirements/scope problem wrangled. When you shift people’s ideas away from the best potential solution to the best path to that solution, things get done better and faster.

The other thing that is on my mind is the egalitarian ideal of the scrum team.

Here is the problem: Despite all the online noise, we are still at the pointy end of a change in the way we do business. And most people are still getting paid according to their old specializations. The HR department is potentially years behind this shift in the way we do business.

Take a look at the spread of pay for project roles here in Australia. It’s not even, and there are some solid differences between outliers.




Take for example the $76k a test analyst may be getting paid compared to the $91k a systems analyst may be paid for essentially the same work.

I know the answer; take it to HR and manage it as an impediment, but it sits in a pile of other organizational impediments and, because the team members are committed and motivated, the py imbalance tends not to stay on the top of the list.

It’s a bit of a problem, don’t you think?

Picture by to ang, with love , CC @ Flickr.