Shared roles in Scrum

I am working with two teams from different clients right now that are both struggling with the concept of swarming and cross-discipline work.  Each of these teams have team members that are experts in their own area, but run the spectrum from not comfortable to just plain don’t understand the other technologies or practices that the team needs to accomplish the work.  The result is that both teams are struggling to get stories done because of the lack of ability to focus on just one or two stories at a time; since many team members would ‘have nothing to do’ and others are overworked.  One of the primary focuses that we have for improvement is to learn to swarm on stories and begin the cross-discipline training.

It seems that the general philosophy in agile coaching today is that every member on a scrum team should be able to do anything needed to complete the feature.  I disagree with that hard and fast interpretation, and the Scrum Guide also does not support this concept.  Summarized, the guide states that all disciplines needed to complete the work need to be on the same team, not that all team members need to do the same work.  (Scrum Guide, pg 4 ‘The Scrum Team’).  Self-organizing means the team figures out how best to get the work done, which includes who best to do each portion.  However, the guide does stress that “The team model in Scrum is designed to optimize flexibility, creativity, and  productivity”.

I think the statement that really started the “everybody does everything” mentality was this:

·         Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

But then those same people skipped over this:

·         Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

I was at a conference a couple months back and heard Jeff Patton give an analogy that I plan on re-using in the future to help with this misconception. Essentially, think of your scrum team as a football team. (North American Football for you euro’s out there). In football, you have specialized skill sets that are pretty ingrained; for example an offensive lineman

is good at his job because of his specific physical and mental attributes, which are very different from a wide receiver's. However, on a given play, each of the 11 players on the field knows not only their role, but the other player’s roles as well, and could perform them if needed. A wide receiver can stay in and block, but they are not as good at blocking as a lineman or tight end.  A lineman can go out for a pass, but they are not as fast or as good at catching a pass as a receiver.

    (I challenge you to remember a time that you saw a 320 pound lineman streaking down the sidelines after making a fingertip catch?)  The point being that each player knows their own role innately, but as needed they can jump into other roles as appropriate to move the team forward.  However, when they jump in to those areas there will be a degradation (usually slight) in efficiency.  That loss of efficiency is more than made up for by the elimination of the queue that would otherwise form at the other team member’s feet. 

Applying this to a Scrum team, the reality is that each member has their specific skill set.  I cannot take a software developer that is really good at their craft, and move them into testing and expect them to be just as good as a well-trained experienced software tester, nor vice versa.  Each of those roles takes years to develop the specific skill sets needed to be an expert in that area.  I can, however, expect them to know each other’s roles well and be able to jump in to any role as the team needs them to so that the work can be completed.  If I need the wide receiver to block, he/she should not only be willing and eager, but understand enough of the technique to be successful.

This does not mean that there are no more experts.  Through pairing and other practices you are going to help share understanding and skills about using the testing and development tools and how to function within them, but it would take years of pairing to share each and every experience that has made each team member valuable in their own expertise.  (Having been a developer for multiple decades I know this first hand).  Many (most) developers or testers have gone into their field of expertise because that is what they want to do; forcing them all to be a homogenous pile of goo that can ‘do anything’ is not practical. 

The reason we as coaches teach and preach about cross functional teams and ‘everybody doing everything’ is to avoid the major downfalls of mini-waterfall (those dreaded queues again) and to increase collaboration and shared ownership.  Queues are what slows down a team because of the inherent wait states built into most (all) queues.  (Google queue theory or read Rienertsens excellent book “Principles of Product Development Flow”).   The delays built into queues are one of several key factors that slow down waterfall development and make it inappropriate for most software projects.

Collaboration is key to any agile team’s success, but making the blanket statement that no one can be a developer or a tester (having a primary skill set) is short sighted.  The tricky balance is building the collaboration while still allowing the efficient part of each team member doing what they are best at.  The best practices I have found, and the ones I plan on introducing with my current team, is to break the work up into small enough chunks, and keep the focus on only a story or two at a time within the sprint.  This tends to force the right balance of “that’s my skill so I’ll take that” with “I have nothing else to do in my skill area, so I’ll jump in to this other area to get this story done” mentality.  Back to the football analogy, I’m going to ask the team to run one play at a time, let them focus on that play and allow them to do what they are best at, but if the team needs the wide receiver to throw a pass to the lineman to score, then so be it.  But that offensive lineman is still an offensive lineman, and is needed to make a true team.

