Sunday, January 13, 2013

Are you tired of being lectured by "Pure Scrum" fanatics? Some people are so quick to judge! They will tell you "that's not agile!" or "that's a smell!" when:

you have a defined Software Development Life Cycle (SDLC)

team members are distributed to different rooms, cities, or time zones

you write anything down on paper larger than a 3x5 card

you spend more than a few days planning your work, even for a large project

you don't release to production at the end of every sprint

you start requirements an iteration ahead of development

you have a management structure more than one level deep

you use MS Project to do resource planning

you work on fixed cost projects

you have a PMP certification on your resume (even if it's the PMI-ACP)

you advocate use of HP Quality Center, which is Kryptonite to legions of agilists world-wide

you perform end-of-year performance reviews

Agile friends, let's take a look at ourselves. Am I right? Are we quick to form a howling mob when we see a blogger or speaker promote any of these ideas? In a recent blog post I suggested that in an enterprise context, it is a good idea to have both a requirements workshop AND an iteration 0 period, and one responder pointed out that this suggestion was in and of itself, "a smell." I got a very unhappy reaction to another post even for suggesting that it is good to use a checklist.

Mike Cohn's official catalog of agile smells does not include any of the bulleted points I just listed. (Cohn's list is really helpful, and I suggest you all take his points seriously). And if one of the leading thought leaders in world of agile scrum can be flexible on matters of scrum deployment, perhaps those of us who are less eminent could back off a little bit too. Context matters a lot, and enterprise agile is significantly different than start-up agile, or even agile as practiced in small or medium businesses.

So let's take some perspective today from the world of rugby, an original context for the use of the world "scrum." As a random example from the blogosphere suggests, we non-athletes
quickly think we see an analogy between agile development and rugby scrum. It's "the whole team going together as a unit, passing the ball back and forth," we say. "There's No 'I' in 'Team!'"

But there is also no "we" in team, a
rugby-playing software architect friend pointed out to me. Or
"halibut." Rugby scrum is a great analogy for a set of techniques that contribute to a good strategy, but not an analogy for the whole strategy to win the game. In software development, as in rugby, scrum may be necessary, but it is not sufficient.

In rugby, scrum is not the only technique or even the main technique.

Those of you who share my lack of first-hand experience with rugby may picture a scrum in terms of a stock photo of athletes on a field.

From http://chrisdixon.net/?tag=scrum

We like to think of ourselves as gladiators, even though some of us don't even lift. But let's do a quick, rudimentary fact check.In rugby, scrum enables play, but it doesn't advance the ball.

As wikipedia says officiously, a scrum "is a method of re-starting play in all codes of rugby football." (emphasis mine) It is an elaborate version of a hockey "face-off" or a basketball "jump ball." As Ask.com best answerer "John D" says, a scrum is:

generally summoned when an error of play occurs according to the law
book. E.g. forward pass, knock on/ lost forward, free kick and any other
play that is an infringement but falls short of the straight arm penalty.

In rugby, in fact, the scrum moves the ball backwards, relatively speaking.

Once the ball is in the tunnel the hookers use their feet and legs
to 'hook' the ball backwards and so win possession of
the ball which moves back through the scrum and exits at the rear.

Scrum is a small part of rugby in the scheme of things.

In the "Laws of Rugby," "Scrum" is defined as Law 20 of 22. The Laws themselves are divided into three sections as follows:

Part 1 - Before The Match (Laws 1-6)
Part 2 - During Play (Laws 7-22)
Part 3 - Appendices: 7-a-side; Under-19; Rule Variations; Administration History

Within this structure, Law 20 comes at the end of Part 2, and the scrum is only one of several techniques described for putting the ball into play. Before you ever get to "Scrum," you take a tour through all of the things it takes to hold a rugby match in the first place, starting with preparing the ground, rules for measuring team success (in terms of scoring), overall governance structure (how to select a referree), team staffing (who gets to enter the field of play, and when), and so on. And then you get into rules around actually advancing the ball.

Just as professional basketball players allocate significant time to
practicing free-throws, professional rugby teams spend significant time
developing scrum techniques. But no professional sports team considers
itself ready to play based solely on its ability to handle a penalty situation. And note that a successful free-throw in basketball, unlike a successful rugby scrum, is a guaranteed score for the team.

In rugby as in full lifecycle software development, winning or losing may depend on doing scrum right--but first you have to be able to position the scrum on the field and know when to force it to happen.

Many games have been won or lost based on a team’s scrumming abilities —
or lack thereof. Though the structure of the scrum remains unchanged
from one to the next (unless a forward is sent off), there are several
strategy-specific elements that should be figured out prior to a game.
One such element is the pack’s ability to move the scrum around the
field.

Agile software project management is much bigger than team coordination during specific points of delivery. You need all the fundamentals, not just one skill set. You still need to start with a business case and executive sponsorship. You still need to bring in the right workers with the right skills. You need to set up a governance structure to measure whether the team is winning or losing your company's fight against time or the competition. You need to know what you want to do, and you need to know how to do it.

Mike Tindall is probably the world's most famous rugby player, partly because he married Zara Phillips, the eldest grand-daughter of England's Queen Elizabeth II. He is also well known by readers of tabloids because he always seems to be drunkenly cavorting with blondes to whom he is not married on camera and off the field. Even I have heard of him.

From http://www.dailymail.co.uk/femail/article-2020540/Zara-Phillips-wedding-Mike-Tindall-Canongate-Kirk-Royal-princess-marries-rugby-ace.html

Tindall has had a long history as a successful rugby player. What's his secret to success? He told The Telegraph in 2010:

I'm always trying to become a more complete package. Through my early
years I was more of a physical player than anything else, but what I'm
trying to do now is work on the other side, whether that is footwork or
speed, or improving my handling. I'm lucky in the sense that I have the
physical side to fall back on, but I want to get better at the other stuff.

And that's the bottom line, isn't it? Agile software development, when defined as a philosophy which values "working software" as the ultimate goal, doesn't solely require Scrum. It requires the complete package. It requires "the other stuff."

There are a lot of interesting directions for this topic to take, but the key question I've been mulling over in my own mind is this: What, if anything, do you need to do as a hiring manager at "annual review time," in order to reinforce an agile culture of teamwork without demotivating your star contributors? It's Star Trek's notion that the needs of the many must battle and win against the needs of the few! Or so it seems.

Let's talk about these issues frankly for a moment.

Punish and reward: a significant plurality of LinkedIn Agile and Lean Software Development forum members (henceforth LAALSDFMs) pointed out that only a fool thinks that the way to squeeze better performance out of an individual -OR- a team is to use the threat of punishments or promise of external rewards. As Daniel Pink's web site says with reference to his amazing book, Drive: The Surprising Truth About What Motivates Us:

Most of us believe that the best way to motivate ourselves and others is
with external rewards like money—the carrot-and-stick approach. . . . The secret to high performance
and satisfaction—at work, at school, and at home—is the deeply human
need to direct our own lives, to learn and create new things, and to do
better by ourselves and our world.

"Bah, humbug!" you say. "Idealistic twaddle!" No, seriously! It's true. Think of your own life. Have you, or would you ever, leave a job due to one year's rate of salary increase? On the other hand, have you, or would you ever leave a job or take a new one for the same salary or even less, in order to learn a new craft or increase your sense of being needed? Day to day or even year to year motivation is seldom a matter of an external reward.

Tying salary to end-of-year reviews is therefore a really bad idea. In fact, end-of-year reviews are a bad idea. This notion was also a popular one for the LAALSDFM crowd. Here I must protest.

Seriously? Never review? Are you also not giving regular raises? How is that working for you? I can picture in a small start-up where everyone owns a stake of the business that reviews and raises wouldn't be relevant. I've never personally worked anywhere that didn't have annual raises though.

Don't link review and annual raises? Again I ask, are you serious? Are you a line manager? Do you want to explain to an important member of your team that although you are both going to spend hours preparing for and conducting an end-of-year review, the result will have nothing whatsoever to do with their salary next year, their bonus, or their hopes of promotion? And worse, how are you going to justify the salary, bonus, or hopes of promotion discussion when you get around to it?

Please, be practical. If you don't do one on one reviews with people reporting to you at least once per year, please set that up. It is a very good practice under most circumstances to conduct an annual review of a person's goals, how well they did in achieving the goals, and you must certainly also discuss any related news you might have about their compensation or external rewards. Although money is not a motivator, a careless or cavalier attitude towards a person's salary is a guaranteed DE-motivator.

Okay, but you should measure people by something fair, like a 360 review by the whole rest of the team, or the actual business value the team delivered, divided by the number of team members. Sorry, no. This is not "Lord of the Flies," and we don't set compensation based on popularity with the team. You are aware that teams are composed of human beings, correct? It is also not a good idea to create competition among team members for the "revenue enhancing" projects rather than the "bread and butter" infrastructure and workflow projects that keep the lights on. As a manager, I am hugely grateful for people who enjoy what they're doing even if it isn't "cutting edge" or "high recognition."

And it's not going to work to just give everyone in your whole division the same compensation every year to reinforce how we judge "teams" and not "individuals" any more. Telling a person "we're giving everyone the same compensation this year because we only judge team performance" is both careless and cavalier, however noble it may sound to you in theory.

As a hiring manager, it is your job to work with everyone on your team at least annually to ensure that the person's employment on your team is mutually beneficial for them and for your organization. This discussion should not be focused primarily on salary, but to avoid giving offense to the employee, it must include an explicit conversation about what their salary and title needs are, and an implicit consideration by them and by you of what it would cost you to replace them in the current hiring climate, and what their prospects of flight to somewhere better might be.

Make no mistake: there most certainly is competition in this world, no matter how agile your company becomes, and that competition is for the chance to hire and retain the best workers. The cost of hiring and training a replacement even for an AVERAGE worker is something like two years worth of that worker's salary. The issue is not "how do we keep team members from competing with each other through deft use of carrots and sticks." The issue is "how do we as managers create a workplace where workers want to stay for a while?" Each person's need for recognition, in terms of title, compensation, and so on, is individual, and must be negotiated individually based on how much you need them and how much they need you, and how well you negotiate the deal.

So I hope you're never doing something really stupid like "victim rotation,"where you give everyone the same raise, except some random people. That will have people running away! Sorry to disappoint, but I'm not with you on this point either.

Give your team members some credit. If nobody is getting a raise this year, there is no need for you to pretend that the "no raise" situation is personal to the individual, in order to falsely motivate them to work harder. If your hands are tied, you need to be honest about that, and do the best you can. Not in order to motivate, but in order to avoid DE-motivating.

During the endless decades of my working life to date, I have faced the worst-case situation for a manager, and I have executed on the "pick a victim" strategy. And I have no regrets. In this case, corporate policy forced to "grade" my team members on a "bell curve" or "S curve," with the dubious result one year that on a team of six people, I could assign one "A," four "B"s and one "C." You would think this situation would cause mass exodus from my team or even my company. But it didn't. Everyone in the division understood the system, and most teams had an overt understanding that "As" "Bs" and "Cs" would be rotated over successive years. So long as this was done fairly and transparently by team managers, de-motivation was avoided. And so was motivation.

So let's go back to the original question. What, if anything, is a hiring manager in an agile world to do at end-of-year review time? I think it boils down to one "do" and one "don't."

DO: Focus on coaching individuals on appropriate goals for their own career paths, throwing your support behind them in the things they want to achieve that also work to the benefit of your team. If your company has a good structure for using the annual (and quarterly) review processes to help people reflect on where they want to go, the best time you will spend as a manager will be the time you spend working with your direct reports figuring out what their dreams are and helping them accomplish those dreams.

DO NOT: Create any unnecessary offense by acting coy about money. Make it clear what parts of a person's compensation are under your control as an individual manager (in your opinion), what parts are not, and what you've done about that. If they need additional pay because they're getting a divorce, or they want a title change to keep their morale up, they should feel free to say that, and you should work together with them to figure out what the two of you can do as a team to make that happen (or not). Are they getting in their own way? You need to tell them how to change their behavior so you can help them achieve their goals without cutting into your integrity. Are you not pushing hard enough? They need to tell you. Maybe you're being too timid.

This annual end-of-year review is a discussion between two adults, whether your company is agile, waterfall, or government-controlled process hell. It requires personal judgements. Pardon the reference, but it requires that most agile of concepts--a focus on "people" over "process." Please don't be silly about it.

About Me

Elena is a Principal Business Architect for ThoughtWorks, London. In this capacity, she focuses on transforming business architecture to better support digitally enabled retail clients. Prior to ThoughtWorks, Elena was a Program Manager and Chief Agilist for the Treasury Services vertical at JPMorgan Chase, followed by projects which measurably improved scalability and productivity in IT processes for the Corporate and Investment Bank (CIB) and the Consumer and Community Bank (CCB). In addition to business architecture, Elena’s areas of professional interest are value chain mapping, change management, and non-annoying IT productivity strategy and measurement tactics.