Six Sigma	Business Analysis
Purpose	Remove defects created by a process	Discover user needs and align with business objectives
Approach	Remove variations in the process	Feedback from users
Main Skill Set	Statistics	Analysis
Objections	Forget to ask should we even do this, or is there a different, better approach. Most people are really bad at statistics. Removing all variation inhibits innovation and growth.	Too often just an order taker or list maker. Analysis is not a common skill.

I have gone into many a company whose managers brag to me about their 100% utilization of their people. They have all the techniques down pat and know just how to do it. I see opportunity. If they are willing to listen, I can improve their productivity 20-50% by not trying to get 100% utilization.

 

First, some terms need to be defined. Availability is the amount of time someone is available to do the job you hired them for. If they are a programmer, they are programming. If they are tech support, they are working with customers. If they are a tech writer, they are writing. Utilization is the amount of the available time that the person is actually doing the work. Many companies count utilization as the percent of hours a person bills to a project. That is merely how someone charges their time, not a measure of what they were doing in that time. To improve utilization, you have to improve both availability and utilization.

 

To know the actual time someone is working at their job requires observation. Many of these studies have been done for knowledge workers of all kinds, where the researcher follows someone around all day, tracking the time they spend on everything they do. They do this for maybe hundreds of people (multiple researchers of course) over an extended time. Companies pay for this research because they are looking for inefficiencies in their processes. Fortunately a lot of this research is published and the results are very consistent. This means you can use averages instead of paying for the research at your company.

 

The highest availability anyone has measured was 80%. Your most productive people are available at best 80% of the time to do their jobs. This is actually a good thing! They are not doing nothing in the other 20% of their time. The other time is spent on things such as company town halls, training, meetings with their boss, meetings with their team, and so on. When you think of all the things that pull people away from their work, 20% is a quite reasonable number for those kinds of activities. You want to allow your people time for career development.

 

You think that the contractors you hire must be at 100% availability. Of course they are 100% available for the hours they bill you. If they are billing you at 40 hours a week, they are almost certainly putting in about another 10 hours a week on their own time (or their staffing company’s time) for these other activities.

 

If you really had 100% availability, you would have unhappy, burned out employees who quickly leave for better opportunities.

 

So far, we know we cannot have 100% utilization of people’s time because they need about 20% of their time for activities other than the actual job you hired them to do (programming, writing, tech support, etc.). But what about 100% utilization of the 80%? We can use all our management tricks to get that number; we do it all the time!

 

Maybe.

 

Let’s consider all the things that prevent people from working 100% of their available time. Start with task switching. If you assign people to two or more projects at a time, you are losing on average 10% of their time every time they switch between projects due to having to switch their brains from one project to the other. Averaged out, this amounts to about 20% loss of productivity for each project you add (because people don’t usually just switch once between projects). This number is extremely well established based on about 90 years of research. It is real, it is going on, whether you want to admit it or not.

 

The first step then is to focus your people on one project.

 

But you say you have specialists and they don’t have that much work to do on one project. Then cross train them. The specialist model has been well studied and shown over and over to be inefficient. It looks appealing on paper, but actual measurement in real life shows that specialists lose most of their time to task switching. You are not getting much actual work out of your specialists anyway, so leave them in one place and teach them new skills.

 

The second step is help your people gain additional skills so there is more work that they can do.

 

A final common cause of lack of utilization is the huge number of interruptions due to telephone, e-mail, instant messaging, texting, and so on. For best utilization, you want to focus your people’s time on one project and you want to focus their attention. Get rid of the sources of interruption for some number of hours every day and add practices that help them focus on their work. Since you only have 80% availability, make that 80% as interrupt free as possible. For 6 hours a day, no phone, email, texting, or IM. Seat the whole team together so they do not need to use phone, email, texting, or IM to communicate with each other. Have them work in pairs to stay focused on the job.

 

The final step is to put people who work together in one place, remove interruptions for 6 hours a day (phone, text, email, IM), and have them work in pairs as much as possible.

 

There are companies who have taken these steps and watched their productivity soar. Companies who deliver products to market at 1/10th the cost of their competitors. Maybe you don’t get that much lift, but what is the value to you of a modest 10% gain? What if it was 20%? Is that worth changing they way you staff your projects?