Casual Friday

It’s Friday, and my current client observes ‘Casual Fridays’ for a relaxed dress code (normally Business dress code).  It’s amazing to me to see the lack of productivity on Fridays due to everyone wearing jeans instead of shirt/tie or skirts/dresses.  The drop off in efficiency is just horrible.  And yes, I’m being extremely sarcastic.  What I do see is the same (or possibly more) work accomplished, the same level of professionalism, and the same level of drive to do something good for the company.  If the drive to make the company successful is not there with jeans on, it won’t be there any more with a shirt and a tie in place.

So, what does this have to do with agile, since this is an agile blog spot?  A Lot.  To me, dress codes, KPI ratings, manager performance reviews, and all the other trappings of the corporate lifestyle are one of the major factors inhibiting the agile movement really delivering on its promises across the spectrum.  Let’s take one of the agile principles and see what effect these artificial corporate practices have on agility.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”.

Dress codes are a holdover from a bygone era where how you dressed reflected how high up the ladder you were, and you had to dress appropriately to climb the next rung.  Many of the old school corporate executives still struggle with trusting the employees to ‘get the job done’, and they mask that lack of trust with an enforced dress code.  “If they are dressing appropriately, then I can assume they are acting appropriately”.  If only it were that easy.  This is something that, as an agile coach, I struggle with daily.  Yes, trust must be earned, but it must also be available.

My wife interviewed with a company back in the 1990’s and during the interview she asked about the dress code.  They responded “we prefer you come to work dressed”.  That was it.  That company was far more focused on hiring the right people and trusting them to do the job than worrying about the dress code.  I do understand that there needs to be some sort of standard upheld, and some companies do actually have customers coming in house that require some sort of dress code, but the point being that the emphasis is far too often on gaining the appearance of trust, rather than establishing an environment that fosters trust and commitment. 

People are not motivated by dress codes, performance reviews, or all of the other artificial trappings we put on it.  They are motivated by the intangibles, by the opportunity to do something difficult and having the environment where they can succeed.  In his book “Drive: The Surprising Truth About What Motivates Us”, Daniel H. Pink talks about experiments that have proved that pay, status, and other simple rewards are not what drives us.  The opportunity to challenge ourselves, the chance to stretch out and try something that we have not done yet, the ability to achieve something really cool, that’s what truly motivates us.  Once corporations understand this and focus more on providing these environments, the better off they will be.  There are a few companies you may have heard of that learned that early on, with names like Google, Apple and Amazon.

BTW, that company my wife interviewed for?  She got the position, and it was one of her favorite jobs of all time because their corporate culture was accurately captured in their simple response on the dress code.

It’s like kissing your sister

Why we should always strive to complete stories and tasks in the committed sprint

One of the most common missing attributes of teams struggling to adopt agile practices, particularly in a Scrum framework implementation, is the dedication to complete what was committed to.  Especially when coming from a waterfall background, where the exception is to complete on time (as per that glorious project task tracking sheet) and the norm is to have tasks slide.  And slide.  And slide.  Many of us have been conditioned to believe that this is ok because:

• “the original date was not realistic anyway”
• “The task grew to more than I expected”
• And the all-purpose “but I had to wait for this other thing to get completed”

Agile, and Scrum in particular, is very much about making us predictable.  Moving stories and tasks from one sprint to another (and another, and another) should be like kissing your sister; you will do just about anything to avoid having to do it.  (I grew up with 4 brothers so I can’t say for sure, but I think you get the point).

We have made a commitment to complete a set of work so that we can provide an agreed upon value to the business; our predictability is being counted upon to maintain the cadence of Scrum, and to build the trust from the organization that we will complete what we set out to do.

How do we become predictable?  How do we create a pattern of meeting these commitments?  It’s not by padding our estimates; that will make us predictable in a very bad way.  It’s not by overworking and going down the ‘death march’ path; that’s not sustainable.  And it’s definitely not by laying blame elsewhere; agile is all about personal accountability, team commitments and transparency.   We become predictable and create this reputation for meeting commitments by breaking things down appropriately, maintaining the proper level of communication, and by having a clear view of what done looks like.

How to avoid carrying stories from sprint to sprint

Humans are terrible at predicting very far out into the future.  When we try to predict how long something will take, the bigger the effort the worse we are at predicting the completion time.  When we invest time in making that long range prediction more accurate, we only succeed in extending the date out further; hence making the prediction even worse.

Break it dowm

When we break things into smaller chunks we not only can predict with more accuracy how long it will take, we also gain a ton of knowledge about what that value is and how to provide it.

In Donald G. Rienertsen’s excellent book “Principles of Product Development Flow” he illustrates this fact with the 6^th and 7^th principles of Product Development Variability.  In the 6^th principle he describes how forecasting becomes easier at shorter time-horizons as we are able to better predict the size and scope and also increase the speed of development (through less uncertainty, amongst other benefits).  In the 7^th principle he illustrates how many small experiments (tasks) produce less variability then one big one; resulting in faster feedback and reduced variability in the outcome (read: Predictability).

Don’t Overcommit

Superman says “Don’t worry ma’am, I’ll stop that train”, and the action hero always tells the distressed damsel “I won’t let anything bad happen to you”.  Big promises, but whether through superpowers or a Hollywood script they know they can back it up.  We are not Superman nor are we action heros, overcommitting in the real world just gets people hurt.  So, why do we try? 

The reality is that the real heroes are the ones that understand their limitations and what they can and can’t do.  They don’t put their team’s reputation in jeopardy by overstating what’s possible.  (In the same light they don’t sell their team short by under committing either).  The tricks to this step are to learn from recent history.  What did we get done last sprint?  Did we over or under commit?  If we over committed, what was the main reason?  Were we optimistic?  Did we not see the risks or dependencies in the committed work?  One of the great powers of the Retrospective is to answer questions like this, to inspect and adapt by improving our tasking and commitments.

Planning for Done

Dwight D. Eisenhower once said “In preparing for battle I have always found that plans are useless, but planning is indispensable.”  We task out stories to find the inherent risks and dependencies in a story, not to track our time.  Working together as a team at the beginning of a sprint to task out the committed work will identify many hidden risks and dependencies early on, as well as lead to a confidence factor in completing the work.  If risks and dependencies are discovered, or the confidence factor is low, early in the sprint is the time to discover this.

However, do not mistake this for a waterfall in a can.  We task out enough to understand how we will approach the problem, but we don’t write a full on requirements document before we get started.  We share a common understanding of the acceptance criteria, but also understand those may change slightly as we learn about the feature during the sprint.

Swarming

The practice of swarming on a story is under-utilized in most scrum teams.  Look for a blog in the near future on this topic, but essentially this means everybody that can works on the top priority story until it's done.  I equate this to bees on flowers; as many bees as possible go to the first flower, if it's full then the remaining bees go to the next flower.  However, the bees don't spread out across the entire field, they stick together and move from flower to flower almost as a unit.

Forces from above...

One of the primary reasons for overcommitting or taking on too big of a chunk in planning is the forces from management and product ownership to “get more done”.  That kind of pressure is ok; management and Product Owners should expect a lot out of their agile teams.  However, make sure that from a team perspective you are counterbalancing that pressure with the right amount of reality (through conversations during planning and backlog grooming ) and predictability.  It becomes far easier for management to accept what they consider a smaller commitment once they become used to the fact that what is committed will be completed.  It is better to under commit as you work to get better at these practices; having time available at the end of the sprint is not as anti-productive as you might think.  Become predictable and the trust from management will follow.

Avoid the Icky…

When planning out your sprints, keep this in mind: At the beginning of the sprint you made a promise to your product owner to provide a certain amount of value.  Make sure your plan convinces you that you will be able to uphold this promise.  Take a confidence vote on the plan, raise your voice when you don’t feel comfortable with the plan, ask the right questions at the beginning of the sprint.  If you miss that goal, inspect and adapt during the retro to address the reasons for falling short and follow through on the proposed actions that result.  Becoming predictable should be one of a team’s few top goals.  Work to make sure you don’t have to kiss your sister again.