Habits of a Successful Scrum Manager -- Part 1

A couple of posts back I posted my personal definition of what I believe makes a good Manager within the Scrum Framework.  I'll repeat it:

A leader who creates and maintains an environment that emphasizes trust, personal development and transparency while protecting the team from influences that would disrupt the Sprint -- including himself.

Starting with this post, I'll share some tools that I use achieve that goal.

Today, we'll look at the One-On-One or O³.

The One-On-One is a technique taught to me by one of my former managers who, in turn, learned it from the Manager Tools guys over at http://www.manager-tools.com/.  They have a number of podcasts on this topic, the first of which can be found here.

The One-On-One is an opportunity to invest in your employees as individuals.  It requires time and preparation to be done right, but it is the single most powerful tool I know of for getting the most and best out of your direct reports.

Again, Manager Tools is the canonical reference on the topic, so I'll just outline the process here.

The One-On-One is a somewhat informal half-hour meeting with each of your direct reports, scheduled at a regular interval and time, preferably weekly.  The meeting is divided into three ten-minute sections.

During the first section, the employee can talk about anything that is on his or her mind.   It doesn't have to be work related, though in the earlier sessions it typically will be.

During the second section, the Manager shares observations, instruction, corrective actions, etc.  Most of the items that a Manager discusses are items that were collected over the week that didn't require immediate action.  Collecting those items together allows them to be discussed in a comfortable setting and without interrupting normal work flow or causing Context-Shifting for the employee.  As anyone working with Software Engineers should know, Context-Shifting is a major productivity blocker.  Of course, there are often things that need to be discussed now, but most can wait for up to a week.

The last ten-minute section is devoted to the future: your employee's self-development, promotion plan and the achievement of established objectives.  This section serves as a constant reminder to the employee (and the Manager) that growth should be on-going and it keeps the employee's objectives in front of them.

Many Managers, after hearing about this, will immediately argue "I don't have time to spend five hours a week talking with my direct reports!"  The truth is that you don't have the time not to!  What you learn from your employees during an O³ will help you better understand how your teams work and what problems need to be solved.  Things come out in an O³ that, for some odd reason, never make it into the Daily Stand-Up.  And the O³ is the primary tool for building trust with your direct reports -- assuming you aren't otherwise doing things that would undermine that trust.

Initially, it's an awkward meeting.  The best thing you can do is expect it to be awkward, tell your employees that it could be awkward and then do it anyway.  After a few sessions, the walls will drop and the awkwardness will go away.

My current Scrum Team not only expects their weekly One-On-Ones to happen -- they look forward to them!  As an example, a couple of weeks ago, one of my Software Engineers, who was having a difficult week, told me "I can't wait for our One-on-One -- I've been saving up for it."  He then waved a sheet of paper with a list of items on it.

If you aren't doing One-On-Ones, I strongly advise that you listen to the Manager Tools podcasts on the subject.  They've seen dramatic changes using this single tool -- and so have I.

Scrum Glossary Added

I've added a Scrum Glossary to the site.  It's something I've been planning to add from the beginning, but didn't have time to get started until now.

Some of you may have noticed that there is some inappropriate capitalization in this blog.  This is intentional and should be considered a "domain thing".   Within the domain of this blog, certain terms will (or at least should) be capitalized that are defined in the Scrum Glossary.  I will do my best to link the first use of any of these terms in a post to the Glossary and, over the coming week or so, will add links to the existing posts.

Please use the comment tool below to let me know if this is useful or if anything in the Glossary needs refinement.

The Scrum Manager

One of the lesser-discussed roles in the Scrum universe is that of the Scrum Manager.  This can be a Software Development Manager, (who supervises Software Engineers and Quality Assurance personnel), a Software Engineering Manager or a Quality Assurance Manager.

The reason this role is not discussed often is because Managers are Chickens -- people who are involved in the process of delivering software, but who are not making the personal commitment to a Sprint's completion.  Scrum literature doesn't tend to focus on the Chickens.

While many Managers believe that they should be considered members of the Scrum Team and treated as Pigs, their job role disqualifies them: their presence on the Team would invalidate the Principle of Self-Organization.

That's one of the reasons I started this blog -- to talk about the role of Managers in Scrum.

So where do Managers fit into the Scrum framework?  Explicitly, we don't, because Scrum is intentionally "incomplete" or under-defined, both to emphasize the parts of the framework that are defined and to remind us that Scrum is still an Agile process and requires customization on how the remainder of the structure gets built.

So the formal definition of Scrum appears to leave Managers out of the picture.  That doesn't mean we have no role in Scrum, it only means that Scrum doesn't define it.

I won't call it a series, but for the next several weeks, the bulk of the posts I'll be making will be related to how I see my role as Software Development Manager within the Scrum framework.  Think of this as an introductory post.

I'll be fleshing this out with specific practices over the next few weeks, but for now, here is the core of what I believe makes a good Scrum Manager: a leader who creates and maintains an environment that emphasizes trust, personal development and transparency while protecting the team from influences that would disrupt the Sprint -- including himself.

Weekly Story Sizing

The standard Scrum framework prescribes a Release Planning ceremony with a recommended time box of four hours to two days.  And this ceremony, when performed properly, works as one of the major columns in the Scrum architecture.

The problem for many teams is that it's hard to keep the attention of a team for two days on a single task -- and it's often difficult to schedule a quarterly two-day meeting.  This varies from team-to-team and company to company.  Some can facilitate the traditional Release Planning time box easily, where others find it much more difficult.  And as a result, unfortunately, many teams drop this very important structural element.

One of the groups I worked with was experiencing that pain, and was heading in the same direction of just dropping the ceremony.  I proposed we keep the ceremony but look for ways to make it work.

Those of you who are familiar with it, know that the great majority of the time spent in Release Planning is spent in Story Sizing.  For a typical team, a two-day Release Planning meeting is comprised of an hour and a half of presentations by the Product Owner with team and stakeholder input -- followed by over fourteen hours of Story Sizing.

My plan was to separate Story Sizing into a separate ceremony, leaving the rest of the Release Planning agenda intact.  This change allowed us to still "do Scrum" with only the timing and frequency of the Story Sizing task altered from the original framework.

Coincidentally, about two months after we successfully separated Story Sizing from Release Planning, I found a couple of blog posts from Scrum Masters who had come up with almost identical answers to the problem.  And about six months later, a Scrum Extension was published that documented the variation as well.

Here's what we do:

The Product Owner, who is also responsible for the Release Planning Ceremony, schedules a weekly Story Sizing meeting that lasts exactly one hour.  For our group, one hour a week was sufficient to keep our Backlog maintained and the relatively short time period helped focus the team on quick, from-the-gut sizing.

During the meeting, the Product Owner presents the highest-priority story in the Backlog that has no size to the team.  There is a brief discussion of the story and any refinements that might need to be made to it to make it sizable.  The team then plays a round of Planning Poker to determine the size of the item.  This process is repeated with the next-highest un-sized items in the Backlog and continues until we run out of stories or run out of time.

This has worked very well for teams I've worked with, and it has some nice advantages in that new stories that need to be brought into an on-going release don't require a special meeting in order to get sized -- they get sized as a result of on-going process and are normally ready before the team schedules them into a sprint.

I would note that teams starting Scrum should not try this first!  Always run the framework in its entirety and get some experience with it before seeking alternatives.

Also, this meeting is not the same as Backlog Grooming.  That is an additional process that is often employed by Scrum teams, but it is not the same as Weekly Story Sizing.

The ScrumMaster Manager

One of the most undesirable, but often implemented roles found in organizations is the ScrumMaster Manager.  It's usually the result of companies believing that they can't afford to have an independent ScrumMaster role and interpreting the role as a supervisory position.  It's also sometimes just the result of having only a limited number of staff available combined with a strong desire to implement Scrum.

In my case, it was the latter.

Wearing these two hats is very difficult, especially since it's hard for your team members to distinguish between the Manager and the ScrumMaster -- and for the Manager to know that he needs to shut up and be a ScrumMaster.  Over the past four years where I've had the combined role -- and believe me, I've tried hard to rid myself of it -- I've had to develop a set of skills that let the ScrumMaster clearly shine through when the Manager needed to take a back seat.

It's not a perfect marriage, and, quite honestly, it's one that should always be looking for a divorce.

I've been able to make it work, to a degree -- I'll never say it really worked -- by creating an environment of trust not only between my team members, but between each individual team member and me.  The most valuable tool for doing that has been my weekly one-on-one meetings with each team member.

That level of trust is what has made it possible for me to still act as ScrumMaster during team retrospectives.  But there again, it's been a hard role for me.  My natural bent as a Manager is to contribute and steer the meeting that I am officiating.  But as the ScrumMaster, my role should be more in line with a Master of Ceremonies -- keeping the team on the agenda, but not steering the direction of the conversation.

Even though I've done it, and with a significant margin of success, I think the blended role of ScrumMaster and Manager is a Bad Thing.  It's another one of those Agile Smells to be avoided.

Why do I mention this now?  I just read a good article on Len Lagestee's blog called "A Managers' Guide to Attending Agile Team Events".  In it he tells Managers "Don't attend [Sprint Retrospectives], ever."  I really wanted to kick at the goads and say "but... but.. but...I've made it work!"  My experience is the exception but I also know that my blended role has interfered with the retrospectives, though not as drastically as it could have.  Even so, in my remaining time at my current blended role, I plan to step away from the retrospectives.  My team is certainly mature enough in Scrum to do it on their own, and has in the past when I was the SM for multiple teams running simultaneous Retrospectives.  Len's advice is a good wake-up call -- and advice that I would have given to anyone else... just not to myself.  Sigh.  Sometimes you really can't see the forest for the trees.

Once again, it's time for me to Be Brave and Do What's Right.

Do you need to be brave as well?

Scrum Time Boxes Visualized

For a couple of years now, I've used a diagram created in an Excel spreadsheet to explain to new team members how the various Scrum time boxes interact.  Here's a screenshot (click to enlarge it):

The columns in the SPRINT portion of the diagram represent work days.  It should be noted that a Scrum work day doesn't necessarily start in the morning -- it starts with the Scrum.

Feel free to use this image in your team training.

If you don't recognize the "Story Sizing" ceremony, it's something we do a bit differently from traditional Scrum, but that has been adopted by many organizations.  We came into it organically before I saw mention of it in other Scrum literature.  Perhaps that will be the topic of a future Scrum Now!

Don't be afraid to make course corrections

About two years ago, I made a change to our Daily Scrum.  Instead of having each person answer the Three Questions*, I had someone volunteer each day to M.C. the Stand-up and call off the stories that were currently in-progress.  Each person who had worked on the story since the last Scrum then answered the Three Questions in relation to the current story.

This was a Scrum Extension** that was proposed sometime back called the "Feature-focused Daily Scrum" and it seemed like a good idea for mature Scrum teams.  And the truth of it was that for well over a year, this "advanced" format worked very well.

Recently, though, I'd noticed that I was getting less and less input from some of my team members under this format.  Our Scrum was starting to feel stale.  On top of that, the team dynamics had changed significantly and I had some new people who were getting their first real exposure to Scrum.

It was time for a change.

In our Sprint Retrospective I announced that we would be going back to the classic Scrum format where each person answers the Three Questions for all of the work they did since the last Scrum.  This was greeted with some minor support from my developers and, oddly, disdain by my QA personnel.

But this was a Scrum Master decision, not a team decision -- that's the nature of some procedural things in Scrum -- and I asked the team to try the classic format for a Sprint.

And it worked.

Everyone is contributing again and I'm getting more interaction than I got before.  Oddly, the perception of the team is that they are interacting less under the original format, even though the meetings are running about 2-3 minutes longer.  We discussed the change after the trial period at the next retrospective and, for the most part there was enthusiasm for the change.

Scrum requires that you and your teams be brave.  You don't bully, you don't command, but you often have to be brave -- even if it means admitting you were wrong or that the environment has changed and left you behind.  That's Agile.

-------------------
* Three Questions: "What have you done since the last Scrum?" "What will you do today?"  "What roadblocks are in your way?"

** Scrum Extensions are a now-maligned idea where Scrum.Org was hosting moderated white-papers on extending Scrum.  This practice has been discontinued in recognition that Scrum should be intentionally simple and incomplete -- a framework that teams fill in with the processes that work for them.

Bad Coffee, Good Will

During the course of our most recent release, my team decided to use the theme "Coffee Flavors You'd Never Want To Try" for naming their sprints.  (We try to make sprint naming fun.  Can you tell?)

The team came up with some absolutely disgusting coffee flavors: Salmon Roast, Moldy Sunrise and Pickled Onions, to name a few.  Toward the end of the release, I thought it would be fun to make these coffee flavors a reality.

I bought some 1 lb. kraft paper coffee bags, the kind with the window on the front and the metal twist tie at the top.  I also bought ten pounds of roasted coffee beans in bulk.  I put a pound of coffee in each bag and then, with the help of Bing Image Search, created a label for each of the coffee names my team came up with.

The bags were put on display in the conference room where we had our Release Retrospective and it was a great surprise for most of them.  (I'd let one of my guys in on the idea weeks earlier, but he had no idea I'd gone through with it.)  Everyone got to take home a pound of coffee that they'd named.

This was great fun, the team loved it, and I spent just under $100 to get it done.  The photos below were taken in the conference room just before the team showed up for their retrospective.

What fun things have YOU done for your team's Release Retrospective and Celebration?  Use the comments below.

Seven Ways to Fail at Scrum -- Part Four

Here is the final installment of my mini-series on bad Agile smells I've experienced.

Smell #6: Not Performing All of the Scrum Ceremonies

Scrum has a number of time-boxed events, collectively referred to as Ceremonies, that must be performed in order to support the framework.  Omit any of the ceremonies and you aren't doing Scrum.  I know there are those of you reading this that think I'm a purist and that some of the things we do in Scrum are only marginally useful and therefore a waste of time.  But the truth is, if you are doing them correctly, none of them are a waste of time, and together they make a strong and well-supported framework on which you can do good development.

Here are the Scrum Ceremonies:

• Scrum (aka: Daily Stand-up)
• Sprint Planning
• Sprint Review (formerly called the Sprint Demonstration)
• Sprint Retrospective
• Release Planning
• Release Retrospective
• Periodic/Weekly Story Sizing (this only applies if you don't do sizing as a part of Release Planning)

Every team I've worked with, even before I was familiar with Scrum, I had a standing rule: "I will never commit my team to unnecessary meetings.  If a meeting has limited or no value, it gets eliminated.  If you think a meeting is unnecessary, tell me and we'll discuss its elimination."

The six/seven Scrum ceremonies are all necessary.  But here's how it tends to break down when people try to do Scrum buffet style:

• All teams do the stand-up.  Unfortunately, a lot of groups think that by doing just this one thing, they are "doing Scrum".
• Most teams do Sprint Planning, since it's an obvious necessity.
• Slightly fewer do the Sprint Review, with those dropping out thinking that it is an unnecessary formality.  "The customer will see the product when it's shipped."
• More teams drop the retrospective, since "it's just going to be a bitch-fest, anyway."
• There's then a big drop in groups performing Release Planning.  The excuses start mounting up: It's harder to coordinate; it takes time away from "productive" work; "We really don't know what's ready to work until we get to sprint planning, anyway."
• And there's a huge drop in groups doing Release Retrospectives.  Again, it can be difficult to coordinate.  "Besides, we covered all that in the Sprint Retrospective, right?"

My teams have always done the morning Scrum, Sprint Planning, Sprint Review, Sprint Retrospective and Weekly Story Sizing.  If I tried to drop any of those ceremonies, there would be Hell to pay because my teams know those ceremonies have value.  We worked as a team to ensure that they were (and are) valuable experiences.

We dropped the Release Planning and Retrospective at one point.  Not intentionally, but because those two ceremonies are hard to coordinate at times.  Especially since Releases are only marginally related to Sprints and Releases can overlap, with work beginning on a new release often weeks before the current release is delivered to Software Configuration Management.  I realized after almost a year of not doing them that I wasn't doing Scrum -- I was missing two important tent poles.  So I bit the bullet and worked with my Product Owners to re-introduce them.

The result was amazing -- and it shouldn't have been.

Almost to the person, my team members came to me afterward and told me how good these meetings were; how they improved their perspective on the on-going direction of the product; and why weren't we doing these before?  My team members aren't gluttons for punishment.  They tell me when they've been to a bad or worthless meeting.  And here they were, again, almost to the person, telling me how much they appreciated these "new" meetings.

Scrum is not a buffet -- don't do it a la carte.

Smell #7: Not Respecting the Sprint Time Box

The following conversation actually occurred, though it may be a bit paraphrased.  Some of you may think I'm making this up; I assure you I am not.  Others may recognize it because, they too are not respecting the time box.  

The participants in this dialog are a Product Owner from another set of teams in my company, denoted as "PO", and me.

PO: It looks like one of my teams is going to have two stories incomplete this Sprint.  It's so frustrating.

Me: I understand, but they'll get finished at the start of the next sprint, so they'll still make it into your release.

PO: Oh no.  They have to stay unfinished for at least another sprint.  Our next sprint is already full.

Me: (doing a coffee spit-take) Excuse me?  How can it be full already?

PO: It's full.  There's no room for those stories to be finished.

Me: Oh, so these stories are lower-priority than the stuff that's already in the sprint?

PO: No, they are higher priority.  This keeps happening and it's really annoying.

Me: (doing spit-take number two after foolishly sipping my coffee again) WHAT?  I'm missing something here.  Why are higher-priority, unfinished stories not at the top of your next sprint.

PO: Because the sprint has already been planned.

Me: Already planned?  Today is Friday.  Your next two-week Sprint starts on this upcoming Wednesday, right?

PO: Yes...

Me: So...  (realization dawns) ...when did you do Sprint Planning for next week's Sprint?

PO: Two days ago, on Wednesday, before the team realized these stories wouldn't get finished.

Me: (safely not spitting more coffee on my monitor because I saw it coming) So, let me get this straight, your TEAM is doing Sprint Planning a week before the sprint starts while the current sprint is on-going?

PO: Of course.  There's no time to do it any closer to the sprint -- we'd be in a whole day of meetings.

Me: (More coffee on the monitor, darn-it) You realize that it takes the same amount of time whether its on the same day as the demo and retrospective or not, right?  I mean you don't actually lose a day.  You just allocate it differently.

PO: You guys do something different?

Me: (Feeling faint.)  Yes.  We do Sprint Planning for the new Sprint after the Sprint Review and Retrospective for the prior Sprint.  That way we automatically transfer unfinished stories to the top of the new Sprint if we have to.

The good news is that, as a result of that conversation, the Product Owner's teams reorganized so that the Sprint Time-box was no longer intermingled with the prior sprint.

The Time-boxes were created so that Scrum processes work.  Respect them so that you can work, too.

Seven Ways to Fail at Scrum -- Part Three

Here is Part Three in my series on bad Agile smells I've observed.

Smell #4: Secret Calculations for Velocity

I'll admit, when I heard about this one, my jaw literally dropped wide open with a "Whaaaaaaa...?"  I don't think I even added the terminal "t" to the word.  This is one of those bad smells that you can't even conceive where it came from or what motivated it.  I want to think it's unique to the company where I saw it, but as Solomon once mused, "there is nothing new under the sun", so I'm sure it's happened before and may still be happening elsewhere.

In this particular company, one of the managers is responsible for "calculating" the velocity for all of the teams working on the product.  I've quoted the word "calculating" because, while that's what she says she's doing, I'm suspicious that she's actually creating velocities as a way of motivating her teams.  I should also note that this product group is guilty of Smell #5 below -- correlating story points directly to man hours.  The Managers have unilaterally decided that one Developer working with one QA Engineer during the course of a sprint defines eight story points -- essentially assigning a velocity of four points per person per sprint.  The velocities the teams are challenged with (and I use that term intentionally in this case) tends to be slightly higher than that raw calculation, which fosters my earlier suspicion that the secret calculation is aimed at pushing or motivating the team.

So why is this a bad smell?  Because it hits hard against two core principles of Scrum!

The first violated principle is that of Transparency.  Velocity should be a simple matter of looking at a team's average story points over the most recent sprints.  It's not hard to calculate and it should be something transparently presented to the team as a statement of the team's current performance and predictor of future performance.  In this product group, velocity is being used as a whip against the team instead of as a tool for Product Owners to predict what features are likely to fit into the next release.

The second principle violated is -- you guessed it -- self-organization of the team.  (It's amazing how many bad smells come back to a violation of self-organization, isn't it?)  The team uses velocity as one of its indicator tools when preparing a sprint during the Sprint Planning ceremony.  Combined with predicted task hours, velocity is a way of sanity checking whether or not the team can complete the work it is about to commit to.  If a team tries to commit to 40 points of work when its established velocity is 20 points, the Scrum Master needs to be throwing flags on the field -- even if the tasked hours look feasible.

Smell #5: Correlating Story Points Directly to Ideal Man Hours

This smell is pervasive.  It's hard to get past.  We all want to quantify our work in terms of time.  It's natural.  We've been asked to do it all our lives.  

"When will you be finished?"  

"What time can I expect you?"  

Relative sizing isn't hard, but it's hard to break ourselves from the habit and mindset of predictive hours.  It's especially difficult for individuals with a scientific or pedantic bent; less so for those who are more kinesthetic.  This is complicated by the fact that we see the Product Owner (correctly) using our Velocity to project features against a release date, so, as developers, we see another argument to correlate back to time.

But despite what you might read in Henrick Kniberg's otherwise excellent and seminal white paper "Scrum and XP from the Trenches: How We do Scrum", story points need to be about a from-the-gut feeling regarding a story's size and not an estimate of time.

The psychology and reasoning behind why we should size things from the hip and relate them to the bigness of a well-understood story is a topic way beyond the scope of this particular series, but it has been exhaustively discussed throughout the Scrum literature.  For the purpose of this post, let's just take it as given that relating story points to any unit of time during the sizing phase of a story is a Bad Thing.

If there's curiosity about sizing expressed in the comments, I'll consider making a more in-depth post.

Seven Ways to Fail at Scrum -- Part Two

In my previous post, we took a look at two of the "bad Agile smells" coming from product groups I've observed.  Today we'll look at another.

Smell #3: The Quality Assurance Wall

The QA Wall is essentially any structural practice that tries to maintain one or more levels of separation between Quality Assurance Engineers and Software Developers.  It's based in Waterfall SDLC and is a strong odor for any Scrum team.  

The wall can take many forms: a separate QA team, who plans its work in its own set of sprints away from the development teams;  QA Engineers who are "embedded" within a development team, but have no input into the development process; the list of different forms can be quite extensive.  Most of these practices cite a perceived need to keep some distance between Development and QA as an audit control.

The teams I'm observing currently have a different form of wall:  QA maintains its own source control rail (there are no branches, so it's not a trunk) that developers merge their code into from the "Development trunk" as stories are completed.  Testing cannot begin until code has been built from this QA rail and the final product delivery is made by QA from a build using the QA rail.  There is no Continuous Integration environment in place.  (CI is technically an eXtreme Programming practice, not Scrum, but it is a highly recommended practice.)  Additionally, the QA teams' cubicles are all co-located -- adjacent to the developers, but not mixed in with them.

