Saturday, June 22, 2013

Safety for specialists on cross-functional teams.

For many organizations, cross-functional teams are something new (even those claiming to be using Scrum as a framework).

"The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity." 
Source: Scrum.Org Scrum Guide.

Consider the specialist who has found themselves on a cross-functional team in an organization that is unprepared for this reality and is wondering "Is my job safe?"

Clearly, this could be a frightening position for these highly valued team members.

Let's consider a few situations;

  • I want to do Scrum but am afraid for my job
  • I am willing to give it a try but I am skeptical
  • I hate Scrum and I don't want to work on something other than my primary skill

This post is intended for those who want to do or are willing to try Scrum as a Framework.

For others, perhaps Agile or Scrum is not for you. That's OK. Here's a post about this topic:  Cross-Functional Teams are not for everyone.

Please do not pretend the person's fears are inappropriate, especially in a new adoption or transformation.  

There can be a legitimate fear for team members in a company transitioning to Scrum (or any cross-functional team based framework).  You (like me) may believe in how Scrum can help an organization but that does not mean the organization is ready to do the mind-shift quickly.  This puts a specialist in an awkward position.

Consider a method I call 'EARS'.

Explain the purpose of Cross-functional teams. Explain the ability to "pull" or "absorb" the next most valuable work or "User Story" from the Product Backlog and have potentially ship-able software come out the other side of the Sprint.  This is not feasible without the appropriate complement of people to do the work.

Acknowledge that the current state of the backlog may not yet be in a "format" appropriate to cross-functional teams.  It may take some time until the organization learns to deliver work to a team in this new and in many cases "foreign" approach.

Re-assure the person that it is normal for them to be called upon to do work outside of their primary skill set for the team. The reason they are there is because they have a valuable part to play in that team's success.  After all, they might not be there if they were not good at their primary skill.  James Heidema recently made a great post about this concept.  Click here to read Jim's post..

Sit quietly and let the person think about what this means and answer any questions... Truthfully.

The reality is that if the management is not in alignment with the concepts of Scrum and cross-functional teams, the team members's job may be at risk.  At a minimum, it may be that Scrum is at risk.  People are perceptive.  No matter what you say, they can see for themselves what is happening around them.  

The best you can do is confirm to them the intentions and mechanics of the Agile framework you are using.  I find that often, just knowing it is normal in the framework is enough to already put someone at ease.  Most people want to make sure they are contributing effectively.

You may offer to open up channels of communication with their superiors to find out where they stand.

Don't make up information about what the company thinks!

If you do have management support for cross-functional teams, put extra effort into ensuring work comes to the teams are "slices" through the system that "Need" the complete skill set of a team.  It won't always work out that way, but the discussion needs to take place.

You cannot just build a cross-functional team and continue to give that team work in a traditional way.  This will ultimately fail.

If you are a change agent or consultant, please address this during your transformation or change.  People need to know they are safe in a cross-functional team environment.  This is especially true as the teams and organization learn to work with a cross-functional mind-set.

If someone comes to you with a fear about this, be smart about it .  Use your EARS.


Cross-Functional Teams in Scrum -  Scrum Guide

Sunday, May 26, 2013

Scrum is about Business. Do not be afraid to talk business when talking Scrum.

The situation...

The team has 4 days left in a 10 day (2 week) Sprint.

Person with some "Power": "I want to get this special feature done right now by inserting it into the Sprint because it is important for my division."

Scrum Master: "I am sorry, but we don't allow new work into the Sprint."

Person with some "Power": "Are you telling me that you don't care about this valuable work.  (usually not in a very nice tone).  Scrum is not very flexible".

Scrum is a Framework for delivering Complex Solutions.  It does not solve problems, but one thing is clear.....  Scrum used properly is about Business.  Actions by people in "Power" can have significant negative impact on the expensive group of people called the Scrum Team.

Scrum teams are EXPENSIVE to maintain (especially if distracted).  Don't be afraid to acknowledge that fact!  I once worked with a team who knew exactly what they cost each Sprint as a total including burden (other company costs including building, legal, etc.). It certainly changed conversations.

If your team is not allowed to focus on their current goals for the company, warning bells should be going off.   The team is too expensive to allow this to continue.  The team is already focused as a whole on what has been deemed as the highest Return on Investment from customer feedback to the business.

Please note, Return on Investment (ROI) does not have to be about Money. Return on Investment could be about many other factors.  (A post for another time).

A potential response to the situation above... (Yes, I know, easier said than done).

"Sure. As a Scrum Team, we work by ROI (Return on Investment) and we are highly aligned with business needs. The cost of the team of being redirected is material.  They are a very Expensive as a team.

We wouldn't be doing what we are unless it was important to reaching our Goal.  We are serious about it and serious about protecting the company's money.

For us to be diverted, we would let the Customers and the Business know that this work is more important than what we are currently focused on.  We'll Cancel the Sprint and re-plan.  Based on the size of our team, that should only cost about $12,000.00 all-in.  

We will leave it up to you to explain to the stakeholders who are waiting for our current deliverable.  

An alternative is to ask the Product Owner to put it as the first thing on the list for the next Sprint.  That's only 4 days away.   We're happy either way. I'll leave it up to you.  We'll just need to publish the reason for the cancellation if you choose that path."

This direct approach assumes that the team is actually following Scrum themselves and doing what they agreed to work on. If that is not the case, think carefully about what problem you should address first. 

The example assumes your teams are not just working on whatever they want to or something that was just assigned to the team in a haphazard way.  

If someone is assigning work to individual team members that is a whole different problem.  PLEASE Call an experienced Agile Coach or Consultant who has courage immediately. 

If the conversation would not go well in your organization, I believe you should be asking yourself (or your organization).

- Why are we doing Scrum?

- Why can we not allow the team to focus?
- Why are teams not working on the highest value items already?
- What can I do to educate people and/or executives about how and WHY we keep the Sprint Focused on the current goal?
- Should we be using OpenAgile or Kanban ? (there are more Agile Frameworks)
- Are we being honest about the costs of diverting a Scrum team?

Scrum does not fix problems.  It's rules are designed to expose them

Although it may be tempting to just ignore those rules, realize they are there to protect the investment the company is making in this very expensive team.

By not using them as designed, you are potentially wasting money.  The problems caused by changing the teams' focus are compounded by the cross-functional nature of the team and the work they are already engaged in.

Mishkin Berteig has been posting a series about Scrum Rules and why they work on   Here are some links for you if you're interested...

Sprint Review
Sprint Planning Timebox
Why is each Sprint the Same Length

If you really should be using Scrum and your company would prefer not to re-organize to allow this very expensive team to do the highest ROI work now...

Perhaps Scrum has already exposed a Material problem.  Think about it. Maybe it is working perfectly.

Mike Caspar
Passionate About Agile

Scrum - Scrum Alliance,  Scrum.Org
OpenAgile -
Kanban - Kanban for Development

Thursday, April 18, 2013

Scrum exposes problems. It does not fix them.

I regularly hear people making statements such as "If we do Scrum, it will solve our problems".

The reality is in fact, it does exactly the opposite.  Scrum helps to expose problems.  In some way, you could view this as purposely creating them.

Let me explain.... The Scrum Framework is deceptively simple.  If followed properly, it will quickly show impediments to the development process.  As work continues, it will expose an increasing number of obstacles.

Scrum does not fix a company or a system.  The fixing needs to be done by the company, team members, management and leadership.

By exposing impediments, Scrum allows the removal of obstacles to the development process.  Due to it's time-box nature, it improves the focus of the teams and organization to fix those problems.

By removing those obstacles, it allows the team to go faster.

Think of a balloon filled with helium with several layers of straps and barriers keeping it down.

The balloon wants to climb, but cannot because of barriers holding it back.

Some people think that the measure of "velocity" can be used to "push" a team to go faster.  This is the equivalent of just pushing harder on the balloon to have it try and force the straps out of the way.

In a Scrum context, we realize that pushing the balloon harder to go up when a strap is holding it down only stretches the balloon to it's limits and will eventually cause it to explode as opposed to climb.

Work to remove the straps holding the balloon back, and it can be free to climb.

As the balloon climbs and more barriers are removed, it can start to move at it's natural rate (flow).

The problems Scrum expose need to be addressed.  Only then can the performance of the team increase.

If Scrum shows you something that is hurting the development process, you need to adjust the process to remove the delay to the team.

Having the team changes its' way or worse; trying to change Scrum so you do not have to deal with the information, only serves to allow the straps to remain secure.

Trying to adjust Scrum to allow the "straps" to stay in place and just keep pushing will not fix the problem Scrum has shown.  What is intended is the direct application of pressure to remove the obstacle.

Please don't tell people that Scrum fixes problems.  Remember, Scrum exposes them.

by Mike Caspar
Passionate About Agile