Author Archives: Geri

Setting up Your Programs for Success

With all the conversations about SAFe, you would think programs were a new idea. Actually, they have been used for many decades to manage very large efforts. This article discusses lessons learned from the past about how to set up a program at the beginning so it will run more smoothly throughout.

A program is one kind of construct to organize and coordinate the work of a large number of people on the same deliverable. Other constructs include value streams, products, product families/lines, and the open source model (community ownership of software with rules and governance). I have heard of programs as small as 40 people contained within one company and I have been personally involved with programs involving hundreds of people, sometimes across several companies or countries. Programs are used to manage big efforts.

Programs were developed in the defense industry to manage efforts such as putting a man on the moon, creating a new submarine, or creating an overall battlefield management system. Programs were adopted in commercial enterprises to manage efforts such as SAP implementations or creating a new tractor. Creating a mobile app does not require a program.

Programs are used to manage large complex efforts. A key technique to managing complexity is to structure the work in such a way as to get rid of as much complexity as possible. Simplify as much as possible, then manage the rest.

When planning your program, assign work to individual teams in such a way as to reduce or remove dependencies between teams. Each team should work as independently as possible. There should be little or no dependencies based on time, code, functionality or any other factor.

You can achieve this independence by assigning complete independent work packages (for example use case, user story, subsystem, component, or task) to each team. If the work packages are truly independent, you should not have very many cases where multiple teams need to work in the same code base, nor should you care much about what order the work is completed.

Any points where the teams need to cooperate should be well defined using tools such as contracts, interfaces, services, or API’s. Test harnesses and stubs can be effectively used to keep the work of the various teams as independent as possible, allowing each team to test their own code even if code they need to use from another team does not yet exist.

Teams should NOT be set up around the SDLC, i.e. a requirements team, design team, coding team, and testing team. This creates unnecessary dependencies between teams such as the coding team is waiting on designs, the testing team is waiting for code, etc. Each team should be responsible for the complete life-cycle for the work package they are assigned.

You do have to plan coordination points for releases. Teams cannot work on whatever they please. Each team has to make a commitment to deliver certain functionality at a certain time with specified quality. This is a commitment to their co-workers on the other teams. There may be other work a team does as well, but there has to be a minimum set of code they complete by a specific scheduled date in order for everything to fit together. You have to carefully manage the teams so they deliver what they promised the other teams at the time they promised to deliver it. If you do a good job defining the integration points between teams and managing their work to complete on time, then integration of the work of the various teams should be fairly straight forward.

There has to be a program level management team whose job it is to create the appropriate work packages, set up the release schedule, assign the work to the teams, define the minimum each team is required to deliver to make the release, coordinate the work of the teams, remove obstacles between teams, and be the final arbiter in situations of disagreement. People managing the program may include architects (software, system, network, data, UI, business) as well as those in more traditional management roles. You may need people at the program level to create (or help create) code that coordinates the work between teams such as test harnesses, stubs, interfaces, services, or API’s.

While you can do a whole program with one release at the end, this is very high risk. Programs tend to be lengthy and much can change from beginning to end. It is much better to plan a series of releases with time scheduled to make any needed adjustments due to change or lessons learned.

In a well structured program, you do not have to care about how each team does their work. As long as the team delivers according to their contract, it does not matter if they are onshore, offshore, or vendor, or whether they use an Agile or Waterfall type of SDLC.

Finally, the key to a well-run program is monitoring the teams and their progress with appropriate metrics, regular meetings with a representative from each team to coordinate efforts, management by walking around when you can, and quick resolution of problems when they arise.

Tips for Job Searches

While not specifically Scrum or Agile related, I know at any particular time many of you are likely looking for a job.  If that is you, read on.

I recently put together a workbook that steps you through using the Strengths Finder quiz to find keywords to use in your resume, LinkedIn profile, and cover letters. These keywords are your strengths, as well as being the search terms that recruiters use to find people for jobs.

Right click on the link to download the PDF.

Using Strengths Finder to Get the Job You Love

I hope you find this useful.


Six Sigma versus Business Analysis

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.

The Myth of 100% Utilization

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!




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?

Different Ways of Managing Work

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.


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.


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.

The Myth of Software Complexity

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…” , Why it Matters, accessed 11 May 2014


(2) “Trains work best with about 50-100 people dedicated to a primary value stream.”, accessed 11 May 2014.

Earned Value Management (EVM) and Agile

Recently I was asked about EVM, specifically CPI and SPI, for Agile projects.  The question stopped me in my tracks because …. it makes no sense.  Why would I collect metrics that estimate my progress when I can prove actual progress by delivering working software every iteration (sprint)? I’ll outline my thoughts in this post to show why EVM makes no sense for Agile.

First, EVM was developed by the US Government in the 1960’s to solve a particular problem. They had many large, multi-year Waterfall projects with outside vendors and no visibility into progress.  Because there was no way to measure how much of the product was complete (Waterfall meant they got everything at the end), if they stayed with Waterfall, the only thing they could measure was the progress of the project.  EVM is based on a fundamental assumption that we can plan everything up front, and therefore if the project progresses as expected, then we will get the product we paid for.

Let me be very clear. EVM treats the project as the deliverable and measures progress of the project.  EVM in no way measures completion of the product, which is what we are actually delivering to the customer.

The fundamental assumption on which EVM is based is (in many cases) not a valid assumption. In many cases we cannot plan all the work up front. Also, we all know of projects that progressed exactly as planned, but the delivered product was a failure. The project succeeded, the product did not.

But let’s be fair. As long as the choice for software development is Waterfall, there really is no other way to measure progress.

Agile gives us a fundamentally different approach. We can still measure plan versus actual, but we measure a different plan against a different actual. We measure the user stories selected for the iteration (sprint) against the actual software we completed. Does the delivered software do what the user stories said it must do? We measure the actual benefit received by real users using the real software against the cost of developing the software. Do the actual benefits match what we expected? Is the cost reasonable compared to the benefit? Should we continue investing in this product?

Agile answers the question the customer really cares about:

Did I receive the right product at the right time for the right cost?

Our customers do not care about how well the project went. They don’t see projects. They see products. They see what the product does, they see what the product costs. They want the product when they need it, not 6 months from now.

I’ll close this by illustrating with a scenario.  I have 2 projects with 10 people each, with an average labor charge of $100 an hour. Each project is expected to cost $1,000,000 and complete in 6 months.

Project 1 is Waterfall. The project plans calls for the requirements phase to be completed after 2 months for a cost of $330,000.

Project 2 is Agile (of some flavor). They are doing 2 week iterations (sprints). Each iteration (sprint) should cost $80,000 if everyone is billing full time to the project. The first two iterations (sprints), the team expects to complete work that has an estimated benefit of $400,000 a year by saving 80 hours a week of labor time on a task performed by 40 people in the company (2 hours per person).

Project 1 completes the requirements phase in 7 weeks for a cost of $280,000. Everyone is happy. We are ahead of schedule and spend, so the project continues.

Project 2 completes the two sprints. The software matches what the user stories described. The team spent $90,000 (they had to call in a specialist to fix a weird problem). The software is given to 10 of the people who will be using it. The users save on average 1 hour per week using the new software. The cost was $90,000, the benefit is only $200,000, but still a good ratio and the users are happy. The new software is released to all 40 users. Based on lessons learned, the team reviews the cost and benefits of the next user stories to see if there is value in continuing.

If I look at EVM for Project 2, we completed what we planned, but we have overspent. The users are already using the software and receiving enough benefit that it was worth the cost. We have this information 1 month into a 6 month project. We can choose whether or not to continue spending money.

EVM for Project 1 looks better. We are on schedule and budget. But we have no idea if we are doing the right thing or if the benefit will be worth the cost. We will not know this for another 4 months. We have no basis for deciding if the cost is worth the benefit or if we should continue spending money.

Agile Pain Points from Agile 2013

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?


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


  • 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


  • 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


  • 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


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


  • 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


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

Introversion, Extroversion, and Shyness

It is really exciting what science is discovering about our brains and what it means for how we get along with each other in the world. For example, consider introversion and extroversion.

We all used to think that extroversion meant you got your energy from being around people and introversion meant you got your energy from being alone. That turns out to be a simplistic way to describe it.

Here are new descriptions of introversion and extroversion based on current scientific research captured succinctly in this article from Benzinger titled “The Physiology of Type: Introversion and Extroversion”:

Our arousal level identifies the amount and speed of our brain’s activity. …

Having a naturally low level of arousal which causes the individual to seek higher than normal levels of stimulation in order to “feel alive.”

Typical ways in which the extravert seeks stimulation include: trying to influence or control his or her environment; confronting others; engaging in competition; attending crowded parties or events “where the action is.”

Having a naturally high level of arousal which causes the individual to seek lower than normal levels of stimulation in order to not feel overwhelmed.

Over a period of years, this need to not be overwhelmed by external stimulation develops into an internally focused thinking style which may seem withdrawn, meditative, quiet, or even reclusive to more extraverted person. Typical ways in which the introvert seeks to control the level of stimulation include: spending time reading, reflecting, or otherwise alone; avoiding or being accommodating to others; competing mostly with oneself or self image; going to small parties or out of the way places.

An obvious way for a person to get more external stimulation is to be around a lot of people. That is where we get the idea that an extrovert needs to be around other people and an introvert wants to be alone. But other ways of increasing external stimulation include multi-tasking, playing music while doing other things, or engaging others in debate or argument.

So if extroverts want to increase external stimulation, then they should like multi-tasking, playing music at work, and being argumentative. And if introverts want to decrease external stimulation, then they should hate multi-tasking, playing music at work, and being argumentative. These statements both turn out to be true.

Now what about shyness. Shyness (or the lack of it) just refers to a person’s comfortableness with other people, particularly with strangers. A person who is shy is very uncomfortable around strangers; in the extreme case, a shy person literally cannot talk with strangers. On the other end of the scale is the gregarious person who enjoys chatting with complete strangers; in the extreme case, the gregarious person looks for people to chat with everywhere.

So now think about shyness and type. There are four combinations:

  • The shy introvert
  • The gregarious introvert
  • The shy extrovert
  • The gregarious extrovert

Obviously shyness is compatible with introversion. One way to reduce external stimulation is to not be around people. And gregariousness is compatible with extroversion. One way to increase external stimulation is to be around a lot of other people. Those folks have it easy.

The challenges are for the gregarious introvert and the shy extrovert. And yes they exist. I personally know people in both those categories.

The gregarious introvert after spending time chatting with people all day at the office will need time alone in a quiet place to recover balance. A gregarious introvert may turn to alcohol (a depressant) to reduce the level of stimulation to manageable levels. Maybe you know someone who just needs that glass of wine or martini after a day at the office. Maybe the custom in your house is for the wife to take the kids off to make them dinner, while the husband sits quietly in his chair in the dark with a drink for an hour before he can face the family. This is the gregarious introvert balancing the stimulation levels so he can feel functional.

The shy extrovert after working from home alone all day feels dead and needs stimulation to get their energy levels up to a point where they feel functional. A shy extrovert may do a lot of multitasking to reduce the boredom of lack of external stimulation, or play action packed computer games.  Maybe you know someone who works from home who really comes alive when the kids get off school and they go play. Maybe the custom in your house is to take the kids out to the park to play before everyone settles down to dinner and homework. A shy extrovert may put on loud music and the TV and start dancing around the house to get energy levels up. Or propose going out to dinner. Or tease the dog, cat, or children into boisterous play.  This is the shy extrovert balancing the stimulation levels so he can feel functional.

Since Agile focuses a lot on teamwork, it is useful to know what drives different people to behave the way they do. These compensating behaviors become more pronounced in periods of high stress, so if you are pushing your team to a deadline, and some people withdraw and others start picking arguments, you can be sure they are adjusting to their own needs for reduced or increased stimulation in that high stress environment. Give the people who are withdrawing a quite place to get away for a while. Send the argumentative people to a game room with lots of games, music, and TV to play in for a while. Use what we know about the brain to make it easier for people to do their best work for you.

Product Owner – The Misunderstood Role

It is time to talk about the Product Owner, a role that most people developing solutions do not understand. Let us start by pointing out the the Product Owner as a role has NOTHING TO DO with developing solutions. It is a role independent of methodology or process. If a company sells products or services, then it has Product Owners, no matter what they may be called.

So what is a Product Owner? A Product Owner is a person in a company responsible for making sure that a product or service offered by the company is as profitable as it can be (or that it is time to end-of-life the product or service if it is no longer worth maintaining). As a start, a Product Owner knows intimately what the product or service is about, what the market is for the product or service, whether the market growing or contracting, why the customers care about the product or service, what else the customers are looking for, who has competing products or services, and who has complementary products or services. The Product Owner has a continuous task of market research and analysis.

You could say that the Product Owner is the ultimate subject matter expert on the product or service – not in the sense of how to use it, but in the sense of what it is for, what problems it solves, and the market it is in.

Examples of products and services that would have a Product Owner include:

  • Adobe Photoshop
  • Microsoft Word
  • Personal checking accounts offered by your bank
  • Term life insurance offered by your insurance company
  • Personal shopping service for busy executives at a major department store
  • Purina Hamster Chow
  • Ever Ready Batteries
  • Facebook timeline

Depending on the size of the company, the Product Owner may be even more specialized, such as the Product Owner for Term Life Insurance for people over 45.

Like a homeowner with a list of projects to do around the house, a Product Owner will have an ever changing list of things he or she wants that will improve the product or service.  The list may be in the Product Owner’s head or, even better, in a spreadsheet or database. A good Product Owner will review this wish list periodically to see if it needs to change based on changes in the marketplace. This is the same kind of thing a homeowner does; you may have a list of projects based on the idea of living in the house for the next 20 years, when suddenly your spouse gets a job offer too good to refuse in another state, and you change the list of projects to match the goal of selling the house.

No Product Owner I have ever heard of has unlimited funds to do whatever he or she wants with their product or service. Periodically, let’s say every 6 months, a Product Owner selects the things that are most important about the product, and writes a proposal for developing a solution for those things. In order to convince the upper level decision makers that his/her ideas are the best, the Product Owner puts an expected value on the things he/she wants to develop, along with an expected cost for developing the solution.

For just a few ideas, a Product Owner may want money to:

  • Develop a strategic partnership with a company with complementary products
  • Divide a product into basic and advanced versions to answer the complaints of 80% of the customers who say it is too complicated, while not losing the expert market
  • Add features highly requested by customers
  • Add features that research shows us are the things that are causing our customers to buy the competitor’s product instead
  • Fix some bugs that have been discovered since the last funding cycle

This proposal of what to do along with an expected Return on Investment (ROI) is typically reviewed by a corporate portfolio committee. This portfolio committee’s job is to find the things of highest value for the company overall and fund those endeavors. This is a challenging task, since many things have to be considered. Some of the selection criteria may include the things that will make the most money, the things that will save the most money, or the things that modernize failing infrastructure. This committee often has separate pots of money for different things that are important to the company, such as ongoing maintenance, research and development, new products, upgrades, and regulatory. This way they are comparing for example two ongoing maintenance proposals to each other, and not trying to compare ongoing maintenance with research and development proposals.

Some companies have a different funding process, where the product is funded for some period, often a year. The amount of funding for the product is based on past earnings, projected earnings, value to the company compared to other products, and corporate direction. In this situation, the Product Owner has the authority to decide what to spend the money on throughout that period.

Hooray! The Product Owner has money to do the work. Now what? Well now he/she needs a better idea of what it will take to develop a solution, so that the right people can be brought on board to do the work.

The Product Owner now divides the work into work packages. A work package is a relatively small, independent bit of work.  The Product Owner will often work with other people to write up the work packages, people who are familiar with what it will take to develop a solution.  Done well, one work package can be assigned to one group of people to implement, while another work package is assigned to a different group of people to implement. This allows for the complete solution to be developed in parallel, thus getting the solution to market faster.

At this point, the Product Owner has some decisions to make. First, are all the work packages equal, or does it matter which is completed first. The Product Owner may say that as long as everything is delivered in 6 months the order does not matter. Or the Product Owner may recognize that it would be a large advantage in the marketplace for some of the work packages to be delivered earlier.  Or perhaps some work packages describe areas of risk that the Product Owner would like to have developed first, so that he/she can send out the early solution to targeted customers to get feedback before the final product is released. What I have just described is Release Planning, where the Product Owner is making business decisions on what will be released and when.

Another decision the Product Owner has to make is does he/she want to write all the detailed requirements up front and hand them off, or does he/she want a person to represent the requirements to the team developing the solution. This is the fundamental difference between Waterfall and Agile development processes; a document containing requirements or a person representing the requirements.  If the Product Owner chooses to have a person work directly with the solution delivery team, this may be to address areas of uncertainly that the Product Owner expects will change. Most Product Owners do not have the time to sit with the solution delivery team day by day, so he/she will delegate someone else to do that work.  The delegate is responsible for keeping in close communication with the Product Owner.

The Product Owner needs to be very clear on his/her expectations regarding status reports and demonstrations of progress. The Product Owner also has to be very clear who gets to make what decisions throughout the solution development.

You may notice I have worked very hard to avoid mentioning software. Software is one kind of solution, but may not be the whole, or any part of the solution. If the Product Owner is developing a strategic alliance with a company with complimentary products, there may not be any software developed, and yet this endeavor is expected to bring value to the company.  Or the solution may involved hardware and firmware. Or the solution may be to hire a vendor to come and install an upgrade to their product.

Product Owners are very important for the health and profitability of the company. We make a mistake if we only think of them as people who supply the requirements for our projects.