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.

The shortest answer: Yes, we want to get most people (those doing innovation work) quickly working 100% of their time in one Team.  Many reasons for this.

***

Here is the longer answer.

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’ doing BAU (business as usual, or ‘regular work’).  And, you have 75 people in Innovation.  So, 875 people altogether.

We want most of the BAU people 100% dedicated to BAU.   And we want most of the Innovation people 100% dedicated to innovation (for now, think of innovation as project work).

We first must recognize that the Innovation group must draw on the expertise of the BAU people.  The products that Innovation are producing will be very weak without the input of the BAU people.

So, for maybe 125 of the BAU people (from the 800), I would have a rule that they are 80% dedicated to BAU and each of those 125 BAU people might work up to 20% of their time to support Innovation.   (Let us also not forget that the BAU people will benefit from the products from Innovation.)  Thus, these BAU people will make decent business representatives to the Teams, either as business stakeholders who come to the main meetings, as SMEs who consult with the Teams, or in some roughly similar capacity.

Next: Let me assume that all of the current Innovation people have Technology backgrounds.

I would move an additional 25 of the current BAU people to the Innovation group (and they become ‘Innovation’ people), and they work full-time on Innovation.  These 25 people would form the Product Owners and business analysts, etc. inside Innovation.  Note what we call this group doing ‘innovation’ or ‘change’, which now has about 100 people.  Innovation is now a mix of technology and business people.

(More broadly, Innovation should have people with a diverse set of skills sets and knowledge to be effective in getting their work completed quickly, with high quality.  In Scrum terms, that includes Product Owners, ScrumMasters, Team role people, and others.)

BTW, innovation happens with any work that delivers ‘change.’  And technology change is not the only type of change.  For example, a changed process (possibly with no related technology change) could be an innovation effort.

Let’s assume my ratio of business and technology people is roughly correct for now. Especially if supported by the 20% time of the 125 BAU people. By correct, I mean that this ratio seems to support fast innovation notably better than we did before.

It provides enough hours to do the BAU work (if only 20% of the time of 125 of them is given to Innovation).

It still raises two questions:
(a) is this the optimum ratio? (between business people and technology people within Innovation)
(b) should the firm be investing more (or less) in Innovation?  eg, are the ratios between BAU people and Innovation people roughly correct for the current business model and the business environment and the business situation?

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

These are the two main groups: BAU and Innovation. (Your firm probably has other groups as well, and very typically BAU is divided into Lines of Business or Functions (sales, ops, etc).)   Note, again, that the Innovation people include business people as well as technology people, at least.

Organizing the Teams

I would organize most of the people in Innovation into Scrum Teams.  Let’s say from the 100 people, you form 12 Scrum teams of about 7 people each. So, 84 people are in Scrum teams, including POs, SMs, and implementers.  The other 16 people are working 100% on Innovation, but as chickens (part-timers) to any one Scrum Team.

Remember that the 125 BAU people are NOT part of the Scrum Teams . At least not as ‘pigs’, although some of them will work with the Scrum Teams some as chickens (in their 20% time), eg, as key business stakeholders.

We would group work into ‘Product Backlogs’ that have groupings of features 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).

Everyone in a Scrum Team is 100% dedicated to that one Team (with some minor exceptions).  And one Scrum Team is 100% dedicated to one Product Backlog (which represents one vision, one product). And the Team are focused, mainly, on the one next release.

Obviously, we can only support, with the Innovation people we have, a limited number of product releases at any one time (over one year).  Let’s say we have 12 Scrum teams from the 100 Innovation people.  That gives us only 12 projects (releases) in flight at any one time.

This is the first important thing.  We must minimize WIP, work in progress, in the form of ‘projects in flight’.  This is a key lean idea.  And essential to success.

And we only work on the number of ‘releases’ that our teams can support at any one time.  No team ever again is working on two projects at the same time. (Once we gain this discipline, we can talk about some relatively minor exceptions).

For most of the teams, the approach makes it very clear whether we are making progress on the top 12 innovation initiatives.  Each team is being successful, or they are not.  But it is very clear.  And, at least to each team, it is very clear what their top impediments are.

We do not have the same clarity about the work of the 16 people who are not in teams.  But, their main job is to support the teams, so, if the teams are all successful, we (say, the Exec Team) can hope that the 16 are helping that success.

How do we allocate the people to Teams?

In a simple world, the best initial method seems to be the following (which is based on experience).

1. Get a small group of managers together (4 people?), and identify Teams on paper.  And identify projects for the Teams, with a short description of each project or release or high-level product backlog.

2. Let the people (on the Teams) self-organize and change the Teams.  Give them the information from the managers (teams and projects), and let them adjust things.

3. Let the managers review the changes by the people, and make some final tweaks.  They may ask the people why they made certain changes.  The managers should be biased to accept the changes that the people made.

The general rule should be that all the pigs are 80-100% dedicated to one Team.  Mostly 100% dedicated.

The other key rule: a Team will only work on one release at a time.  (There can be some minor exceptions to this rule that the PO can control from one Product Backlog.)

