Cancelling out Broken Scrums

Does the team(s) in your Scrum or Agile implementation or look like this?

Ok so ignore the first major alarm bell of the ‘Agile Project Manager, that’s a whole other blog. Read the titles again, have you hired for or do you have these positions for your agile implementation? Hang on though it isn’t working, we’ve recruited these guys and they’re all ‘agile’, so why is our Scrum so dysfunctional? Odd isn’t it. Why aren’t we going faster? Why are we plagued with bugs? Well lets do a little experiment with sort of improper fractions.

Lets, for the sake of it, do this.

Ok, so here we have the different job titles as the numerator, and the ‘agile’ part as the denominator. Don’t worry if it’s not exact maths, it’s a metaphor*. So the next step here for me would be simplifying the improper fractions here. So…

Erm, ok.. by cancelling out the Agile part of all those job titles, it’s actually clear to see that the job titles are from ‘back in the day‘ when ‘all this were fields waterfalls’.

What does this mean? Well those roles are traditionally very silo-ed (they’re Nukes, not c***s). Developers develop, Testers test, Analysts analyse and guess what, Project Managers manage. Doesn’t quite look so Scrum or Agile now does it.

Here are a few questions to ask yourself.

  • Are they still building software and communicating in the way they always did? especially contractually?
  • Is the Scrum Master really an Agile Project Manager who is in fact in control?
  • Is the testing still happening after the development?
  • Are the testers and developers still disagreeing (politely put) over the analysis?
  • Do the developers think that testing isn’t something they do?
  • Does adding ”Agile’ to your job title or project somehow magically make that individual or the organisation more agile?

If you’ve answered YES to any of those.. you’re Agile implementation is broken. Now don’t get defensive, man up and face the facts that really, you’re only paying lip service to the terminology of agile and not actually investing in the substance,  and it’s possibly because of the mental model of the roles above. Once you can own up to it, once you do you have a chance to change it and get your agile implementation back on the rails.

Here’s the thing with agile, it’s like a mirror. No one ever blames the mirror for their own ugliness.


Possible solutions?

Here’s a little thing I do with my teams to try to address the problems of ‘job title’.

  • Get the team to individually write down the job title by which the describe themselves using their own mental mode.
  • Get them to tear that paper up and shred it.
  • Ask them to write a new mental model determined by the team as a whole.

This breaks with their traditional mental model and gives them a new identity and sense of equality and community**.




*if you’re picking holes in the metaphor then you’re missing the point altogether.

** The armed services do this, in basic training your identity is partially stripped. Same hair, same rank, same clothes, same routine. In it’s place a new team based mental picture of yourself is instilled.



Tags: , , ,

7 Responses to “Cancelling out Broken Scrums”

  1. Tom Howlett March 8, 2012 at 11:16 #

    Whilst both our developers and testers both test they do it from a different perspective, a perspective that is partially defined by their roles. I think these different perspectives within the team can be important as long as the perspectives are constantly shared and challenged as part of the collaborative process. Over time the roles become less defined as we understand and view things from multiple perspectives. I don’t think we should deny the value of (flexible) roles, the beauty of Scrum comes from the way the roles interact and self organise for the greater good.

  2. Dunc February 16, 2012 at 10:06 #

    I like the idea of challenging team members perception of identity and really see the value in it. However I do think there is a power in having mutiple hats on. When I play rugby I am a flanker, I am a back rower and I am a forward but overriding all of these I play for my team. I feel an affinity with my fellow back rowers and forwards but make sure that this supports the team rather than compromises it.

    Broken teams are ones were a team member’s first allegiance is to a sub group of that team.

    • Scrimmers February 16, 2012 at 15:03 #

      I couldn’t agree with that last sentiment more, in fact I’m sure that’s in Lecioni’s Five Dysfunctions.
      The title technique is less about allegiance and more about breaking the mental model of the silo and moving towards cross functional. Often when I do it I remind the group when they’re creating their new ‘title’ of the generalist/specialist idiom, which probably paralells your rugby positions.
      I’m happy that you’ve reminded me of the allegiance aspect, I will work that in.

  3. The Agile Fly February 14, 2012 at 14:25 #

    I love the idea of team writing their own job descriptions and then tearing them up and re-writing them. Do you get people less keen on tearing them up? I imagine some people are very proud (not to mention defensive) about their current role on the team.

    Great quote “Here’s the thing with agile, it’s like a mirror. No one ever blames the mirror for their own ugliness.” I might steal that one.

    • Scrimmers February 16, 2012 at 15:05 #

      There is often an inital hesitance to breaking that mental model, that manifests as a reluctance to tearing up the paper. Conversely some people can rip it easily and it doesn’t affect their opinion of themselves.

      I used that mirror line in a meeting I had today.. it seems to hit home quite well.


  1. Cross Functional Teams - August 20, 2012

    […] We should be helping, encouraging and doing anything we can to help our team members build the skills in areas beyond the things they are best at. Most important is giving them the opportunity and time to learn. I loathe the term ‘developer’ or ‘tester’. I feel they are ultimately self limiting. Not everyone does that but a great many do. I encourage my teams to get rid of their traditional job titles and create new ones that describes them better, you can read more about that here. […]

  2. What is an Agile PM? | - February 21, 2012

    […] agree with Scrimmers latest blog post, that within the Scrum team applying “agile” to job descriptions within the team does not solve […]

Leave a Reply

%d bloggers like this: