Organizing a small-ish company to do Scrum and ‘regular work’

Holly asks: “I am relatively new to this methodology, and I would like to learn more about how resources are assigned to Scrum teams.  Resource allocation – do Sprint team members need to spend 100% of their time in a Scrum Team?  If so, how do we account for existing job responsibilities?”

***
Good question or questions.

In simple terms, we are dying from complexity.  So, we want to keep things as simple as possible, to help people become more productive.

This is what I am thinking from what I know of your situation.  Imagine that your company has 800 employees, but most are ‘in the field’.  So, you have 75 people who support ‘BAU’ (business as usual), who are not ‘in the field’ and are potentially available to support Innovation.

So, for 125 of the BAU people, I would have a rule that they are 80% dedicated to BAU and each person can use up to 20% of their time to support ‘innovation’.

I would maybe move 25 of the current BAU people to an Innovation group, which would include other people already doing innovation (technology people, project managers, etc.).  Then we call this group doing ‘Innovation’ or ‘Change’, which now has about 75 people.

Let’s assume my ratios of BAU and Innovation people is roughly correct for now.  It provides enough hours to do the related BAU work (if 20% of their time is given to Innovation).  It still raises two questions:
(a) is this the optimum ratio?
(b) should the firm be investing more (or less) in Innovation?

These two questions should be of prime interest to the Exec Team.

Note that often the Innovation people are doing work to benefit the BAU people, directly or indirectly.

These are the two main groups.  Note that the innovation people include business people also.

I would form most of the people in Innovation into Scrum Teams.  But the BAU people are NOT part of the Scrum Teams. At least not as ‘pigs’, although they may work with the Scrum Teams some as chickens (in their 20% time).

We would group work into ‘Product Backlogs’ that have groupings of stuff that can be released quickly.  We get a limited number of ‘projects’ or product releases in flight at any one time. In simple terms, one project per Scrum Team (per 7 people in a Scrum Team).

Obviously, we can only support, with the Innovation people we have, a limited number of product releases at any time (in any year).

Each Innovation person is 80% dedicated to one Team (but can advise others with 20% of their time).  The Innovation people are 100% innovation…no meaningful BAU responsibilities.  They can ‘advise’ others on BAU work in their 20% time.

It may be that some lower priority projects will ‘require’ some BAU people to be involved. But a lower priority project can only start if someone feels that they can get enough BAU support to be viable.  Or can get enough ‘business support’ elsewhere (within Innovation, via consultants, whatever).  This will not be the case; this may represent a significant constraint on the number of inflight Innovation teams. So some projects will be blocked until higher priority projects complete, and ‘release’ certain BAU people.

So, X project may not be able to start.  The Exec Team can decide to hire people or not, to fix that impediment.  Or, we go to the next viable priority project.  (Remember that business information can get into a Team either from Innovation people (eg, product owners or BAs or whatever we call them) or from BAU people.

Why?  We need to be focused on getting things DONE, not on how much work is ‘in process’.  We need to be focused on accountability by Team. Each Scrum Team is focused on the next release.  (That means the release is much more likely to get done well and quickly.)

How to form the Teams?  Here is a good option.  Have 3 managers draft up a set of teams.  The Innovation people look at that and then ‘self-organize’. They can modify the proposal.  Give the Innovation people a week to meet, discuss and change the proposed teams.  With the understanding that any person in a Team is 80% dedicated to that one Team, at least.  Then the 3 managers review the alterations and give final approval.  The group usually does a very good job.

Later we discover a few things, and realize we need to make some adjustments; the Teams usually can manage that.

The real issue is when to start and stop ‘projects’.

Whenever we have a better project than one currently in flight, we need a way to pause the existing project (or get it to release early) and start the higher value project. Before pausing, we tell the related Team, and ask them ‘we want to ‘pause’ your project…can you release most of what you have now ‘real soon’?  How soon?’  Then adjust according to their advice.

Another issue is: when does the ET know that a Scrum Team is coming ‘free’?  I give the Scrum Teams the responsibility to ‘brag’ about a Release they are about to put out.  They are clearly expected to release quickly, products of  high value and high quality.

So, when a Team has just released, the ET can give a different ‘assignment’ or ‘mission’.  The Team may make a case that they need to stay on Product 1 for the next release.  But the ET gets the final decision.

In this vision, the main jobs of the ET are two (for the innovation teams)

1. Fix impediments

2. Be decisive about priorities.

This includes….when a Team finishes a release, what do we give them next?

Given where we have come from, I suspect the Team will have to say (probably repeatedly for awhile): “We are only working on one and only one release at a time…the one of top priority.”