In general, once we form a Team, and it is doing well (say, they have increased velocity by 100%), then management tries hard to keep the Team together.  Still, occasionally we will have to add people to a Team (and, less frequently, subtract a person).

***

Digression:

Usually things are not so simple that we can use the 3 step approach unmodified.

For example, there is a high value in starting Scrum with a pilot project or two, and not with a Big Bang (say, starting 10 Scrum teams at one time).

And, once you have started some Scrum Teams, if they are doing well, I recommend keeping each Team together.  If they are doing well, they have a chemistry and other tacit knowledge that took a lot of time to build.

So, these and other considerations may make you modify the approach suggested above.  Use common sense, and remember that common sense is uncommon.

***

Can BAU have projects?

Can BAU people start their own ‘projects’?  Well, it depends on what we mean by project.  To me, most of the things that I want to call projects would fall to Innovation to do.  But one can imagine ‘temporary work’ of some special nature that is best done by BAU people, and only BAU people.  (Ex: A set of work to gather data for the regulators.)  And this might be called a ‘project’.

But if a ‘project’ in BAU gets very big (say, more than 15 man-months of work?), then probably it should be moved to Innovation.  In this model, and to keep things simple, the people who know how to run ‘projects’ well should be in Innovation.  And the BAU people are best at BAU.  Don’t ask a person to do something he is not good at.

If BAU finds that they want to do ‘large projects’ more frequently, then we may have to revise this simple model to cater for that situation better.  But for now, I would err on keeping the structures simple.

Do all Innovation efforts have to involve Technology?  No!  So, we stop thinking of the Innovation group as ‘mainly Technology’ and more and more as ‘the people who make any innovation happen.’

But we need some pigs on multiple teams

It is very common when starting Scrum that some people are needed on multiple teams.  George is the ‘only’ expert in X skill or Y domain of knowledge.

How do we overcome this constraint?  I like to use the 80-20 rule.  Or a kind of 80-20 rule.

Let’s say we have 20 George’s in our 100 people in Innovation.  Make 10 of them chickens, at least for now.  But make the other 10 pigs.

For the Georges’ that are pigs, tell them they are 80% dedicated to that one Scrum Team, but they can use 20% of their time to help other teams.

So, when Mary and Amir and Pierre ask for help from George, George can no longer do that work himself.  (Imagine that George is in Team 1, and Mary, Amir and Pierre are in Teams 2, 3, and 4 respectively.)   Mary-Amir-Pierre suddenly see that they must use George’s time very efficiently in such a way that they can now do the work themselves.  So, all 4 of them have the right incentives to do ‘knowledge transfer’ efficiently and effectively.

One of the key issues is assuring that George wants to ‘release’ his knowledge.  On paper, one would think he would, but in practice it is not always so.  Someone, often a manager, must talk to George and encourage him and later reward him for ‘giving up’ the knowledge to the others.

In this way, we overcome the ‘we’re too dependent on George’ problem.

Note: Each Innovation person is at least 80% dedicated to one Team (but may advise others with 20% of their time).  And all Innovation people are 100% innovation…no meaningful BAU responsibilities.  They may ‘advise’ others on BAU work (or Innovation work) in their 20% time, for a period.  ##

What if we are dependent on BAU people?

As some point, we must accept that we can only do what we can do….what we have enough people to do.

If we need BAU people, we use those 125 people doing mostly BAU work who can work as chickens with the Innovation teams for 20% of their time.

And we allocate those people to the highest priority work first.

It may be that some lower priority projects will ‘require’ some BAU people to be involved, and the right BAU people are not available.  Then management must work on this impediment.  (The solutions are relatively obvious; we won’t review them here.)

But, for now, a lower priority project can only start if the Team feels that they can get enough BAU support to be viable.  Or can get enough ‘business support’ elsewhere (within Innovation, via consultants, whatever).  In some cases, maybe there is not enough ‘business support.’  This may represent a significant constraint on getting some projects started. So some projects will be blocked until higher priority projects complete, and ‘release’ certain BAU people from ‘higher’ priorities.

Imagine that X project may not be able to start for this reason.  For example, 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, BAs, etc.) or from BAU people.)

Why is minimizing WIP so important?

We used to address the problem of ‘need to do many things’ by just ‘starting’ a project, even though it did not have the proper people to be worked on effectively.  Or we could not tell if it had the proper people.  This was not good.

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

Again, minimizing WIP is a key Lean principle, and we have only scratched the surface on how important it 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 (the Exec Team or a member of the Exec Team) talk with the related Team, and ask them “we want to pause your project…can you release most of what you have so far ‘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’?  The Scrum Teams have the responsibility to ‘brag’ about a Release they are about to put out.  They are clearly expected to release quickly, and with products of  high value and high quality.

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

This later point 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 to others in the organization (probably repeatedly for awhile): “We are working on one and only one release at a time…one of the Top Y priorities.” (Y = 12 in my comments above, because their are only 12 teams.)

***

Your comments are welcome.

 

« « Learning from the Toronto Scaling Workshop || Question: Advice to a beginning ScrumMaster » »