Managing Work

Inside your company, many different kinds of work are being done. Rather than examining the work and then deciding how to structure it, most companies take a one size fits all approach. Many companies have decided that everything has to be run as a project, so they hire a lot of PMPs and set up systems to track the progress of a project. Other companies see success using Scrum in software development so they decide that everything has to be run using Scrum teams, and they hire a lot of Scrum Masters, and usually still try to account for the work as projects (though more enlightened companies fund Scrum Teams instead). Other companies fund product teams and all work is accounted to the product.

The fact is that all of these approaches work (as do many others). Where we make a mistake is treating all work the same way. The reason it is a mistake is that when we organize work in a manner not appropriate to the work itself we introduce unnecessary overhead and cost. You can keep doing everything as a project or everything as Scrum, just know that the work of your company is more expensive than it needs to be.

A Fluid company will look for the best way to do work based on the type of the work itself. In this post, I will examine three primary ways of managing work and discuss the kind of work that fits each management technique. These three ways of managing work are: project, product, and workstream.

Projects

Many companies structure all their work in the form of projects. What they do not realize is that for most companies, about 10-25% of the work of the company fits a project framework. For everything else, the project framework introduces a lot of unnecessary overhead.

First, what is a project? A project has a beginning, middle, and end. A project is completed and there is no work left over. A project is formed to achieve a specific goal or end state. A project has a schedule and budget. The schedule and budget of a project are measured throughout to show the progress of the project. Companies using an Agile methodology for software development (such as Scrum) add a regular measurement of the progress of the actual product being developed to the project metrics.

To run work as a project, you have to define the goal or purpose of the project, estimate the total cost, assign people to work on it, get everyone up to speed (project kickoff), estimate the tasks to be done to achieve the goal, run the project measuring schedule and budget throughout, and finally deliver the results of the work and close down the project.

Work that is “one and done” fits the project model very well. Things such as buying and installing third party software, upgrading all the workstations in the company to the newest version, converting a 40 year old system to new technology, and building a new company cafeteria are all examples of things that fit a project model.

Work that is repetitive and demand driven, or planned and ongoing, does not fit a project model very well. This is for two reasons. First, each repetition of the work requires defining, estimating, setting up and tearing down the project. That is a lot of overhead over time. Second, by dividing the work up into projects, you lose the long term vision of the work and almost always this results in suboptimal short term decisions leading to long term inefficiencies and cost.

Things that are repetitive and demand driven include customer support, setting up a work area for a new employee, releasing a product, or emergency response. These things should have standardized procedures and be managed as workstreams.

Things that are planned and ongoing include adding features or fixing non-critical bugs in an existing product, initiating a new product that you expect to have a lifetime longer than a few months, creating and regularly delivering training, doing competitor research, and any ongoing work that is not demand driven in nature. This kind of work should be organized around products or systems

Products and Systems

Products and systems are things that your company is responsible for maintaining over some lifetime. Systems are inside your company and generally exist to support the work of the employees. Products are things that you provide (or could provide) to customers, partners, or vendors outside your company. The important thing is not whether something is a product or system, but rather is this something that your company has to maintain over time.

Products and systems can be things such as computer hardware, computer software, business processes, training, and reports for a few examples. While products and systems do have a beginning, middle, and end, the lifetime is generally measured in decades, not months. There are products in the market today whose lifetimes are measured in centuries. When managing products and systems, the important measurement is the lifetime cost of ownership. Projects focus on the short term cost, often leading to decisions that make the product or system more expensive to maintain over time. Products and systems should not be maintained as a series of projects; over time that is far too expensive.

To manage work as a product or system, you form a product or system team. This is a small number of people whose job it is to create, maintain, and manage the product or system over time. This could be as small as 2 people (never one – you do not want to depend on one single person knowing the product or system), or for large products being actively maintained you may have 20 or 30 people on the team (or more). The product or system team is responsible for the long term vision of the product or system, the architecture or design of the product or system, the development of the product or system, the maintenance of the product or system, and the release plan for the product or system. The cost of the work is in the size of the team; team members are paid full time to work on the product or system team.

Work comes in continuously in the form of defect reports and feature requests from users, product managers, and company goals and directives. This work is organized into releases by the product or system team. The releases may be monthly or quarterly, or the team may decide on continuous releases, as we see with many mobile apps. The release schedule will be driven by market demand and the ability of the users to consume the changes.

The measurement of success is did we deliver the right product at the right time for the right cost. This will be measured every time a release is made and the team sees how the users react to any new features or fixes.

A lot of “run the company” work is associated with a product, but may not fit as part of the product team. If you are an insurance company and have a life insurance product, then creating actuarial tables is part of creating the product and so the actuary is part of the product team. On the other hand, handling claims is not part of creating or maintaining the life insurance product. It could be considered a product (or service) in its own right, and since it is repetitive and demand driven, it is a better fit for a workstream model.

Alternatively, legal work is often directly associated with a product. For some companies in highly regulated industries, a lawyer should be part of the product team, as well as possibly a compliance officer. For small, stable products these people may not be full time on the product team, but are rather a resource to be called upon as needed.

Workstreams

A workstream is a way of structuring work that is repetitive and on demand. The repetitive work should be described by standard processes and procedures. Work comes into a queue which may be “first come first served” or may have some other prioritization scheme applied. Work is managed by tracking the current work in progress to be sure it is not too large. There are typically service level agreements (SLA) which describe how quickly requests are processed.

The processes and procedures themselves are likely maintained by a system team who creates and maintains the processes and procedures, and maintains the software and systems to support those processes and procedures.

The cost is in the number of people staffed to handle the work in the workstream. People work full time handling the work in the workstream. For many people, the continuous pace of work can be very wearying over time, so rotating people between the workstream and the system team may be a way to balance the work across all the people involved.

Success is measured by the quality of the results, by staying under the work in progress limit, and by meeting or bettering the SLA.

The Common Mistake

When considering a company as a whole, structuring the work in different ways makes sense. The common mistake is to categorize all work within a department or division the same way. We see this often in IT where everything is a project. All the systems, metrics, and reporting are designed around projects. And yet, the emergency bug fix team should be a workstream. There should be product teams for each product. And there will be projects as well. But management wants everything reported the same way on one dashboard, and so we are back to everything is a project. (Why projects instead of products? Because PMI and Business Schools train people to manage projects not products, so management picks what they know as the default.)

By forcing everything to be measured the same way and accounted for the same way using the same systems, we are forcing inefficiency and greater cost into our work. These are not small inefficiencies. The unnecessary costs could be as low as 10%, but for most companies, these additional costs may be 30-50% of the IT budget. Just so we can have everything on one dashboard.

Think about it.

To claim that software is complex and that therefore we must create large teams to manage that complexity (as SAFe asserts (1)) is missing the point entirely. In this article, I’ll examine the fundamental flaw in that perspective and explain what we really need to do to manage software development in the modern world.

 

Software is complex. I have heard this a lot in my career. It is typically said by either people who do not actually understand software development or by practitioners who want to maintain the mystique of the discipline. Good software engineers know that the best software is a simple as possible.

 

The statement “software is complex” implies that complexity is a fundamental characteristic of software. This is quite obviously not true. If complexity is a fundamental characteristic of software, then we would not have all these clever iPhone apps being developed by individuals, even children, in time frames measured in days. The vast majority of software running things such as your clock, thermostat, and parts of your car is extremely simple. Even the software running robots is relatively simple. The math is complex, the software is not.

 

I’m sure the counter argument is, “OK, all software is not complex. But the software running our businesses and systems, that is complex.” If it is true, then that software is almost certainly unnecessarily complex. Think about most business applications. At its most fundamental, you have a user interface, some business rules, and a database. While the business rules may be complex, the software to implement them should not be. There may be a lot of features, but that does not mean the software behind the features is complex. Many is not the same as complex. Large is not the same as complex.

 

The discipline of software engineering (not coding, engineering) is filled with techniques and practices to remove complexity from software. This is because complexity in software is bad. Complex software is hard to understand, and therefore prone to error, difficult to change, and often full of defects. Good software is as simple as it can be, easy to understand, easy to maintain. Practices such as service oriented architecture, domain specific languages, object oriented design, test first development, refactoring, and minimum viable product all speak to the push away from complexity.

 

As my buddy Kyle points out, you have to ask the right questions. The question is not “How do we manage the development of complex software”, the question is “How do we remove complexity from our software”? Hint: you do not remove complexity by creating teams of 70-100 people running under the structure of a program (2). The Fluid Approach is based on removing complexity in software by using the eXtreme Programming (XP) practices along with good Voice of the User teams made up of Analysts and UI Designers who are skilled at Solution Anthropology.

 

I’m sure someone will bring up this argument “OK, software does not need to be complex, but the process of developing software is complex”. My answer to that is it does not need to be. If your software development process is complex, you have made it unnecessarily so. I have worked for extremely large companies creating big software using a very straight forward, simple development process. You really can create large percentage of the software needed today with teams of no more than 20 people with broad skill sets.

 

If your company has many different programmer roles, tester roles, analyst roles, etc., then you have created an unnecessarily complex process. If you have many layers of people involved in your software projects, then you have made the projects unnecessarily complex. The question is not “How do we manage a complex software development process”, the question is “How do we lean out our software development process”? The Fluid Approach has the answer: cross training, dedication and co-location of the development team with the Voice of the User team, management of the queue, and development of the tribe. These things have been proven to simplify the process of software development.

 

The question is not “How do we manage complexity”?

 

The question is “How do we remove unnecessary complexity”?

 

The Fluid Approach shows you how.

 

(1) “Our modern world runs on software. In order to keep pace, we practitioners must build increasingly complex and sophisticated software systems. Doing so requires larger teams…” http://scaledagileframework.com/ , Why it Matters, accessed 11 May 2014

 

(2) “Trains work best with about 50-100 people dedicated to a primary value stream.” http://scaledagileframework.com/agile-release-train, accessed 11 May 2014.

On the final day of Agile 2013, I led a crowd sourced mini-workshop/discussion on Agile pain points. In this post I’ll summarize, with a goal to get into more details over the coming months.

I posted large easel pad sheets on the wall and wrote names of company departments on each sheet. Then I invited the audience to take sticky pads and write their particular pain points and post them under the department causing the pain. After a few minutes, I handed out strips of 8 dots to each participant and invited them to vote on the things that were their biggest pin points. They could use all 8 dots on one, one dot on each of 8, or any variation in between.

A helper reviewed the sheets looking for high numbers of dots. Then we discussed those highest pain points until we ran out of time.

I am still transcribing my recording of that session for notes. But below is the list of departments, pain points, and number of votes for each. 14 people participated in the writing of pain points and voting. Note that things with zero votes are still pain points; they just are not as painful as items with more votes.

What are your pain points? Do you have others?

Geri

Executive / Board of Directors

• 1 – Lack of positive support from executives and on down
• 0 – Want everything now
• 9 – Can’t  or won’t prioritize
• 0 – Silos of demand – no overall view
• 0 – Developers think the only reason for our Agile transformation is to save money by firing people
• 3 – Portfolio management
• 2 – Why don’t you ever stick to the plan?
• 0 – Not all management is on board with transformation

Finance

• 0 – Project funding (instead of product funding)
• 6 – Use of estimates – want the budget up front
• 0 – Must capitalize software projects

Legal / Compliance

• 0 – It takes too much time to review documents and contracts
• 3 – Compliance built around waterfall

Human Resources

• 8 – Job titles versus Agile roles = confusion for teams
• 2 – No team based compensation model
• 5 – Performance appraisals / Yearly appraisals
• 0 – Cannot hire excellent co-op who is a rockstar on the team because of his GPA
• 1 – Revolving door staff
• 0 – Compensation model
• 0 – Lack of dedicated resources

IT

• 0 – Security patching that breaks automated tests and slows build times (example you can’t use AWS you have to use the corporate cloud solution but we know it sucks)
• 0 – Project team staffing (staffing a project instead of staffing a team
• 0 – Mainframe developers, long development cycles
• 4 -Still think in terms of projects not products
• 4 – Won’t adopt stable teams
• 3 – Lack of resource dedication and co-location
• 1 – Team members changed in and out based on application expertise
• 7 – Insist on assigning multiple projects to teams at the same time

Product Lines

• 0 – Lack of priorities
• 0 – Lack of backlog
• 0 – Lack of release plans
• 2 – Product Owners are unfamiliar with how to support Agile

Facilities

• 0 – Cube farms
• 0 – Some teams in special rooms, some not
• 0 – The right kind of space
• 7 – Lack of co-location
• 1 – We need more whiteboards
• 3 – Can not modify workspaces
• 0 – Setting up Agile space / colocation
• 0 – You can’t tear down the cube walls due to fire code
• 0 – No flexibility to move around

Customer Support

• 1 – Tier 3 customer support in engineering team takes time away from our work

Center of Excellence

• 4 – Testing in COE’s instead of the team doing the testing

Product Development

• 2 – How people are assigned to teams
• 0 – Defining team structure, competency vs feature
• 9 – Lack of flexibility for scope on projects
• 4 – Product specialist not willing to build minimal features
• 0 – Lack of user stories

Sales

• 0 – Always have most important projects (they think so)
• 7 – Squeaky wheel want it now

Operations

• 2 – Operations is not structured to support Agile
• 0 – Prioritizing epics
• 0 – They don’t work in our Agile teams
• 0 – Can not provide product owner with enough focus
• 4 – Operations can’t match speed of Agile team
• 0 – Can’t take software upgrades more than once per quarter in the factory
• 0 – Defining roles – product owner, scrum master, coach
• 0 – Complex development – red tape

Other

• 0 – Politics – want to say we are doing Agile, no actual support
• 2 – Funding model
• 0 – Just velocity metrics

I think it is not possible to implement a sustainable Agile practice thinking only in terms of teams of 5-10 people, especially a sustainable Agile practice in large companies. I have nothing against small teams – quite the contrary! But there are distinct advantages to including our teams in a larger organism that supports and sustains the Agile teams.

We need to think in terms of Tribes.

I have been familiar with the ideas around Tribe for a very long time, and have been part of creating Tribe on many occasions.  Dedicating people to a Tribe and allowing them to move around to different teams within the Tribe provides distinct advantages without the thrashing and loss of velocity that occurs when we move people between teams that are not part of a Tribe.

What is a Tribe?  A Tribe is a group of around 100 people who are dedicated and co-located, and who have a commonality of interests. A Tribe develops its own language, culture, and rituals distinct from other Tribes. A Tribe contains people of many ages and experience levels, with the most knowledgeable people acting as “elders” who guide and mentor those with less experience. People in the Tribe work together, play together, and eat together.

Why about 100 people? It is large enough to get a varied pool of talent and skills, and small enough that everyone can get to know everyone else. These are very important elements to creating a stable Tribe.

Doing paired development is the best way I know of to help a Tribe form. Not just paired programming, but pair all the tasks of the Tribe. As people move around pairing with a variety of other people within the Tribe, we get terrific knowledge sharing, and people get to know each other and how to work together.  It is this broad knowledge sharing and knowing how to work together that lets us have fluid teams without the disruption we usually see when people are moved on and off a team.

Advantages to a Tribe are many:

1. Allows Tribal members the opportunity to broaden and deepen their experience by working on a variety of teams with a variety of people
2. Allows for load balancing of work among a number of teams without the disruption that typically occurs when people move between teams
3. Knowledge is spread among many people so you do not risk losing the one person who knows X
4. It is easy to bring new people into the Tribe and get them quickly up-to-speed
5. If your company has pools of specialists who are stretched thin trying to help so many teams, a Tribe of 100 may be large enough that one specialist can have enough work to be dedicated to the Tribe so the Tribe does not have to wait for their time.

Many companies do form Tribes, though they probably do not call it that. They dedicate a group of analysts, testers, developers, technical writers, etc. to one product line, and within that product group, individual teams work on specific work packages. It works quite well, and fits nicely with the Agile focus on Products rather than Projects.

We can do more to promote the idea of Tribe as a purposeful construct, deliberately forming a Tribe by co-locating people with many different skills and experience levels, dedicating them to the Tribe, pairing all tasks to share professional knowledge and get to know how to work together, and encouraging the most knowledgeable people to mentor those less skilled.