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.


  1. Craig, how are ya...

    I keep trying to have a discussion about Scrum, topic being "where do the requirements, or product backlog, come from?"

    One answer I have got is that it comes from "Up-front work". Sounds a lot like what I do as a BA...

  2. 2 things:

    1) I see a triangle between the WBS, requirements, and the product backlog and traceability between the three using the WBS ID as essential. There's going to be correlation between requirements and the product backlog as things get re-prioritized. Do you implement it this way?

    2) On the pay issue, I get a little sick of the defined roles, especially when they are so close and overlap. Pay should be based on the value added. In my mind HR in general has it all wrong; we should be doing wage cuts when people are under-performing and giving raises commensurate with the value being added. Let's go to a hybrid commission model!

    So a scrum team that releases quality software in half the time another department can....that difference should show up in the paychecks!

    Josh Nankivel

  3. It would be a problem but I left salary-strictly-connected-with-role-name approach long ago. It's all about how much the company is willing to pay for work someone does, no matter what they have on their business card.

    In last company we had only one role in development team - it was called, surprise, surprise, developer. And believe me salaries was spread really wide (you could earn up to three time as much without changing a role).

    In current company approach is different - we have tons of role names which at the end of the day means the same - a developer. But it works the same - if you compare compare salary of junior programmer to senior software expert the difference is similar. We just keep changing role names as crazy ifsomeone is good enough to be paid more.

    HR doesn't have to understand and I don't really expect them to. As far as I've enough power to hire right people for decent and satisfying salary that's all OK. And I couldn't care less how their role is called and what isprinted on their business cards.

  4. Anonymous10:16 am

    Кто знает где реально качнуть Хрумер 5.0 Палладиум???
    очень надо...
    оч незаменимый инструмент для сеошника да и не только... все советуют. Помогите!

  5. Hi all, thanks for the comments.

    David - The degree of up front work yeilds different value outcomes depending on the cirumstances. New post coming up this week on that topic.

    Josh - I am not sure the product backlog and WBS need to be that tightly linked, but agree with the sentiment. In a fixed scope project I think the requirements MUST be represented in the WBS.

    Pawell - I appreciate the inclination to pay for performance but what about the principle of optimising the whole rather than the parts?