No Such Thing As a "Typical" Agile Team

June 28, 2012 by  Filed under: Management 

A while ago I was speaking to an Agile friend and brought up rotating around the ScrumMaster role. He made an interesting statement: that what I was conveying to him wasn’t the regular way Agile was being done.

Made me wonder – what is the standard for everyone working at Scrum and Agile? What’s an average Agile group? You might be thinking about Agile but can’t decide because you’re not doing software, or your team just doesn’t seem to “fit”.

I’ve trained scores of Agile teams, I’ve worked in them a lot, and I’ve had my eyes on hundreds of teams becoming more Agile. Perhaps if I share some things just around the ScrumMaster role that I’ve seen it would allow us to move this conversation along.

The first pattern I’ve seen is that the ScrumMaster is the Project Manager. The standard position. Most teams originating from a “traditional” project-oriented history possess a Project Manager and they don’t believe that they have very much to do within an Agile domain. So they grab the ScrumMaster function.

Another one is everybody in the team is the ScrumMaster. I’ve had three teams where everybody got their CSM and then they just performed the duty as-needed as team-members were open. Seemed to perform all right for those folks.

No one person is known as a ScrumMaster. People don’t want to do Scrum, yet they certainly look like they’re doing a lot of what looks like Scrum: Kanban/Story board, sprints, stand-ups, etc. In the event you ask these people who their ScrumMaster is, you are almost certainly going to receive a frosty answer. The don’t do Scrum.

ScrumMaster is an Admin Assistant. There was one customer that didn’t wish their Project Managers placed into ScrumMaster functions, but each team had an administrative assistant. So the admin received the necessary training and started to be the team ScrumMaster. In fact I discovered to my surprise that these folks did a great job! Taught me to be wonder exactly how much we over-emphasize cross-training for everybody.

Rotating ScrumMasters. Recently I recommend highly rotating the ScrumMaster position, which also is successful. I’ll totally agree with an issue my pal brought up in the course of our discussion: it can result in a little extra chaos. However in the longer term – 3 or more months – I find it assures a doubly sturdy and higher-functioning team. I’ve only coached this half-a-dozen times, so I’m no guru. Just my experience.

ScrumMaster is the BuildMaster. For development groups that are big on Extreme Programming, making the BuildMaster also the ScrumMaster makes a great deal of sense. All things considered, both jobs are challenging, and by merging the two roles you get a bit of extra cohesion. I’ve only personally seen two teams try this. If you ask me it used up the people quickly, but you never know.

ScrumMaster is really an engineer. I’ve observed, coached, and used this for ten years or longer – going back to when we were doing fast-cycle time and RAD. The guy accumulating the data is doing just that – accumulating data. There’s very little of the “fluffy” part of ScrumMaster in such a setup, but it works. Conflict resolution, negotiating, identifying obstacles and anything else are the entire team’s responsibility. Folks understand anything that entails 2 days of teaching is something a regular engineer can do.

Agile means variance

What’s a normal ScumMaster look like?

There’s a lot of variation among Agile development teams. I even had one particular team that made a piece of software be their Product Owner (It’s a long story.) While Scrum and Agile have their roots in internet-based software development, folks are using it for all sorts of things presently. At Agile 2009 I spoke on developing agility in nonstandard teams. Agile usage has just gotten broader ever since, with whole businesses, not just technology development, moving to Agile strategies.

Something I have noticed – time and time again – is usually that people are very likely to make wide generalizations influenced by just a couple of experiences. I am aware that I am guilty of this. It’s a thing I battle against.

There’s absolutely nothing about this that is geared towards my companion in dialogue at all. I absolutely don’t mean that his assertion was too broad of a generalization. I merely don’t know. If anything, I really take pleasure in the remarks. I’m also not seeking to weasel out, to back off and simply take a diplomatic position. I’ve my ideas and I’m prepared to protect them. What I’m wanting to do is frame this up, provide some context. It is really a very important discourse, the role of ScrumMaster is essential to a happy and effective Agile project team. But you ought to understand also that this is comparable to “If made to generalize, how does one approach problem X? Why?” not “What’s the right/best way?” We’ve been working in generalizations, that’s always bothersome. In Agile this difficulty just gets even worse. The instant we feel we “have it” – some generalization that works well a lot of times, a bunch of examples show up to make us change our position. Like it or not, that is a great deal more Oprah show and far less the Discovery Channel.

What I desire to highlight here is that early generalization is a considerable obstacle blocking Agile acceleration, and it’s most always identified among those that love Agile and have been in a few pleasurable Agile groups. Just like premature optimization, premature generalization is our wanting to jump ahead to a place we’re not really at yet, to form statements on what developers should or shouldn’t be doing. So yes, perhaps I am entirely off-base with my recommendation to take turns with the ScrumMaster function. The thing is that I’m not sure – none of us are. Agile is the collection of best practices concerning iterative and incremental development. It is unfinished. That implies there’s likely to be plenty of variation in the stuff you hear and read. But that’s the awesome part too: when we talk about and evaluate our experiences and opinions widely, it helps move the community forward.

So if you’re thinking Agile or Scrum might not fit for you, keep an open mind, don’t follow the directions exactly, and see where it goes. I think you’ll be pleasantly surprised.

If you’re interested in using Agile or Scrum in your team, check out Tiny Giant Books, where you can find easy-to-use e-books for getting your team started with tips on both being a ScrumMaster and setting up your Backlogs.

Article Source:

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

You must be logged in to post a comment.

Prev Post:
Next Post: