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.

Five Immutable Principles of Project Success and Project Failure

Herding Cats - Glen Alleman - Fri, 09/30/2016 - 02:43

I saw a blog post about the Top 5 Reasons Your Project Fails recently. They were all good reasons, but those reasons were symptoms, not causes. We seem to always identify the symptoms, but until we fix the cause of failure, those symptoms will return.

The symptoms were:

  1. Priorities change.
  2. Incomplete requirements.
  3. Lack of Resources.
  4. Lack of User Support.
  5. Lack of Executive Support.

But these are simply missing practices and processes of the 5 Immutable Principles of project success

5 Immutable Principles

So let's look at the symptoms and the principle that could have addressed that symptom

  1. What Does Done Look Like?
  2. What is the path to Done?
    • Without a Plan, we have no visibility to the steps needed to reach Done.
    • As Yogi Berra says¬†If you don't know where you're going, you'll end up someplace else.
  3. Do we have enough  time, resources, and money to get to Done?
    • Without a plan, we can't know how many resources will be needed, what kind of resources, and when they will be needed
    • That time, resources, and money are actually random variables, drawn from an underlying population. The distribution of this population can be determined through a variety of means.
  4. What impediments will we encounter along the way to Done?
    • Risk Management is how Adults Manage Projects - Tim Lister
    • What are the risk, what are their mitigations
  5. How do we know we are making progress toward Done?
    • Measuring Physical Percent Complete is the foundation of all good project management
    • This physical¬†percent complete can be represented as¬†effectiveness, performance, key performance parameter, and other technical¬†measures

So with the 5 symptoms assigned to the 5 Principles, corrective actions can be put in place to avoid the outcomes.

Related articles Want To Learn How To Estimate? Capabilities Based Planning First Then Requirements Risk Management is How Adults Manage Projects Root Cause of Project Failure
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 09/29/2016 - 15:23

Never attribute to malevolence what is explicable by incompetence. - Robert J Halon

When we hear all the bad things that go  wrong with projects. The misuse and abuse of data, people, tools, and processes, I get a smile when I remember Halon's quote.

Removing things, changing things, installing new things will not address the root cause of bad management and especially bad project management. Only replacing the people will fix the root cause when they are willfully ignorant of how to do it right. 

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Estimating Resources

Herding Cats - Glen Alleman - Wed, 09/28/2016 - 19:54

There's a never-ending opportunity to learn how to estimate in the presence of uncertainty. Here's some resources for informing that learning process. 

When you hear that estimates are a waste (we'd rather be coding), estimates are fiction, we're bad at estimating, and the plethora of other excuses for not learning how to estimate, ask if that person has done the minimal homework to learn how to estimate needed to make decisions in the presence of uncertainty found on all software development projects.   Don't need estimates? - the project is de minimis  Related articles Want To Learn How To Estimate? How We Make Decisions is as Important as What We Decide. Herding Cats: Where Are We Going, Doesn't Much Matter It Seems Herding Cats: Estimating on Non-Trivial Software Projects Taxonomy of Logical Fallacies
Categories: Project Management

Software Development Conferences Forecast September 2016

From the Editor of Methods & Tools - Wed, 09/28/2016 - 15:01
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

The Sprint Review as a Sign-Off Meeting

Mike Cohn's Blog - Tue, 09/27/2016 - 15:00

Some teams use the sprint review as a time for product owners or key stakeholders to formally approve the product backlog items completed during the sprint. Is this a good idea?

In general, a sprint review should not be used by a team to get formal sign-off on their work from their product owner. The team and product owner should be working so closely during a sprint that the team knows what the product owner thinks of what they’ve built.

No surprises is my No. 1 rule for the sprint review.

It is absolutely acceptable for a product owner to reject the work of a team on a product backlog item. But the team should know that’s coming.

Team members should not walk into a sprint review expecting glowing praise from the product owner but then be blindsided by a litany of complaints about a feature.

But what about acceptance by a client? Can a sprint review be used for formal sign-off or acceptance in those cases?

Ideally, in cases in which a client hires a vendor to develop a product, someone at the the client company would act as the product owner. And in those cases, it can be OK for formal sign-off on features to occur during the sprint review. But I’d still stick with the advice that there should be no surprises during the review.

Even though the client product owner is providing feedback to the team during the sprint, it’s possible that the product owner needs to wait to fully accept something until other stakeholders have a chance to comment on the work.

As a simple example, my daughter recently asked me if she could go on a school trip. I said it was fine with me, but--guess what--we needed to check that it was OK with her mother. That is, my wife might have had plans for our family during that time that I didn’t yet know about.

This will be a common situation for client product owners in contract development situations. The product owner interacting with the team daily may like how a feature has been built, but may need to confirm that the stakeholders he or she represents agree. Sure, we can say that the product owner should simply go ask. But that can be impractical and might best be done in a sprint review.

But in outsourced, contract development, the client doesn’t always provide the product owner. Many times, the client hires the vendor to take care of everything.

The client is, of course, the true product owner. The client will ultimately accept or reject what is developed. But, on a day-to-day basis, the client doesn’t want to be “bothered.” And so the typical solution in this case is for the vendor to appoint a product owner from someone within its own organization.

And in this case, true acceptance (or “sign off”) on product backlog items cannot happen before the sprint review. The true product owner (from the client) is not sufficiently available and engaged to accept things any more frequently.

Sure, the team may have a preliminary sign-off from their own product owner representative during the sprint. But the true, client product owner may completely reverse that decision in the actual sprint review.

So the ultimate answer depends, like so many things, upon the context in which you’re operating. And so I’ll say that I’m not too concerned by actual, formal sign-off occurring during a sprint review. But I always want to stick with a policy of no surprises during the review.

Sign off or not, as needed. But the team should always have a good idea of what’s coming before they get to the review.

What Do You Do?

What does your team do in sprint reviews? Has the product owner largely seen everything before then? Are product backlog items formally accepted during the review? Please share your thoughts in the comments below.

Agile Estimating Methods and Impact on Project Development Performance Index

Herding Cats - Glen Alleman - Tue, 09/27/2016 - 01:40

The presentation "Quantifying the Impact of Agile Practices," Larry MacCherone at the RallyOn 2013 Conference, presents some results on estimating impacts. The chart below shows 4 estimating types, including No Estimates, the sample sizes for each type and the components that make up the estimating types.

The Software Development Performance Index (SDPI) scale on the left ranges - by eyeball measurement - from 46 to 55.

Screen Shot 2016-09-16 at 8.46.28 AM

The Higher the number the better the performance of the process. The presentation speaks to the components of the index further.

But first another piece of information ...

Teams doing Full Scrum have 250% better Quality than teams doing No Estimating

But are these differences meaningful statistically?

Let's start with several reading assignments, before answering

  • How to Lie with Statistics, Darrell Huff - this is a¬†must¬†have book for anyone working in an environment¬†where numbers are used to make decisions.
  • Statistics: A Very Short Introduction, David J. Hand, Oxford University¬†Press - this is a short summary of all the other books on statistical processes sitting on my office shelf.
  • The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty, Sam Savage - another¬†must have¬†book to learn that those tossing around numbers are likely¬†unaware of the flaws in their logic.

Let's start with the numbers from the chart

Since the raw underlying data is not available, we can't do any p-Factor assessment from the population samples, but there is a simple question that can be asked.

Are there any statistical differences between the 4 SDPI's? If you look below at the quick and dirty assessment of the only data available, it looks like all 4 approaches are within a single digit variances of each other. Not that useful actually. 

Screen Shot 2016-09-16 at 12.26.22 PM 

So the critical question still remains

How can you make a decision in the presence of uncertainty without estimating the impact of that decision?

 

Related articles The Actual Science in Management Science Carl Sagan's BS Detector How to Estimate Software Development Statistical Significance Monte Carlo Simulation of Project Performance Managing by (mis)quoting Deming Mr. Franklin's Advice Mike Cohn's Agile Quotes Flaw of Averages
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 09/26/2016 - 16:20

The essence of mathematics is to not make simple things complicated, but to make complicated things simple - Stan Gudder 

This notion that estimating is hard, estimates are a waste because they are always wrong, willfully ignores the basic mathematics of making decisions of in presence of uncertainty. The foundation of all decision-making, Probability and Statistics. Without this understanding there can be no credible information provided to the decision makers. 

Categories: Project Management

Where Are We Going, Doesn't Much Matter It Seems

Herding Cats - Glen Alleman - Sat, 09/24/2016 - 17:15

Chesire Cat‚ÄúWould you tell me, please, which way I ought to go from here?‚ÄĚ
‚ÄúThat depends a good deal on where you want to get to,‚ÄĚ said the Cat.
‚ÄúI don‚Äôt much care where‚Äď‚ÄĚ said Alice.
‚ÄúThen it doesn‚Äôt matter which way you go,‚ÄĚ said the Cat.
‚Äú‚Äďso long as I get SOMEWHERE,‚ÄĚ Alice added as an explanation.
‚ÄúOh, you‚Äôre sure to do that,‚ÄĚ said the Cat, ‚Äúif you only walk long enough.‚ÄĚ

(Alice’s Adventures in Wonderland, Chapter 6)

When we hear

The idea behind the #NoEstimates approach to software development isn't to eliminate estimates but, rather, to explore other ways to solve problems without specifically asking, 'How long will it take?'

We first need to ask by what principle of decision making in the presence of uncertainty, what kind of business project has no interest in how long will it take? The answer seems to be a de minimis project. 

Because in the real world not Wonderland with Unicorns, those paying have some sense of where they want to go, how much they are willing to pay, how long they are willing to wait to get there, and what value will be produced by their investment. De Minimis projects have no concern for those answers.

And those spending that customers money appear not very interested in applying known solutions, instead are answering with the Cheshire Cat's words, since the No Estimates advocates appear to live in Wonderland.

For those interested in learning how to produce credible Estimates and make decisions in the presence of uncertainty, here's some starting places that have served me well:

  • How to Measure Anything, Douglas Hubbard.
  • The Flaw of Averages - Why We Underestimate Risk in the Face of Uncertainty, Sam L. Savage.
  • Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban and Scrum Projects Using Monte Carlo Simulation, Troy Magennis.
  • Decision Analysis for Management Judgement, Paul Goodwin and George Wright.

There are many dozens of other books, and 100's of papers describing how to make estimates in the presence of uncertainty. 

After you do some reading and you hear someone say, estimates are hard, estimates are guesses, estimates are always wrong. estimates are a waste, we can decide with estimates, you'll know they didn't read any of these, haven't a clue what they're talking about, and just making things up as the go. Just like the cat

Related articles Flaw of Averages The Reason We Plan, Schedule, Measure, and Correct Essential Reading List for Managing Other People's Money The Flaw of Empirical Data Used to Make Decisions About the Future Making Decisions In The Presence of Uncertainty Decision Making in the Presence of Uncertainty Why Guessing is not Estimating and Estimating is not Guessing IT Risk Management
Categories: Project Management

Business Dysfunction, Malfunction and Strategy

Herding Cats - Glen Alleman - Thu, 09/22/2016 - 20:03

Mike Cottmeyer posted

This is an interesting article that misses the point of what's going on. Companies have too much management because they are poorly architected and not organized around value producing assets. When you don't have sufficient encapsulation, you end up with too much orchestration. Management is not the problem. It's a symptom of the problem. Firing, or redeploying managers, without fixing the underlying organizational issues will fail cause you to faster and harder. The solution is to refactor the organizational architecture, increasing encapsulation, and then redeploy managers as you are able to reduce the need for them.

The root cause of this dysfunction is the lack of line of sight traceability for Why the firm is in business to how the firm fulfills the strategy needed to deliver on that WHY.

Here's one way that has been shown over the years to connect the dots between Why and How and critically importantly, how the projectize the work efforts needed to implement the strategy.

Notes on balanced scorecard from Glen Alleman With Balanced Scorecard concepts from this briefing, go read Execution: The Discipline of Getting Things Done, then you'll have a foundation for correcting and even avoid what Mike talks about Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Deadlines Always Matter
Categories: Project Management

Manage Your Workshops with Workshop Butler

NOOP.NL - Jurgen Appelo - Wed, 09/21/2016 - 21:00
Workshop Butler

I am officially an investor now.

I have always been an investor. After all, I have always invested my time, energy, and resources in ideas that seemed to make sense to me. That’s what entrepreneurs do!

But now, I have taken my Lean Funding approach to invest in someone else’s idea. Actually, it is my idea as well, but I have no time to pursue it. I happily let Sergey Kotlov take our idea in a new direction and grow it into something fantastic.

Whether you organize workshops for managers, developers, marketers, or yoga students, there are always things you need to do for your classes, particularly when you work with more than one trainer:

  • Manage your trainers and their licenses
  • Publish the event schedule on your website
  • Provide info about topics, locations, and trainers
  • Process registrations online
  • Send notifications to participants
  • Process feedback and evaluations
  • Produce certificates of completion
  • and much more

Not surprisingly, Workshop Butler started its life as the back-end system for all Management 3.0 workshops worldwide. It has served the brand well, with more than 100 facilitators using the system on a regular basis.

Now, Workshop Butler has evolved to power other brands as well, including Collaboration Superpowers, Lean Change Management, and more.

If you offer classes under a brand name, with multiple trainers, various topics, and different locations, I suggest you check out the Workshop Butler public beta and get Sergey Kotlov to show you around the system.

It would make me happy. {8-)

The post Manage Your Workshops with Workshop Butler appeared first on NOOP.NL.

Categories: Project Management

Acceptance Tests & Agile Teams Coaching in Methods & Tools Fall 2016 issue

From the Editor of Methods & Tools - Tue, 09/20/2016 - 13:13
Methods & Tools ‚Äď the free e-magazine for software developers, testers and project managers ‚Äď has published its Fall 2016 issue that discusses alternatives to acceptance tests, Agile transformation, software project estimation, Agile coaching and the following free software tools: DbFit, generjee, Mox. Methods & Tools Fall 2016 issue content: * Alternatives to Acceptance Tests […]

The #NoEstimates Paradigm and Response

Herding Cats - Glen Alleman - Mon, 09/19/2016 - 02:32

Thanks to Sean Craig's Live Sketch Note for capturing concepts directly from Woody Zuill's talk. This is a good starting point for answering the mail on the notion that decisions can be made in the presence of uncertainty without estimating the impact of those decisions.

NoEstimates Map

Let's look at these Notes and plausible responses to the conjectures. But first, let's look at the motivation for a blog post like this one from Bono's admonition ...

There‚Äôs nothing more dangerous than an idea ‚Äď or a person ‚Äď that‚Äôs almost right. ‚Äď Bono

I attended our Agile Meetup last night, where the speaker walked through  the three current Agile at Scale development methods, all based on Scrum - SAFe, LeSS, and Nexus. He had an interesting statement.

Each of the authors have a different, sometimes slight, sometimes major, approach to producing software using their methods. But each author (or currator of the mehod) has extensive experience testing that method in the field against a broad range of domain and environments. 1,000 to 10's of 1,000's. There is no sure basis of credibilityy for the No Estimates conjecture that decision can be made in the presence of uncertainty without first estimating the impact of the decision. 

When we hear a suggestion about a process that inverts the logic of normal business activities based on a governance framework - say Microeconomics of Software Development, we need to ask who benefits? How would that suggestion be tangibly beneficial to the recipient that is now inverted?

Estimates are for the business, why would the business no longer want an estimate of cost, schedule, or technical performance for the provided capabilities they are paying to have developed?

Turns out of course, it's not the business that has lost the need to estimate, it's those spending the money provided by the business that are suggesting estimates are not needed. This conjecture started long ago when an original post, from his chief coder position at the lawn sprinkler company. (I have those sprinkler heads on my lawn, and they're pretty nice). But his conjecture starts with estimates are a waste, not saying for whom they are a waste for.

Anyone in the finance department, paying his salary, paying the developers has a fiduciary need to know what something will cost when it is done. And since ALL and I Mean ALL software development operates in the presence of uncertainty, the only when to have knowledge of that cost, schedule, and technical content is to make estimates. The further conjecture that estimates are hard, can't be made, and are always wrong, simply affirms that those making those claims don't know how to estimate. That is clear, but that has nothing to do with the principles of estimating in the presence of uncertainty.

I'm no longer a developer, having left development in the early 80's after a career of writing FORTRAN 77 code for missile defense systems that is still in place today. But that has nothing to do with the principles, practices, and processes of writing code using current languages and tools. If you find it hard, but go find someone who doesn't find it hard. 

So let's look at what's being said here about managing software development in the presence of uncertainty using other people's money

Transformation comes from pursuing profound questions than seeking practical answers 

  • Let's assume we are in the business of spending other people'ss money to produce value in exchange for that money.
  • It is likely¬†those paying us have some sort of governance process in place for managing the spend of that money
  • Governance is about¬†decision rights. Who has the¬†Right to decide?
  • Asking profound questions? Who's job is that? Those spending or those paying? This is a crass point of view I know. But in many ways business is crass, harsh, rude, to the point. It's about the money. Unless we live and work in a socialist society, someone has to pay for our efforts. That¬†someone¬†has and expectation of¬†getting their money back, plus some more some time in the future. That expectation is called Return on Investment and requires some knowledge about the future - the uncertain future - to make a decision today.
  • So¬†practical answers are less important than¬†profound questions? Interesting conjecture. Who's most interested in¬†practical answers and¬†profound questions? Those paying or those spending.¬†

It's not your money

Here's an extract from a Deloitte handbook about business decision making

Effective governance and decision making establishes a framework for transformation and can improve the odds of solidifying change and realizing the benefits of transformation.

  • So when we hear about transformation what does that actually mean?
    • Transforming how the business works? Process improvement?
    • Transforming how we develop software? New methods, processes, tools?
    • Transforming how we spend money? Better ROI, some magic formula for better ROI?
    • Woody doesn't say. It's just¬†transformation.
  • What are the profound questions?
    • For the business, a few profound¬†questions of a time cost of money project¬†are likely
      • When will we be done?
      • Will we show up on the needed date with the needed Features?

Control and Certainty about What?

  • There is no such thing as certainty on projects - this is a¬†false argument, had been a false argument since man started building things, anything, not just software.
    • Projects are uncertain. Uncertanity creates risk.
    • Uncertainty come in two¬†types and these two types of uncertainty¬†are always present on projects
      • Reducible uncertainty - Epistemic uncertainty, which can be handled with margin and redundancy
      • Irreducible uncertainty - Aleatory uncertainty, which can ONLY be handled with¬†margin
    • Uncertainty is the source¬†risk. Risk does not exist in the absence of uncertainty.¬†
      • Risk Managment is How Adults Manage Projects - Tim Lister
      • Risk management requires making estimates of the probability of occurrence, the statistical¬†behaviour of underlying processes, the probability of the impact of the risk if it were to come true and become an issue, the probability¬†of the residual risk even after the actual risk has been mitigated

If you're not managing risk, if you're not making estimates about these risk, you're not managing the project as an adult

 Control our Urge to Control Things

  • Managing the spend of other people's money, while producing value in exchange for that money means having ¬†control to some degree of that spend process.¬†
    • Management is a verb
    • Management is a closed loop process
    • Close loop process makes use of¬†control to keep the process (development of software) moving toward the target
  • Without control, the project is Open Loop
    • Open Loop control doesn't use feedback to take corrective actions
    • Not estimating is Open Loop control. Another No Estimates advocate claims NE is closed loop control. I suspect he didn't attend a Process Control Systems class, nor has any understanding of control system loops.

If the types of decisions we make requires estimates, then are there better types of decisions?

  • This is typical question like¬†when did you stop beating your wife Senator? It's a question designed to have no answer but rather make some unsubstantiated statement.¬†
  • Not sure there are¬†types of decisions¬†unless there are decisions in the¬†absence¬†of uncertainty and decisions in the¬†presence of uncertainty
    • If there is no uncertainty, making a decision is easy, no need to estimate. It's obvious what to do, obvious the outcome.¬†
    • Never seen a project where there is no uncertainty. Even production lines have uncertainties¬†during the day.

If you accept that project have uncertainty, then making decisions in the presence of this uncertainty requires you estimate the impact of that decisions. #NoEstimates has yet to state how, in the presence of uncertainty, that a decision can be made with NO Estimates. Only that they are exploring for ways to to this. Been exploring for going on 4 years now, seems to have found nothing. Which would support the notion that the microeconomics of decision making is still in place and any decisions in the presence of uncertainty requires making an estimate.

The Fear of Losing Control is a Big Barrier to Change. Control is Illusion. Fear is Real

  • ¬†This is one of those platitude statements Woody love to make.
    • Would he say that about driving his car?
    • Would he say that about skiing in the back bowls of Vail?
    • Would he say that about his 401(k) investment plan?
    • How about the cost budget for the room addition to his house?
    • Closed loop control is¬†control¬†the in the presence of emerging drivers.
    • Open loop control is Not control from external drivers, but manual change.

Just another platitude without any basis in principles of closed loop business and technical management

The cycle of non-improvement

  • The cycle of¬†estimate, work, estimates off, requirements unclear, invest in better estimates and requirements is labelled as a cycle of¬†non-improvement.¬†
    • No root cause for this behavior, just a statement of bad behaviour
    • Without root cause, only the symptom is observed
    • Without root cause, any suggestion of a corrective action -¬†no estimates - has no credibility, since the problem has not been identified but the solution is proposed.
    • Any proposed solution to¬†stop doing something requires direct evidence that¬†not estimating will improve requirements fidelity and improve the probability of delivering the needed software as needed.

There is no evidence that No estimates improves anything for those paying for the software development. This is a consistent issue with the conjecture that No Estimates fixes problems, without idnetifying the root cause of the problem, testing the hypothesis that No Estimates fixies the problem, and that this fix can be syndicated beyound the personal ancedote of the orginal conjetcure

What is an Estimate?

This question has a simple answer. It is not a Guess. It is not a promise. This question and the answers used by No Estimates advocates is used to manipulate the situation. Bad Managers use estimates as promises. Those with no experience, skill, or knowledge of estimating consider estimates as Guess's. Both are wrong, both are behaving as if they are in a Dilbert carton, following the script of a dysfunctional set of characters.

There endless numbers of books, papers, tools, classes on how to estimate software projects. These have all been provided in this blog before and can be found again. But here's a starting place - Estimating Software Intensive Systems. Read this and you'll have the start of all you need to break the cycle of uniformed, unsubstantiated states about what is an estimate, how are they made, and how can they be used to make decisions in the presence of uncertainty

Most of the things that matter can't be measured

  • Matter to whom?¬†
    • It must matter to those paying
    • For those paying, measuring is a critical success factor for determining of the money is returning the expected value at the expected time
    • Without asking and answering that question Woody's quote has no basis of applicability

Let's establish a baseline here. We're writing software for money, usually other people's money. In this context - a business context, Lord Kelvin has good advice for us. Writing software for money is not about the self-actualization of the individuals on the team. That may an outcome, but those paying ae not paying to improve the staff's psychological wellbeing.

When you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind. ‚ĶIt may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science. -¬†Lord Kelvin (1824‚ÄĒ1907)

 So what is the quest of the advocates of No Estimates? It's not actually clear. 

  • Improve the probability of success of project work? Can't see how that can be, since making decisions in the presence of uncertainty - which appears on all projects - requires we make estimates about the outcomes of those decisions.
  • Reduce the work load on the developers of software products or services? Perhaps, but that leaves open the need to have some probabilistic understanding of where the project is going in the presence of uncertainty to someone else.¬†
  • Reduce or remove the¬†dysfunction¬†of managers in making decisions in the presence of uncertainty? Certainty not, since that uncertainty is present whether you estimate it's impacts or not. Not Estimating does not remove the dysfunction of humans.

I can only conjecture that the purpose of Not Estimating is to return control of the work processes to those doing the work by removing the decision making processes from those owning the money. It's the anarchistic approach to software development. 

I, the one providing the labor in exchange for payment, am the one who will be telling you, the paying, when I'll be done, how much it will cost when I'm done, and what you'll be getting for that time and money. I am the one in charge of the effort to spend your money.

 

 

Related articles Risk Management is How Adults Manage Projects Estimating is Risk Management Herding Cats: Book of the Month IT Risk Management Making Decisions in the Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty Herding Cats: Making Decisions in the Presence of Uncertainty Herding Cats: Connecting Project Benefits to Business Strategy for Success Estimating and Making Decisions in Presence of Uncertainty Your Project Needs a Budget and Other Things
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 09/17/2016 - 09:53

Screen Shot 2016-09-15 at 9.49.52 PM

While this quote appears inverted in our self-centered world, the expert has eliminated the nonsensical, naive, amateur, simple minded options and narrowed the choices based principles, practices, and processes of her profession. It is trivially easy to assert I'm exploring  new ways of doing things when there is no bounding governance principles to guide your exploration.  If the exploration takes place in a de minimis world, the options are boundless. 

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Herding Cats: Connecting Project Benefits to Business Strategy for Success Herding Cats: Estimating on Non-Trivial Software Projects
Categories: Project Management

Book of the Month

Herding Cats - Glen Alleman - Fri, 09/16/2016 - 20:12

SAFeThe SAFe Reference Guide is out.

The website has most everything you need, but it is hard to use and when printed in simplified mode doesn't contain the embedded pictures.

In our local Agile Meetup at Rally, Charles Bradley went through the 3 major methods for agile at scale - SAFe, LeSS, and Nexus

This book is a very useful even if you're not using SAFe, there is invaluable content in the book, including many pages on estimating.

As well as this book, at the Agile Meetup Charles provided a link to an Agility Guide and the site EB Management with lots of resources on Empirical Management

So get the book SAFe , it's the latest in how to manage software development At Scale. LeSS has similar advice, Nexus not so more, you have to attend their classes.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 09/15/2016 - 12:43

Thought interferes with the probability of events, and in the long run therefore, with entropy - David L. Waston (1930)

All project work is probabilistic, driven by underlying uncertainties, both reducible and irreducible. Willing an outcome in the presence of these uncertainties does not make is so. The only useful process to manage in the presence of uncertainty is to estimate the outcome of any decisions made by the participants of the processes by which the project operates

Related articles Managing in the Presence of Uncertainty Estimating Processes in Support of Economic Analysis Herding Cats: Book of the Month Herding Cats: Making Decisions in the Presence of Uncertainty Making Decisions In The Presence of Uncertainty Herding Cats: The Problems with Schedules
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 09/14/2016 - 12:39

It is probably dangerous to use this theory of information in fields for which it was not designed, but I think the danger will not keep people from using it - J. C. R. Lickider (1950)

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Trust But Verify

Herding Cats - Glen Alleman - Wed, 09/14/2016 - 01:10

The mantra of Agile is¬†Trust the team. In some domains, that is an admirable goal. In other domains it's a na√Įve path to disaster. I work in the latter domain, on mission critical, sometimes¬†national asset¬†programs, but always mission critical - can't fail, must work, must provide proper information when called upon to do so.

When we are called on to perform a Root Cause Analysis of why the system failed to do what it was suppose to be, we find the same thing that Dr. Bill Corcoran suggest is found on all root cause analysis processes.

An inescapable fact is that the competent investigation of every harmful event reveals that the causation of the harm includes the mistaken/ na√Įve/ unwarranted/ gullible/ imprudent trust and confidence in one or more erroneous/ untrustworthy theories, assumptions, standards, devices, procedures, processes, programs, people, institutions, agencies, contractors, and/or conditions. The functional alternatives include monitoring, curiosity, skepticism, and the ‚Äúquestioning attitude.‚ÄĚ

Here's some quotes to apply when you hear agile means trust of the team, why are you questioning our processes, our methods, our organizational models. (Thanks to Dr. Corcorn's news feed today):

  • You get what you inspect; not what you expect¬†- An old U.S. Navy proverb
  • Trust, but verify¬†- Quoted by President Ronald Reagan
  • A sucker is born every day -Attributed to P. T. Barnum
  • The world abounds in unrocked boats with holes just above the current waterline -Salty Wisdom
  • Faith is believing for sure what ain‚Äôt so¬†-Mark Twain
  • In God we trust; all others please furnish evidence - Unknown for now

So saying it again for clarity - you can't make a decsion in the presence of uncertaty without estimating the outcome of that decision. When you do, be preared to conduct a Root Cause Analysis of why your project went in the ditch. Trust is necessary but far from sufficient when spending other people's money on non-trivial development efforts.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty Are Estimates Really The Smell of Dysfunction? Making Conjectures Without Testable Outcomes Good Project and Bad Project Estimates
Categories: Project Management

Trust But Verify

Herding Cats - Glen Alleman - Wed, 09/14/2016 - 01:10

The mantra of Agile is¬†Trust the team. In some domains, that is an admirable goal. In other domains it's a na√Įve path to disaster. I work in the latter domain, on mission critical, sometimes¬†national asset¬†programs, but always mission critical - can't fail, must work, must provide proper information when called upon to do so.

When we are called on to perform a Root Cause Analysis of why the system failed to do what it was suppose to be, we find the same thing that Dr. Bill Corcoran suggest is found on all root cause analysis processes.

An inescapable fact is that the competent investigation of every harmful event reveals that the causation of the harm includes the mistaken/ na√Įve/ unwarranted/ gullible/ imprudent trust and confidence in one or more erroneous/ untrustworthy theories, assumptions, standards, devices, procedures, processes, programs, people, institutions, agencies, contractors, and/or conditions. The functional alternatives include monitoring, curiosity, skepticism, and the ‚Äúquestioning attitude.‚ÄĚ

Here's some quotes to apply when you hear agile means trust of the team, why are you questioning our processes, our methods, our organizational models. (Thanks to Dr. Corcorn's news feed today):

  • You get what you inspect; not what you expect¬†- An old U.S. Navy proverb
  • Trust, but verify¬†- Quoted by President Ronald Reagan
  • A sucker is born every day -Attributed to P. T. Barnum
  • The world abounds in unrocked boats with holes just above the current waterline -Salty Wisdom
  • Faith is believing for sure what ain‚Äôt so¬†-Mark Twain
  • In God we trust; all others please furnish evidence - Unknown for now

So saying it again for clarity - you can't make a decsion in the presence of uncertaty without estimating the outcome of that decision. When you do, be preared to conduct a Root Cause Analysis of why your project went in the ditch. Trust is necessary but far from sufficient when spending other people's money on non-trivial development efforts.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty Are Estimates Really The Smell of Dysfunction? Making Conjectures Without Testable Outcomes Good Project and Bad Project Estimates
Categories: Project Management

Software Development Linkopedia September 2016

From the Editor of Methods & Tools - Tue, 09/13/2016 - 15:11
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about being a better developer, software architecture, tech leadership, shrinking the product backlog, customer journey maps, using sprint data, distributed testing, domain driven design, continuous delivery and testing microservices. Blog: Finding […]