Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Drip Funding, Slicing, Decomposing Large Projects Into Small Projects?

Herding Cats - Glen Alleman - Wed, 02/10/2016 - 18:54

Drip Funding, Slicing, Decomposing Large Projects Into Small Projects are popular platitudes of the agile community and have been picked up by the #NoEstimates community as the response to questions about funding work, business processes, managerial finance and making decisions in the presence of uncertainty.

A domain is always needed before any suggestion for anything can be assessed to be applicable and useful beyond personal anecdotes.

Let's look at an actual program for a Health Insurance Enterprise system provider network system. The diagram below shows what capabilities neeed to be produced in what order for the system to be of any use to the business.

This by the way is a critical issue in the agile development paradigm. The customer may prioritize what Features come first. But there is a business architecture in place for any enterprise system. The order of the work is not arbitrary. Partially completed software components are of little use. Drip funding and Drip delivery may be fine for simple applications. But a System of Systems no longer has an arbitrary order of the work. It's a working system and the capabilities need to appear in the right order for any value to be produce. This order of delivery is engineered not emergent.

In the example below, the systems starts with a legacy suite of applications. The final system is an ERP style claims processing system, provider network integration, and a Data Mart for the information associated with processing claims from the provider. This type of development, integration, and evolutionary deployment is common when there is a mix of legacy and new components. Even in the new components - say green field deployment of SAP. But rarely today is there an Green Field deployment in any non-trivial environment.

The way this diagram reads is things in Boxes are system capabilities, complete with Definition of Done - not in the simple Agile DoD. But with Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters. All defined upfront.  These are not requirements, they are what Done Looks Like in units of measure meaningful to the decision makers.  

The connections between the boxes - moving left to right - are the sequences of the needed capabilities to have them be useful to the business. For example having a Pilot alone isn't much use. Having the Pilot and having real data for that Pilot to work on for a Demonstration of the Conversation process and Member Reconciliation is useful. This notion is how to read the chart.

Screen Shot 2015-12-28 at 6.36.37 PM

By the Way this chart is just a different version of an Integrated Master Plan. This is not by accident. Several of the senior managers on this program, along with our team, work in the Space and Defense business as well, where Software Intensive System of Systems are the norm.  The Integrated Master Plan / Integrated Master Schedule programmatic architecture looks like this. Where tangible business benefits are at the Event Level, the Significant Accomplishments needed to produce those benefits are next, and the Accomplishment Criteria are the exit criteria for the Work Packages (Features in Scrum) needed to produce the working software that can be put to use by the business.

Screen Shot 2015-12-28 at 6.47.40 PM

The connectivity between the IMP elements (Events, Accomplishments, and Criteria) and the Work Packages in the IMS looks like this:

Screen Shot 2015-12-28 at 6.49.14 PM

All This is a Set Up for the Questions In the Title

If we have the typical enterprise legacy integration with new enterprise application - the vast majority of work in IT,  ...

  • Can Drip Funding be used to deploy this enterprise system?
  • Can the work be sliced into smaller incremental deliveries?
  • Can this big project be broken down into a bunch of small projects?

Drip Funding

Drip Funding is claimed to be a way of developing software without having to estimate how much it will cost in the end. Of course this ignores the basic managerial finance principles of any enterprise effort. That principle says, someone, somewhere in the organization who is accountable for spending money has a fiduciary need to how much will be spent, when that expenditure will turn into productive use for accounting purposes of FASB 86, and what is the cash flow for expense curve look like against the bookable value to the firm. 

So Drip Funding also needs Drip Benefits, in the terms of revenue if this is an external project or bookable benefits if this is an internal project. Expense and Capitalization opportunities are also needed for the integrity of the balance sheet every month. How much did we spend, how much will we spend, when will we start to see the rewards from that spend so we can start to balance the books on that expenditure?

Looking back to the Capabilities flow picture, we can certainly incrementally fund work to produce a working capability. But dolling out money in Drips may or may not get us there. How big do the Drips need to be? When do they need to arrive?  There is a difference between allocated funds and committed funds. There may be budget for the work, but authorizing the spend for the work is different. 

While Drip Funding is a popular term in Agile, those accountable for the firms spend - cost accounting and the CFO - need to weigh in on the balance sheet aspects of providing incremental funds with some expectation of when they will get their money back. This is standard Managerial Finance and also the basis of decision making in the paradigm of Microeconomics. If I have a fixed amount to spend, what are the choices that can be made that will produce a tangible beneficial outcome in exchange for that spend? The first number is fixed (usually), the other numbers (benefits and when) are uncertain and require estimates to be made to close the loop of the decision making process.

 

Related articles Build a Risk Adjusted Project Plan in 6 Steps How Think Like a Rocket Scientist - Irreducible Complexity Impact Mapping and Integrated Master Planning 5 Questions That Need Answers for Project Success Herding Cats: What does done look like? How to Deal With Complexity In Software Projects?
Categories: Project Management

The Economics of Sofware Quality

Herding Cats - Glen Alleman - Wed, 02/10/2016 - 02:05

Economics of SWTo predict the future of a software project with acceptable accuracy and precision, it is necessary to measure past project and keep track of current and ongoing projects. Estimation and  measurement are closely aligned, and good historical data is of great value in estimating future outcomes of future software projects. - Opening of Chapter 2 of the book to the left.

Software Development, using other peoples money in the presence of uncertainty is a microeconomics paradigm. What choices are needed to assure project success, confirm that the funding invested produces the planned return on that spend? What choices are best for the current understanding of the uncertainties faced by the project. Both reducible and irreducible uncertainties?

To suggest decisions can be made without estimating the outcome of those choices it to willfully ignore the foundation principles of microeconomics and managerial finance of software development projects.

Those conjecturing those decisions can be made without making estimates, are participants in this willful ignorance.

Categories: Project Management

The Economics of Sofware Quality

Herding Cats - Glen Alleman - Wed, 02/10/2016 - 02:05

Economics of SWTo predict the future of a software project with acceptable accuracy and precision, it is necessary to measure past project and keep track of current and ongoing projects. Estimation and  measurement are closely aligned, and good historical data is of great value in estimating future outcomes of future software projects. - Opening of Chapter 2 of the book to the left.

Software Development, using other peoples money in the presence of uncertainty is a microeconomics paradigm. What choices are needed to assure project success, confirm that the funding invested produces the planned return on that spend? What choices are best for the current understanding of the uncertainties faced by the project. Both reducible and irreducible uncertainties?

To suggest decisions can be made without estimating the outcome of those choices it to willfully ignore the foundation principles of microeconomics and managerial finance of software development projects.

Those conjecturing those decisions can be made without making estimates, are participants in this willful ignorance.

Categories: Project Management

My Book Tour in North America

NOOP.NL - Jurgen Appelo - Tue, 02/09/2016 - 22:20

This year in June, publisher John Wiley & Sons will release Managing for Happiness, the updated version of my very successful #Workout book. To celebrate this, I have a special offer for event organizers in the USA and Canada.

For an appearance at any event (either public or in-company) during my book tour, I offer 100 copies of my new book for free, and for anything above that number, I offer a 50% discount from the catalog price (USD 35)

The post My Book Tour in North America appeared first on NOOP.NL.

Categories: Project Management

Should Scrum Teams Include a Stretch Goal In Their Sprints?

Mike Cohn's Blog - Tue, 02/09/2016 - 16:00

There are, of course, a variety of ways to go about planning a sprint. I’ve written previously about velocity-driven sprint planning and commitment-driven sprint planning and my preference. But regardless of which approach a team takes to sprint planning, there is also the question of how full to fill the sprint.

Some teams prefer to leave plenty of excess capacity in each sprint, perhaps so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to forecast their capacity.

Still other teams like to take on a “stretch goal” each sprint, which is kind of a product backlog item that is not quite in the sprint, but is one the team hopes to complete if the sprint goes well.

In this post, I’d like to share my thoughts on bringing a stretch goal into a sprint.

This is one of those things that needs to be left entirely up to the team. It should not be up to the ScrumMaster or the product owner, but up to the team. Some teams do extremely well with a stretch goal. Other teams do not.

It really depends on how the team views the stretch goal.

