Category: management

Posted on

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.

Posted on

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?

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
Posted on

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.

Posted on

The Importance of Tribe for Agile Sustainability

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.