As you can probably imagine, keeping the QA rail and Development trunk in sync is paramount and involves a lot of extra, and I would argue unnecessary, labor.

What makes this a bad smell for Scrum is that the effort involved in keeping the QA rail updated generates and reinforces bad practices on the part of the Developers.  They delay merging their changes because it is such a painful process.  As a result, QA Engineers don't get their hands on most things until near the end of the sprint and any mistakes made in the merge process by the Developers create build headaches for the QA engineers who aren't build experts to start with.

This practice, combined with the lack of inter-mixing of workspaces and the issues resulting from Smell #2 all combine together to reinforce the "us vs. them" mentality.  That mentality is causing bad blood between the two groups and has completely inhibited any environment of trust.

Contrast this with the Scrum teams I've run, which have had amazing levels of camaraderie, trust and quality software releases.  On those teams, QA performed most of their testing from the Development staging servers, which were staged automatically by the Development build server from the Development source code trunk. Stories are tested often the same day they are checked into source control, or by the next morning at the latest.  When possible, the QA staff were sitting mixed-in with the Developers, who were available to help the QA engineers with coding questions.  (The majority of my QA engineers have been Computer Science graduates doing a mix of manual and automated testing.)  When my QA staff has been remote, we've fostered an environment of "Instant message often, call on the phone more, email less" to keep people in constant contact.  When a current story fails acceptance testing, it's turned around to the Developer immediately by talking to them over the low cubicle wall or by a quick phone call.  My QA staff has as much input into the development process and tweaking of user stories as anyone else.  Retrospectives, as a result, are honest, frank and based on the ability to trust the other members of the team.  My QA people, who all report to me, actually like the Developers they work with.  There is no "us vs. them".  

In summary, a good Scrum team is able to perform QA reliably and faster when there are no walls in place.  Faster QA means earlier detection of software faults, faster turnaround of defects and a higher-quality product.

Bottom line: Don't create the QA Wall!

Seven Ways to Fail at Scrum -- Part One

