Agile Zone is brought to you in partnership with:

Dave Rooney is a veteran Agile Coach and co-founder of Westboro Systems. He has over 20 years software development industry experience and has been involve with the Agile community since 2000, working with organisations from pre-funding startups to the Fortune 15 improve their software process. Dave is co-founder of the Agile Ottawa Group, and an active write, speaker and advocate of agile methods in Canada. Dave is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Pragmatic Agile - Remember the First Value!

01.30.2013
| 1589 views |
  • submit to reddit
Everyone, I'd like you to meet Al.  He's a real person, not a conglomeration of people or a fictional persona created for this post.  Al is a ScrumMaster at a recent client... a ScrumMaster with a secret.

I coached Al and his team quite a bit for the first few months I was engaged at that client, and then to a lesser extent for the next 18 months.  That team was very high performing, avoiding a lot dysfunctions that many teams encounter when they first move to any Agile process.  Their standups were reasonably effective, their defect rate was ridiculously low, they shipped meaningful work at the end of each sprint, and they sought constant improvement.  I started working with Al's team during their second sprint, and I was told that their first sprint was an "unmitigated disaster".  From my perspective as an objective observer, it really wasn't, but such was the attitude on that team that they believed they could do much better.  And they did!

This team had worked together as a group for years, many of them going back a decade or more together.  I often saw this team sitting together having lunch in the cafeteria, management included.  That's where Al's secret lies... he was the team's functional manager as well as their ScrumMaster.

I hear gasps in the audience...

You can't have a functional manager to whom the people on the team report as the ScrumMaster!  That's a conflict of interest!

Sure, in a good number of cases I'm sure it is.  Not with Al, though.  You see, although I hadn't met Al before he became the team's ScrumMaster, I could tell that he was a servant leader.  He comes from a  technical background, but doesn't meddle with the work of the team.  Indeed, he was originally appointed as the ScrumMaster so that the team members wouldn't be burdened with the role.  Al did whatever he could to remove obstacles and ensure that the team's flow of work would be as uninterrupted as possible.  Al was (and still is) a very effective ScrumMaster.

How could this be possible?  How could a functional manager possibly be an effective ScrumMaster?  After all, the functional manager has a position of authority over the team members.  He handles their annual reviews that affect their salaries and position within the company.  There's no possible what that such a relationship could work, right?

Yes, it can.  It has worked in many teams and many organizations long before the 17 good folks at Snowbird coined the term Agile.  Are there situations where the functional manager shouldn't be the ScrumMaster?  Absolutely!  In fact, I would suggest that in those situations, though, the functional manager probably should not be the functional manager either!

Many people have assumed that there is a rule stating that a functional manager can't be the ScrumMaster for a team.  Even Al and the Product Owner with whom he worked were somewhat sheepish when I arrived, apologizing for the fact that they weren't organized "properly".  There actually is no such rule in the Scrum Guide, and the list of "services" that the ScrumMaster provides to the Product Owner, Team and Organization sounds an awful lot like the things that an effective functional manager would have been doing prior to adopting Scrum.

It all comes down to the very first and most basic of the Agile values:

Individuals and Interactions over Processes and Tools.

When it comes to determine who should fill what roles in Scrum or any other process, it should be the individual people who are evaluated, not their job title.

In another business unit at this same client, a development group decided to remove the entire layer of first-level management, with all team members reporting to the director.  The former managers became the ScrumMasters for the teams, and there was no longer a reporting relationship.  That certainly dealt with the conflict of interest issue, but wouldn't the team members still view the ScrumMasters as their superiors?

Actually, no.  Those four ScrumMasters ranged from good to excellent in their role.  They were mindful of their "previous life" as a manager, and one told me that he had to actively suppress his project manager tendencies at times.  Another said that the transition from functional manager to ScrumMaster was easy for him, because facilitation and impediment removal was already a part of his job prior to the change.  So, again, people who are already servant leaders should not be discounted or disqualified from becoming a ScrumMaster simply because of their previous title.

I have seen organizations attempt to apply Agile - be it Scrum, XP or some other flavour - as a recipe without any understanding of the values and principles.  Those are situations that are ripe for failure because the values and principles form the basis for any and all things that are considered to be practices in Agile.  This sort of blind faith in practices is what causes problems.

Consider this TED talk by Barry Schwartz about our loss of wisdom:

So, if you find yourself in a situation where a decision about a practice makes you feel uncomfortable, reflect on what value or principle the practice represents.  Question if that .  Question when a practice is being omitted, what other practice or practices will be put in place to serve the value or principle.

Don't be afraid to question why the values and principles aren't being followed. After all, it's not the practices alone that will enable you to be agile - they are the means to an end. To be agile, you have to actually think about what the values and principles mean and how they apply to everything you do.
Published at DZone with permission of Dave Rooney, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)