Technically Pink

In every forum where Scrum is discussed, there are the same frequently asked questions: what does a Scrum Master in an established team do? Can a Scrum Master be part of more than one team? Can the Scrum Master be an existing team member or should it be a dedicated role?

There are no one-size fits all answers to these questions, which is why they are also just as frequently poorly answered. The job of a Scrum Master/Mistress/Coach is to minimise the opportunity for failure. All the ceremonies around daily stand-ups, retrospectives and planning meetings are simply a means to that end: the tools of the trade.

This article is the first in a series looking at some of the insights into common place human behaviour that have been highlighted by 50 years of human factors research within the airline industry. The IT industry relies very heavily on people for it's success, just as the airline industry does. Failures in the IT industry are not as public or as catastrophic as an airliner crashing but the basic human behaviours that underly them are the same.

So, what does success look like, for you working on your project or product in your organisation? Is it delivering the required functionality on time or within budget? Perhaps it’s increased sales revenue or a better Google ranking? Maybe it is all about attracting good press? Avoiding bad press? Winning awards? These are the macro successes, what about the micro successes? How do you know when you've had a good day? Or when your colleagues have? The effects of failure might be catastrophic to your product or your organisation but the failures themselves won’t be spectacular and there will likely be more than one - a cascade failure.

It is impossible to foresee everything that could go wrong. Failure is inherent in everything we do and to think that there'll never be failures in our industry is foolish in the extreme. For three reasons: firstly technology is always going to be defined by state of the art; secondly there is always going to be economics involved; and thirdly there are always going to be people involved - the human factor.

Whilst it is generally outside of the scope of a Scrum Master to influence the first two. The third, human behaviour, is not only within the scope of a Scrum Master. It is the reason the role exists. Not only are no two projects and no two sprints the same; no two teams are the same, neither are any two people in those teams the same. Agile is about optimising the productivity of the people you have.

Can a Scrum Master be effective at minimising the opportunity for failure if he or she has another role within the team? No. People are bad at spotting their own mistakes, no matter how skilled and experienced they are. He or she will also have their focus divided, just when clarity is needed most: when the team is under pressure. In the airline industry, no matter how experienced the cockpit crew are, one crew member monitors the instruments and maintain situational awareness whilst the other flies the airplane.

Can a Scrum Master be effective at minimising the opportunity for failure if he or she is part of more than one team? Sure, why not? There are some great Scrum Masters out there who understand the pitfalls of serving multiple teams. The question is will your Scrum Master be effective working with more than one of the teams you have? If you cannot confidently answer yes to that question, then don't divide your Scrum Master's time.

So, what does a Scrum Master do to minimise the opportunity for failure in an established team? They devote more time to the causes of micro failures: factors such as negative training and social and cultural conditioning affect people's problem solving and decision making skills.

You’ve educated the client on the benefits of using an Agile approach to deliver the project. You’ve convinced them to sign an Agile contract. You’ve hired the best people you can get locally. You’ve selected the best off-shore partner you can and selected the best people that they can provide. In short, you’ve assembled a stella team of designers, developers and QA people. The client has met the local team. The local team has visited the off-shore team. Everyone knows everyone. You’ve worked hard to foster a relaxed, inclusive culture that promotes personal responsibility and shared ownership. The local team get it but did you check what your off-shore team’s internal KPIs are?

Working Remotely

As I've written before, I am no fan of the daily stand-up "script": rigid, time-boxed and full of wooden speeches. A coffin in which to bury the conversation that should be taking place.

The rules for the stand-ups I moderate are simple:

everybody in the team has to speak;

conversations have to be on topic, e.g. about the team's current tasks;

we use body language as our guide and move on before people stop paying attention;

no hogging the floor, when the Scrum Master says move on, we move on;

the team talks for as long as there are things to be said and people willing to listen.

Having read Gabi Steinhardt’s The McDonaldization of the Development Team a couple of days ago, I was about to leave some comments when I saw Ilan Kirschenbaum’s had written a response, The Sovietization of Scrum.

This is my response to their articles. If you’ve come here looking for a rebuttal of either article then you’d best look away now. There is a great deal of merit in both articles and the open minded amongst the Scrum community would do well to take note.

As I’ve said before, Agile is failing miserably to deliver on it’s promises. in my experience, Ilan isn’t way off with his assertion that only “… about 5% of Agile transitions become successful in a reasonable period of time”. So, whilst Scrum is not the last word in Agile any more that Toyota is the last word in cars. Scrum is the Agile brand of choice for most organisations and as such the Scrum community needs to accept responsibility for it’s part in the ongoing failure of Agile to meet expectations.

Frameworks versus Methods

As Ilan correctly points out, Scrum describes itself as framework. The point being that it is explicitly accepted that organisations should fine tune Scrum to meet their own needs.

Sadly when Gabi describes Scrum as a method, he is echoing the reality of the majority of Scrum adoptions/implementations. Namely, slavish attempts to follow what was written in a particular book or taught on a particular course as though Scrum were a method.