I've watched and participated in Scrum teams that were successful -- teams that were self-organizing, promoted trust, delivered regularly and produced a high-quality product.  But I've also seen teams "fail at Scrum".  The quotes here are intentional, because, in most cases, it was not Scrum or Agile that failed, but the teams or the environment around them tried to do Scrum-like things, but failed to actually do Scrum.

The simple truth of the matter is that Scrum works -- but you have to actually do Scrum to make it work.  Doing things half-way or picking and choosing the parts of Scrum that seem palatable to you is destined to fail -- because Scrum is a framework, a support structure.  If you don't include all the pieces, or cheapen some of them, the structure falls apart.  Most groups that have seen "Scrum fail" have actually failed to do Scrum.  This isn't to say that Scrum works everywhere and in every culture -- that kind of thinking isn't Agile -- but it is a framework that works well when the environment is suited to it already or can be tailored to it.

Over the next few days I'll present seven things I've seen in product groups that claim to be doing Scrum, but aren't.  Elsewhere in Agile literature you'll see these things referred to as "smells" -- things that people do in the name of an Agile practice, but that just smell wrong.

Smell #1: Teams formed by Project Managers/Product Owners

I've seen a few shops where the members of Scrum teams were chosen by the Product Owner so that the PO essentially had a go-to team where they could park their pet or customer-sensitive features.  This resulted in a sort of A-Team where all the high-visibility and cherry features went while the second-string teams got all of the defect work and "add a new field to page X" stories.

This is a Scrum anti-pattern, plain and simple.  It flies in the face of the core concept of Scrum: the concept of self-organizing teams.  Team composition should be organic and the teams should be organizing themselves around the whole of the product backlog.  Sure, an initial set of team assignments by the team lead or Scrum Master makes sense with a group that is just learning Scrum, but those assignments should be balanced, mixing levels of experience and proficiency throughout, and those assignments should be considered temporary.  While team stability is important for establishing and maintaining velocity, team members should still feel the freedom to move among teams on a single product to find the mix where they work the best.

The fallout of following this anti-pattern is huge.  One of product groups I'm observing currently is experiencing cross-team jealousies, defeatism, feelings of favoritism and a lack of trust.  Everyone knows who the "A-Team" is -- sadly, the teams are labeled "Team A", "Team B" and "Team C" and correspond to the levels of confidence that the product managers have in each.  Inexperienced developers are not paired with experienced developers, meaning the former are not getting the training they need and the latter are not getting the injection of outside-the-box thinking that they need.

Smell #2: QA Musical Chairs

This is another anti-pattern related to the first item.  The way this works is that the Quality Assurance engineers for this group are essentially matrix-managed by a single QA Manager.  This, in and of itself, is not a bad thing.  In fact, matrix management of Scrum personnel, especially when there are dedicated areas of expertise, can be a very good thing.  A strong QA Manager, for example, can be working with all of their direct reports on their career objectives and personal growth in a way that a typical Software Development Manager can't.

Where this becomes an anti-pattern is when the QA Manager involves herself with the assignment of QA personnel to specific teams.  Just as with Smell #1 above, the Manager is interfering with the teams being able to form organically and self-organize.  In this case, the Manager is not making the selections based on proficiency, but appears to be intentionally moving team members around as a way to keep them cross-trained on the application.  While this sounds like a good idea, the fact that the manager is interfering with the team organization is the source of the bad smell.

Here she is somewhat tied up by what is already happening with Smell #1:  if the teams were organizing themselves around the whole of the prioritized backlog, rather than having work assigned to each team by the Product Owners, she would probably not feel compelled to mix things up in this way.

"Okay," you may be thinking to yourself, "so it's a bad smell, but it's for a good purpose, it seems.  Where does this go wrong?  What are the consequences?"

There are a couple of consequences that come to mind right away.  The first is that all of the teams' velocities are being thrown askew, since changes in team composition always affect velocity.  This particular Manager would disagree with me, because her teams also correlate story points directly to man hours, which is another Scrum anti-pattern.  (See Smell #5 in an upcoming post.)

The other issue is that the QA personnel are not forming good working relationships with the Software Developers on their teams.  They see their tenure on any team as being temporary.  The upshot is that the teams are not building trust from within and an "us vs. them" mentality is maintained.

Next time we'll look at the Quality Assurance Wall anti-pattern.