For example, I feel stretch goals are like a crushing weight. I feel like I need to complete them. When I set a goal, I almost always achieve it. I have a hard time distinguishing between what I call a “normal goal” and stretch goal. I don’t think this is good, but it’s who I am. But, I’m not the only one who does this.

If a team included me and perhaps a couple of others like me, we would probably not do well with a stretch goal. The stretch goal would likely be in our minds and possibly even affect our ability to finish all of the main work of the sprint.

Other people--those unlike me--have what I’ll call a more mature attitude toward stretch goals. They can look at it as it’s intended. They can think, “OK, great if we get to it but no big deal if not.” Teams comprising mostly people like that will probably do quite well with a stretch goal.

So: Should your team have a stretch goal in their sprints?

This really has to be up to the team. Unless I’m on the team. Then the answer is no.

Does Your Team Use Stretch Goals?

What do you do? Does your team use stretch goals? Does it help? Please share your thoughts in the comments below.

Managing Programmers

From the Editor of Methods & Tools - Tue, 02/09/2016 - 15:24
Programmers are not like the other kids. They cannot and should not be managed like normal people if your intent is to produce high quality software. The things you would do to make the process go faster will actually make things go slower. This session gives you insight on the care and feeding of programmers, […]

Thinking About Servant Leadership and Agile Project Management

For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management.

I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way.

If you are looking to increase your servant leadership and help your project team (or program), check out the Influential Agile Leader.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 02/08/2016 - 21:17

They constructed ladders to reach to the top of the enemy's wall, and they did this by calculating the height of the wall from the number of layers of bricks at a point which was facing in their direction and had not been plastered. The layers were counted by a lot of people at the same time, and though some were likely to get the figure wrong  the majorly would got it right .... Thus, guessing what the thickness of a single brick was, they calculated how long their ladder would have to be. - Thucydides, The Peloponnesian War

So when you hear, we don't need to estimate to know when we're done, that willfully ignores all the naturally occurring variances and the event based variances in all our project work. The Greeks knew this, we need to heed their advice.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sun, 02/07/2016 - 03:56

One's originality comes in your inability to emulate your influencers - Dale Watson

Categories: Project Management

Agile at Scale - A Reading List (Update 9)

Herding Cats - Glen Alleman - Sat, 02/06/2016 - 19:30

Screen Shot 2015-11-30 at 8.59.46 AMI'm working two programs where Agile at Scale is the development paradigm. When we start an engagement using other peoples money, in this case the money of a sovereign, we make sure everyone is on the same page. When Agile at Scale is applied, it is usually applied on programs that have tripped the FAR 34.2/DFARS 234.2 levels for Earned Value Management. This means $20M programs are self assessed and $100M and above are validated by the DCMA (Defense Contract Management Agency).

While these programs are applying Agile, usually Scrum, they are also subject to EIA-748-C compliance and a list of other DID's (Data Item Description) and other procurement, development, testing, and operational guidelines . These means there are multiple constraints on how the progress to plan is reported to the customer - the sovereign.

These programs are not 5 guys at the same table as their customer exploring what will be needed for mission success when they're done. These programs are not everyone's cup of tea, but agile is a powerful tool in the right hands of Software Intensive System of Systems for Mission Critical programs. Programs that MUST, deliver the needed Capabilities, at the Needed Time, for the Planned Cost, within the planned Margins for cost, schedule, and technical performance.

One place to start to improve the probability that we're all on the same page is this reading list. This is not an exhaustive list, and it is ever growing. But it's a start. It's hoped this list is the basis of a shared understanding that while Agile is a near universal principle, there are practices that must be tailored to specific domains. And one's experience in one domain may or may not be applicable to other domains. 

Like it says in the Scrum Guide. 

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

And since Scrum is an agile software development framework, Scrum is a framework not a methodology. Scrum of Scrums, Agile At Scale, especially Agile at Scale inside EIA-748-C programs has much different needs than 5 people sitting at the same table with their customer with an emerging set of requirements where the needed capabilities are vague until they appear.