This should not be a surprise to anyone. As I've said many times before, in many, if not most, cases Scrum is implemented by inexperienced people working without the benefit of any meaningful support mechanisms. Most of the online Scrum user groups that I encountered have more than a healthy share of self-serving hype and far too many talking heads. People who spout the same dogma in response to almost any question that is asked. All of which only serves to reinforce the idea that Scrum is a method.

Roles versus Titles

Whilst the Sovietization of Scrum makes a nice title, superficially Scrum often appears more Maoist in character. The phrase “Everyone was a private in Mao’s army” comes to mind from somewhere. As does the image of legions of Chinese all dressed the same - the Zhongshan suit.

The lack of other roles in Scrum doesn't mean those are the only roles in an Agile organisation. It just means that Scrum doesn't define any other roles. Not that you would have to look far to find talking heads only to willing to espouse the very opposite. No matter how wrong headed they are.

As a Scrum Master I often have Scrum Master as my job title. A Product Owner might also have Product Owner as his or her job title. However, I've yet to meet anyone who has Scrum Team Member as their job title. Instead, in the role of Scrum Team Member you have designers (Yes, designers are part of the team), developers and testers whose job titles generally reflect their specific skills and experience.

Specialisation versus Generalisation

The trend towards recruiting teams of so called generalising specialists is particularly perverse. It makes sense for everyone on a team to understand everyone else's role. That's just common sense and basic respect. However, understanding someone else's role is not the same as being able to do what they do. Much less being able to do it as well as they can. There is a simple reason why people’s job titles reflect their skills and experience. Professionally that is what we value them for, their Mastery.

It also makes sense to try and limit the number of external dependencies by having independent, self-contained teams with all the relevant skills needed to get the job done. However, trying to achieve this by expecting everyone on the team to be able to do everyone else’s job is at best myopic. 

There are definitely benefits to having some level of cross-skilling but they are limited. The mindsets need to be great UX designers and great QA engineers, for example, are very different. There are rare exceptions but expecting someone to do both roles mostly results in either paying over the odds for those skills or accepting someone with mediocre design skills or mediocre QA skills or both.

Forcing people to generalise leads to a loss of professionalism and a lowering of professional standards. Coming at a time when we already have a highly mobile, global workforce with few, if any, professional standards this the exact opposite of what is needed. So, is it any wonder that organisations are failing to realise the potential productivity benefits of Agile if they take this approach? 

Resistance

Finally I want to add further weight to Ilan suggestion that “Agile is failing because practitioners do not recognize that the resistance has a meaning.” And that “Organizations that relate to this resistance as meaningful data succeed in addressing them, become successful in implementing Agile.”

As a consultant, clients frequently ask me whether or not I have experience of dealing with resistance when implementing Agile. Though they seldom call it resistance. Some clients talk of challenging environments and others are more direct and talk of difficult or opinionated people. What they mean is that they have people who are voicing concerns at what is being proposed and that they are looking for someone who can come in and some how “defeat” this opposition.

My response is always the same. My approach is to listen and to try and understand people’s motivation in voicing their concerns. Occasionally, the resistance is nothing more than a self-serving attempt to maintain the current status quo. Very often this occurs when the client has either over-promoted people or has allowed people to rot in place. The introduction of Agile then threatens to shine an unwelcome light on these people.

Most often, however, what I find is the institutional memory of the organisation being constructive and trying to warn of impending mistakes. This type of resistance often has very little to do with Agile and everything to do with why Agile is being introduced. Examples would include: parachuting in a new development team, which does happens to be Agile, as part of a power struggle between departments; adopting Agile because everyone is, even though you don’t understand it is; or adopting Agile because it’s the only way to hire good developers.

Whatever the source of the resistance, the last thing organisations should be doing is ignoring it.

Conclusion

Agile is not a silver-bullet. There are no one-size, fixes all solutions. Each organisation is as individual as the people who make that organisation what it is.

Organisations seeking to adopt Agile must get smarter about their adoptions. They need to get better at looking beyond the hype and questioning what is right for them. They need to understand what to expect as a return on their investment and what their role is in making the adoption a success.

In my experience, a "paid for resources” Agile contract model, where the client buys a number of teams for a set number of iterations (sprints) works best. This model works equally well with internal and external clients.

The selling points for the client are:

That they guaranteed a set amount of resource (skills and equipment) over the duration of the contract, with the supplier making good any shortfall in the form of additional iterations.

That they are guaranteed full control over the scope of the work.

The Product Owner is provided by the client and takes responsibility for defining the requirements at a User Story level and for accepting or rejecting each User Story at the end of an iteration.

Though not essential, it helps to define an initial backlog as part of the contract. This makes it easier to strike a balance between the number of teams and the number of iterations. Once the contract is agreed the client is free to update the backlog as they see fit.

It has a low barrier to entry, since the client can understand the contract without needing to become expert in any particular Agile methodology.

  The supplier benefits from their costs being fixed upfront. The client controls the scope but the supplier is only committed to provide the agreed resources. There is no commitment a final deliverable.