One of the classes every aspiring grad student has to take is research methods. This class teaches the PhD hopefuls (I didn't make the cut and got a consolation prize of a MS), all about doing research and preparing to be a real scientist. A topic in this class is literature search. This makes sure that your cleaver idea of a research topic, in case your advisor hasn't gotten around at actually talking to you, has already been taken, researched, and solved. This is one problem in the physics world - you need an original idea. Replicating old ideas doesn't get you very far.

Here's a start of a literature search on merging Agile at Scale with Earned Value Management. I haven't gotten to the European and Far East journals yet. 

Slicing Work Into Small Pieces Agile Software Development in the DOD Technical Performance Measures What Do We Mean When We Say "Agile Community?" Can Enterprise Agile Be Bottom Up? How To Measure Anything Business Rhythm Drives Process Empirical Data Used to Estimate Future Performance Related articles
Categories: Project Management

What Does Agile Mean to You?

Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference.

I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile.

I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process.

I like anything that helps management ask the right questions and create an environment in which teams can succeed.

Dogma doesn’t work very well for me. (I know, you are so surprised.)

If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?”

Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you.

If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile Leader.

Categories: Project Management

What Does Agile Mean to You?

Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference.

I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile.

I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process.

I like anything that helps management ask the right questions and create an environment in which teams can succeed.

Dogma doesn’t work very well for me. (I know, you are so surprised.)

If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?”

Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you.

If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile Leader.

Categories: Project Management

The Dark Sides of Agile and Earned Value Management and Their Fixes

Herding Cats - Glen Alleman - Thu, 02/04/2016 - 16:08

Both Agile development and Earned Value Management are coming together in the Federal Government. DOD and many Federal Civil agencies are adopting the use of Agile software development. At the same time, FAR 34.2 and DFARS 234.2 are flow down on procurement programs that implement Earned Value Management.  

I've written about to benefits of this before, Here's some thoughts on the Dark Side

EVM+Agile the darkside from Glen Alleman Related articles Agile Software Development in the DOD Seven Principles of Agile Software Development in the US DOD What Do We Mean When We Say "Agile Community?"
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 02/03/2016 - 23:37

It is a capital mistake to theorize before one has data - Sir Arthur Conan Doyel

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 02/03/2016 - 20:07

Winnie-the-Pooh read two notices very carefully, first from left to right, and afterwards, in case he had missed some of it, from right to left - A.A. Milne, Winnie-the-Pooh

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

How Do You Estimate Work That's Never Been Done Before?

Herding Cats - Glen Alleman - Wed, 02/03/2016 - 18:09

This is a common lament in the #Noestimates community

We've never done this before, so how can we possibly estimate how long it will take?

Well the first question is has it actually never been done before, or is the real question is have YOU never done it before? If the work has truly never been done before by anyone, anywhere on the planet, then it's probably going to be hard to estimate. But if the solution has been done before, this brings up the big question for those paying to have the development done, why would they hire someone that has no prior experience providing solutions in the problem domain? 

Let's assume you have prior experience in the problem domain, but the solution is not readily at hand. This means the solution actually has to be engineered. This is the role of  the well developed process of producing the engineering basis of estimate.

Let's start with the notion of Reference Classes. Here's some databases of projects that can used as Reference Classes used to frame the boundaries of the estimating processes for what you may consider new and never before seen work, but in fact has been done by someone else.

  • Nederlandse Software Metrieken Association - www.nesma.org

  • International Software Benchmarking Standards Group - www.isbsg.org

  • Common Software Measurement International Consortium - www.cosmicon.com

Next is the notion that every graduate student in almost any discipline - mine was Physics - is taught in the first year of grad school. When you have an idea, go first and check that some one hasn't already solved the problem. This starts with a literature search. This is a simple problem to solve in 2016. It's called Google. In 1975 it required weeks is long days in the library looking through journals and books in the Physics Library UC Irvine. But before anyone says This is a new and innovative problem and I can't possibly estimate how long it will take. Do your homework and go see if that is actually the case.

When we hear - how can I possibly estimate what I haven't done before? There are more steps to go before answering I can't

  • Have you developed a process architecture for what you want done from this software? Is this process architecture in the form of some swim lane diagram?
  • Have the system elements been partitioned and their interfaces defined at the data and process level. This definition can be high level to assess coupling and cohesion issues that will drive up cost?
  • Have Use Case's been developed for the system functions? Have the common actors, processes, and data been identified?

This list goes on for awhile. But when I hear I can't possibly estimate something that I haven't done before, it begs the question ...

Do you know what Done looks like in units of measure meaningful to the decision makers?

No? then no wonder you can't put upper and lower bounds on any estimate of effort - you don't even know what the customer wants and most importantly you don't know what the units of measure are for what done looks like.

Go find those answers and them you'll have a clearer idea of what the problem is and possibly how to solve it.

Categories: Project Management

Awards Season

Herding Cats - Glen Alleman - Wed, 02/03/2016 - 16:34

Screen Shot 2016-01-19 at 6.40.39 PM

Read the full article at CEOLEVEL

Categories: Project Management

Value of Burndown and Burnup Charts

I met a team recently who was concerned about their velocity. They were always “too late” according to their manager.

I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they “committed” to for each iteration.

Burndown.StoryPoints

This is what their burndown chart looked like.

A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time.

An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up.

BurndownwithideallineThey tried this burndown chart next, to see if they could meet their ideal.

They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves.

They stopped doing retrospectives, which meant they had no idea why they were “late.”

A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story points here. You could look at story points against time, looking at the available hours or people days or something like that.

For me, a burndown is interesting, but not actionable. Think about what happens when you take a trip. You plug your destination into your favorite GPS (or app), and it calculates how much longer it will take to get to your destination. You know you have driven some number of miles, but to be honest, that’s done. What’s interesting to you is what you have remaining. That’s what a burnup chart helps you see.

For me, a burnup is a way to see what we have accomplished and what’s remaining. I can learn more from a burnup than I can from a burndown. That’s me. Here’s a burnup of the same data:
StoryPointBurnup

I made these charts from exactly the same data. Yet, I have a different feeling when I see the burnups.

When I see the Story points Done without the ideal line, I see a hockey stick. It’s not as bad a stick as the image in Is the Cost of Continuous Integration Worth the Value on Your Program?, Part 1, and it’s still a significant hockey stick.

StoryPointBurnupwithIdealLine

When I see this burnup, I can tell by Day 3 that we are “behind” from where we want to be. By Day 5, I know we cannot “make up” the time. As any team member, I can raise this as an impediment in the daily standup. If I am a leader of any sort, I will put this on my list to discuss in the retrospective, if not problem-solve before.

Maybe that’s just the way my mind works. I like seeing where we are headed and what it will take to get there. I’m interested in what we’ve done, but that’s in the past. I can’t address the past except to retrospect. I can address the future and say, “Is there something we can do now to help us accomplish what we thought we could in this timebox?”

George Dinwiddie has a great article on burndown charts: Feel the Burn: Getting the Most out of Burndown Charts.

Oh, and the team I discussed earlier? They decided they were trying to cram too much into an iteration. They made their stories smaller. That put more pressure on their product owner, but then they realized lack of PO time was an impediment. They thought they were to blame with a burndown. They saw their data more easily with a burnup. Maybe we all had a mind-meld going on.

It doesn’t matter which chart you generate. It matters how the chart makes you feel: what action will you take from  your chart? If it’s not prompting you to act early, maybe you need a different chart. One project truism is: You cannot “make up” time. You can choose actions based on what your data tells you. Can you hear your data?

Categories: Project Management

Successful Software Development Project Failures

From the Editor of Methods & Tools - Mon, 02/01/2016 - 15:10
Software development projects have always been challenging. The most referenced source for metrics about project success is the Standish Group yearly CHAOS report. According to this source, around 30% of software development project were considered as a “failure” in the recent years. The failure rate of larger projects is a little bit higher than the […]

NOT Negotiating Estimates is Example of Bad Management (Update)

Herding Cats - Glen Alleman - Fri, 01/29/2016 - 22:03

A recent Blog post used an example of negotiated estimates between the developers and management. In the example buying a car is used and compared to negotiated the cost of software development. The car was an example of knowing information about what was being negotiated and the software was a example of not knowing what was needed to produce an outcome.

The notion that in the software business we don't know or can't know what the cost, schedule, and outcomes are before we reach the end is sadly misinformed. One of my colleagues - a former NASA cost director - has three reasons projects go over budget, get behind schedule and don't produce the needed benefits:

  • We couldn't know - it was a true science project - inventing new physics
  • We didn't know - because we were too lazy to do our home work, and come up with some assessment of what it could cost
  • We don't want to know - because if we knew we'd never start the project, or we'd cancel the project now that we know

So let's pursue the car negotiation versus software negotiating on what something will cost a bit further

When negotiating the purchase of a car, the dealer starts with a price based on facts. The price paid at wholesale, the cost of money for flooring the car until it's sold. The buyer of the car usually comes equipped with facts as well. Edmunds pricing, Consumer Reports pricing, and similar sources of cost, margins, dealer incentives, local market conditions.

When the negotiations are successful, when there is a mutual beneficial outcome between the two parties - there is no asymmetric negotiating  position. For the dealer, he moves a car, stops paying on the 90 day flooring note needed to put the car on the lot, and the buyer gets the car at an acceptable cost. 

If we accept that estimates are for the business to make decisions more often than they are for developer decision, then facts are needed on both sides for a negotiation to have any mutual beneficial outcome for the business and those provided value to the business in exchange for the cost of that value.

When there is no factual basis of estimate, those asking for the estimate - the business, and there is no basis on which the judge the estimate provided by those being asked - the developers - there is no foundation for a mutual beneficial outcome. The result is an asymmetric negotiation. Those with the money usually win.  

When negotiating the cost of software development effort between the person asking for an estimated cost and the developers providing the software, there is a similar process. When the developer says it will take 5 units of cost (hours, weeks, months) and those asking for the estimates say “I need it in 3” AND there is no basis of estimate for either 5 or 3, there is no means to actually negotiate and the result is those paying.

Those with the money have the final say on how much and when. The developers have no recourse, since they don't possess a credible counter offer showing that the real cost is 5. The developers are on the wrong side of an asymmetric negotiation. 

Until those being asked - the developers - come to the table with credible, verifiable, statistically sound estimates, this relationship between those asking and those providing will never change. Those providing the estimate - and consuming the money need to have a credible basis of estimate. Those providing the money also need to have some sense of what a credible estimate looks like. This removes the asymmetric relationship and creates a symmetric relationship on which to actually negotiate a mutually beneficial outcome.

This by the way is one source of dysfunction the #NoEstimates advocates love to use without ever stating what is the source of the dysfunction. The Dysfunction is the asymmetric relationship between the parties. The buyers have a target, the sellers are clueless if that  is a reasonable target - end of conversation.

Showing up with NO counter estimate to a requested number - is a self-inflicted wound in the negotiating business. The result is those with the money get to tell those without the counter estimate what to do and it turns into a lose-lose outcome. Then the developers blame the estimating process for the resulting dysfunction and wonder why the business no longer listens to them.

You asked me to do it for 5 and I have no counter offer, so you win and actually we all lose. Then blame the request for estimating for the dysfunction. 

It is conjectured by #NoEstimates advocates that removing the estimating process will fix the dysfunction (what ever that is). Of course making decisions in the presence of uncertainty requires knowing something about outcomes as a result of the decision. But without a starting point for the estimate on the part of those spending the money, the asymmetric negotiating position cannot be removed. This is the actual source of Bad Management and cannot be the fix, since the negotiation is one sided and those with the money prevail when there is no counter offer. 

This is like walking into the car dealer wanting to buy a car, with no understanding of the cost of the car you want - your the business. No Morhoeny Sticker. No web pricing. No nothing. And the dealer - the developers - doesn't tell you what the price of the car is either, because it's too hard, is waste of time, and believe they'll be held to the price they say.

Update

Gene Hughson added his voice to negotiating estimates

And I fixed the title to be less obtuse

Related articles Domain is King, No Domain Defined, No Way To Test Your Idea Some more answers to the estimating questions Start with Problem, Than Suggest The Solution How to Avoid the "Yesterday's Weather" Estimating Problem Incremental Commitment Spiral Model No Estimates Needs to Come In Contact With Those Providing the Money The Microeconomics of Decision Making in the Presence of Uncertainty Want To Learn How To Estimate? Estimating Software-Intensive Systems
Categories: Project Management