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&page=5' 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.

What Is Management in the Context of Agile

Herding Cats - Glen Alleman - Sun, 04/17/2016 - 23:07

There's a meme going around in some parts of agile that management is inhumane. This is an extreme view of course, likely informed by anecdotal experience with Bad Management, or worse lack of actual management experience.

Managing in the presence of Agile is not the same as managing in traditional domains. The platitude is Stewardship, but that has little actionable outcomes needed to move the work efforts along toward getting value delivered to customers in exchange for money and time.

One view of¬†management in Agile can be informed by Governance of the work efforts. Here's a version of Governance, from "Agile Governance Theory: conceptual development,‚ÄĚ Alexandre J. H. de O. Luna, Philippe Kruchten , and Hermano Moura.

Screen Shot 2016-04-17 at 4.03.36 PM


Related articles Agile Software Development in the DOD Deadlines Always Matter Risk Management is How Adults Manage Projects Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Before looking to any solution to a problem, determine the Root Cause

Herding Cats - Glen Alleman - Thu, 04/14/2016 - 00:30

It is common to use the phrase 

If we feel pain X. Let's explore solutions? & possibly "Solutions A & B might be a starting point?"

This approach seeks a solution to the symptom not a solution to the problem

This is the false notion used by #NoEstimates advocates, with the conjecture that estimates are the smell of dysfunction. Without stating what the dysfunction is, then makes the statement that Not Estimating will fix it. So in the end nothing is fixed, the dysfunction is not identified, the Root Cause is not identified, and therefore is it not possible to claim Not Estimating will fix anything, for the simple fact that the problem has not been defined. It's a solution - at doubtful solution - looking for an undefined problem to solve. A lose-lose situation. 

So don't fall for the fallacy of the smell and most of all don't fall for the fallacy, we're just exploring and I have no recommended solutions.

The only way to provide an effective solution to any problem, is to determine the Root Cause to that problem and confirm that the proposed solution will in fact prevent the problem from recurring. If you want to learn how to do this - and not follow the naive 5 Whys - read this. Then if you're working in a domain that does Root Cause analysis buy the Reality Charting tool. It's saved us from catastrophe several times. 



Related articles The Dysfunctional Approach to Using "5 Whys" Are Estimates Really The Smell of Dysfunction? Root Cause of Project Failure Turning Editorials into Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty The False Notion of "we haven't seen this before" When the Solution to Bad Management is a Bad Solution
Categories: Project Management

Project Breathalyzer

Herding Cats - Glen Alleman - Wed, 04/13/2016 - 00:25

Screen Shot 2016-04-12 at 5.11.38 PM

The Project Breathalyzer provides question for the Program Manager to assess of the project is fit to be on the road. If the Program Manager cannot answer these questions about the current status, or answers in the negative , then the project is subject to a critical review.

This concept comes from the Software Program Managers Network, and the work of Norm Brown in 1997. The SPMN was a non profit organization, with funding canceled in 1002. but is now for Profit. The questions can from the Airlie Software Council of experts after the failure of the Airane 5 launch vehicle failure attributed to a Software Design Flaw.



Related articles Failure is not an Option Fit for Purpose, Fit for Use Assessing Value Produced By Investments
Categories: Project Management

My Book Tour in North America

NOOP.NL - Jurgen Appelo - Wed, 04/13/2016 - 00:15

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). This only applies to events taking place during my book tour in North America from June 30 to August 31.

You can see my public fees here: http://jurgenappelo.com/fees/

For private/in-company events, I request flexibility of the event date. My itinerary will be very complicated. I aim to maximize the number of people I can meet in the same region and time span, and at the same time I must minimize the time wasted on travel.

Categories: Project Management

Announcing My First Certified Scrum Master Course in Austin

Mike Cohn's Blog - Tue, 04/12/2016 - 15:00

I'm coming to Austin!

I've wanted to offer training courses in Austin for a while, and the time is right. I'll be there for a Certified Scrum Master course on October 3-4, 2016. The course will be at the Doubletree Northwest Austin Arboretum.

We've got an early bird discount running. Register by September 5 and save $100.

Groups of three or more can also save $100 per person. Groups of 10 or more save $200 per person.

The last time I was in Austin, I was walking around downtown and stopped in a little bar because I liked the band I could hear as I walked by.

I sat down, and by the second song, I realized that blues legend Pinetop Perkins was sitting in on piano with the band. He was in his 90s by then and was still amazing to see.

Seeing Pinetop Perkins perform, meeting him and getting his autograph was an amazing experience.

I hope to have just as much fun in Austin this October. And I hope you'll join me for my first public Certified Scrum Master class there.

Where to Next?

I’m looking to add another city or two into my usual rotation. If you have a suggestion, please let me know in the comments below or by emailing us.

Quote of the Month April 2016

From the Editor of Methods & Tools - Tue, 04/12/2016 - 08:44
Having conversations is more important than capturing conversations is more important than automating conversations. Liz Keogh, “Behavior Driven Development”, http://www.slideshare.net/lunivore/behavior-driven-development-11754474, slide 14 mentioned in “More Agile Testing: Learning Journeys for the Whole Team”, Janet Gregory & Lisa Crispin

Find the Root Cause Before Assuming Your Fix Can Actually Fix Anything

Herding Cats - Glen Alleman - Sat, 04/09/2016 - 23:38

A burst of Tweets of No Estimates fixes these problems came across Twitter this morning. I won't repeat who they are attributed to, to protect the guilty. But here's a core concept that is totally missing from not only the No Estimates conjecture, but from most every discussion, where a solution is proposed before the problem has been defined. Let's start with Dean Gano's introduction to Apollo Root Cause Analysis, which is a George Bernard Shaw quote so fitting to the discussion of ignoring the root cause and going straight for a solution to the symptom - in many cases an Unnamed symptom.

Ignorance is a most wonderful thing.
It facilitates magic.
It allows the masses to be led.
It provides answers when there are none.
It allows happiness in the presence of danger.
All this while, the pursuit of knowledge can only destroy the illusion.
Is it any wonder mankind chooses ignorance?
~ George Bernard Shaw

So until the symptom is named - and the smell of dysfunction is not a symptom. Until the search for the root cause of the symptom, and applying the 5 whys to an unnamed symptom is applied properly, the root cause will be undetermined. Without discovering the root cause, there will be no chance that any suggested processes, method, or change in behaviors will have any impact on the symptom - named or unnamed.

To see how the statement Estimating is the smell of Dysfunction is seriously flawed and the¬†approach of asking 5 Whys equally flawed, please read¬†RealityCharting¬ģ Seven¬†Steps¬†to Effective¬†Problem-Solving and¬†Strategies¬†for Personal Success, Dean L. Gano

The Seven Steps are:

  1. Define the problem.
  2. Determine the known causal relationships to include the actions and condition of each effect.
  3. Provide a graphical representation of the causal relationships to include specific actions and conditional causes.
  4. Provide EVIDENCE to support the existence of each cause.
  5. Determine if each set of causes is sufficient and necessary to cause the effect.
  6. Provide effective solutions that remove, change, or control one of more causes of the event. Solutions must have been shown to prevent recurrence, meet our goals and objectives, be within our control and not cause other problems.
  7. Implement and track the effectiveness of each solution.

When one or all of these steps are missing, anyone conjecturing their solution - or worse conjecturing we're just exploring for the solution - that conjectured solution is NOT a solution, it's just unsubstantiated conjecture. 

One of my favorite quotes when hearing unsubstantiated claims is this:

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg - Abraham Lincoln

Calling estimating the smell of Dysfunction doesn't make estimating the smell of dysfunction. You've only identified an unsubstantiated symptom. Until you have found the cause and certainly can't suggest Not estimating is the corrective action.

When we have willful ignorance of the Microeconomics of decision making, managerial finance as a governance process for managing other people's money, denial that the uncertainties of projects - aleatory and epistemic uncertainty - can be addressed without estimates of the impact of those uncertainties. Then we are no better than the people mentioned in George Bernard Shaw's quote above. And we are doomed to repeating the symptoms that result from ignoring these principles of managing in the presence of uncertainty. 


Related articles The Dysfunctional Approach to Using "5 Whys" Carl Sagan's BS Detector Myth's Abound Making Conjectures Without Testable Outcomes Are Estimates Really The Smell of Dysfunction? Architecture -Center ERP Systems in the Manufacturing Domain The Fallacy of the Planning Fallacy IT Risk Management
Categories: Project Management

Is Macroeconomics and Social Science the Same as Software Development?

Herding Cats - Glen Alleman - Tue, 04/05/2016 - 15:48

There a popular notions in the agile development world that authors like Hayek and Taleb speak to how software development works. Let's look at one example. You Can’t Understand Agile Without Understanding Hayek. Let's look at Hayek's paper. "The Use of Knowledge in Society," F. A. Hayek, The American Economic Review, Vol. 35, No. 4, September 1945, pp. 519-530.

Let's look at the thesis of Hayek in light of software development and the decisions that must be made when spending other people's money in the presence of uncertainty. Below is from the paper, but download the paper and read the whole thesis. Hayek was a social scientist. He was not a program manager of engineered to order software intensive system of systems. His ideas have not held up well. Hayek and Modern Macroeconomics. So I'd suggest not spending your customers money before doing some more research.

What is the problem we wish to solve when we try to construct a rational economic order? 

On certain familiar assumptions the answer is simple enough. If we possess all the relevant information, if we can start out from a given system of preferences and if we command complete knowledge of available means, the problem which remains is purely one of logic. That is, the answer to the question of what is the best use of the available means is implicit in our assumptions. The conditions which the solution of this optimum problem must satisfy have been fully worked out and can be stated best in mathematical form: put at their briefest, they are that the marginal rates of substitution between any two commodities or factors must be the same in all their different uses.

This, however, is emphatically not the economic problem which society faces. And the economic calculus which we have developed to solve this logical problem, though an important step toward the solution of the economic problem of society, does not yet provide an answer to it. The reason for this is that the "data" from which the economic calculus starts are never for the whole society "given" to a single mind which could work out the implications, and can never be so given.

The peculiar character of the problem of a rational economic order is determined precisely by the fact that the knowledge of the circumstances of which we must make use never exists in concentrated or integrated form, but solely as the dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess. The economic problem of society is thus not merely a problem of how to allocate "given" resources-if "given" is taken to mean given to a single mind which deliberately solves the problem set by these "data." It is rather a problem of how to secure the best use of resources known to any of the members of society, for ends whose relative importance only these individuals know. Or, to put it briefly, it is a problem of the utilization of knowledge not given to anyone in its totality.

First some questions:

  • Is the economic data for the project available in a¬†single mind? - probably¬†not. But that data is likely available in a collection of artifacts. In our domain this is the Performance Measurement Baseline, which is¬†a time-phased budget plan for accomplishing work against which contract performance is measured. It includes the budgets assigned to scheduled control accounts and the applicable indirect budgets. The PMB is developed and evolves as the project develops and evolves. This is the basis of the Agile Product Roadmap and Product Release Plan (either cadence or capability based).
  • Is the character of the problem determined precisely? - Of course not. But margin, management reserve, analysis of alternative is standard project management process of dealing with the indeterminate elements of projects. This is also the core principle of Agile - evolutionary emergence of the needed requirements to fulfill the needed Capabilities.¬†
  • Is there knowledge of what resources can be applied to solving the problem? - On projects yes. The Organizational Breakdown Structure (OBS) is usually on baseline. People don't come a go at will. People have defined skills and capabilities. People - hopefully - don't have conflicting politics about what the project should be doing.

Is there vague and unfolding knowledge, driven by externalities, of what the project should be accomplishing, with uncertain and variable funding? With members of the project team having differing views of the outcomes from those paying for the project?

If so, the project has already failed, the members of the project team are on a death march (Yourdan) and should start looking for work elsewhere, before it gets canceled.

So like the other misrepresentations of seminal works, the agile community adopts this attractive ideas with little or no consideration or understanding of their principles. And most of all it those principles are applicable to software development or if those principles are even applicable in today's understanding of who the world works. Macroeconomics is the dismal science - treat it as such when developing software.

  • Software development is not Macroeconomics, it's Microeconomics.
  • Black Swans only exist on projects when there are¬†unknowables. If there are unknowables, the project is doomed from the start. If it's knowable, doesn't means it's known, but standard Risk Management has the means to deal with knowns and know unknowns - both reducible and irreducible.
  • If you're project doesn't have a plan - having¬†Balls isn't going to help. You'll go into the ditch just has fast. Product Roadmaps, Release Plans are core principles of Agile. When you hear this You don't always need¬†a plan Bro...¬†it's from someone who is NOT accountable for spending other people's money in the presence of uncertainty.

So whenever there is some conjecture that someone outside the software development domain has a principle that can be applied to Agile, test that idea first before spending any time and money acting on it. Especially if that time and money is not yours.

Related articles IT Risk Management Risk Management is How Adults Manage Projects Risk Management is How Adults Manage Projects Qualitative Risk Management and Quantitative Risk Management Domain and Context Are King, Then Comes Process and Experience Two Books in the Spectrum of Software Development What is a Team? Five Estimating Pathologies and Their Corrective Actions How Think Like a Rocket Scientist - Irreducible Complexity Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Summarizing the Results of a Sprint

Mike Cohn's Blog - Tue, 04/05/2016 - 15:00

The end of an agile sprint or iteration should be a relatively lightweight occasion. After all, it’s something that will be done at least once a month, and often much more frequently than that. So, it’s important that we don’t burden a team with any more process ceremony than necessary. Often a very simple sprint review is all that is needed.

A Sprint Summary Document

Sometimes, though, as a ScrumMaster, I like to produce a sprint summary document. This short document contains very brief details of what work was done during the sprint, when the sprint was, who was on the team, any key decisions that were made during the sprint, and perhaps a few important metrics.


There are two target audiences for a sprint summary document. The first is any interested outsiders. This could include the VP of development, executives, stakeholders, department management, other teams and so on.

The second audience is future versions of the agile team itself. I’ve been in many situations where a team wanted to look back in time. A sprint summary can provide that view. Let me provide an example.

This one team was feeling depressed about how few automated tests they were writing. In the prior sprint, they’d added only about 200 total automated tests, which they knew was too low for what their system needed.

Because their ScrumMaster had been producing sprint summary documents, I retrieved a summary from six months earlier.

I shared with the team that they had once been struggling to write even one or two automated tests per sprint. (They were refactoring code so that it could support automated testing and were learning the concepts and tools.)

By sharing this information with the team from their sprint summary, I helped them realize how far they had come. Yes, they still had a long way to go, but they had already started moving the mountain, and momentum was now on their side.

Without a sprint summary document to provide exact facts, I would have had to rely on memory or had to piece things together by digging through the source code repository.


While the specific contents of a sprint summary document are entirely up to you, there are a few things I’ve found to be helpful. These include ...


Simply list the start and end date of the sprint and the number of working days in the sprint. I also list the people who were on the team, how many days each was expected to be available and the approximate number of days each was actually available.

The number of days a team member worked may differ from the planned days available because of illness or because the person was pulled onto another project mid-sprint, for example.


Include any metrics here that are important to the ScrumMaster, stakeholders or the team. Keep it simple. I tend to include a graph or table of the velocity of the last 10 or so sprints (whatever horizon seems reasonable for your team). If you’re using burndown charts, include those.

You might also consider including things like the number of defects found or fixed, the number of automated tests added, code coverage, the number of builds deployed and so on.

If you are building the software for a client and need to report on cost, include things like billable hours and cost in this section.

But keep it simple.

Contents and Assessment

In this section, include a list of each product backlog item the team planned to do. Indicate whether the item was finished or not. And if the team estimates product backlog items (for example, in story points), include the size of the story.

Also include any additional notes from the sprint review on relevant decisions.

Finally, consider including a list of actions decided as a result of the sprint retrospective. This is entirely optional and be sure the team is OK including this. They may or may not be, depending on the audience for the sprint summary document.

Keep The Effort Short

Once you’ve produced an initial sprint summary document, you should find creating a new one for each sprint quite simple. My guideline is that it should not take more than 15 minutes per sprint to produce. If you keep the metrics section simple, this is quite feasible.

I’ve included a sample sprint summary document you can use to get started.

What Are You Tracking?

In the comments below, please share your thoughts. What do you think of the things I like to track? What do you track already? Or what will you begin tracking now after reading this?

Systems Engineering and Software Intensive System of Systems

Herding Cats - Glen Alleman - Mon, 04/04/2016 - 23:29

There was a Twitter post mentioning Russell Ackoff YouTube about systems.

A system is never the sum of its parts, it's the product of their interactions.

This is a good start, but it needs to produce actionable outcomes, not just principles, but practices and processes. How do you define, design, represent, assess, analyze, and manage these interactions. The notion that systems are somehow unmanageable is fine in some domains. Finance, social, political. But in technical systems - engineered technical systems - the system has to work when commanded to do so. Much of Ackoff's principles are the basis of practices and processes that assure this happens. 

I come to this systems domain from the Software Intensive System of Systems paradigm. This is where systems are designed, tested, verified, operated, maintained, enhanced, repaired, and replaced with other system. The touchy feely view of systems does not belong here. This is the domain of Systems Engineering, that many times is based on the principles of Ackoff and others like him.

When I hear about complex software systems and how difficult they are, and how undesirable they are, and all the other urban legends about complexity, complex, complicated and chaos, I get a smile. This is the world we work in. And the world where most people are users of those systems. Here's a start in learning how to manage in the presence of these systems.

Ask anyone mentioning complex, complexity, complicated, and chaos if they have a background in Systems Engineering? No, walk away, they don't know what they're talking about.

Related articles The Use, Misuse, and Abuse of Complexity and Complex Technical Performance Measures Agile as a Systems Engineering Paradigm Systems Thinking, System Engineering, and Systems Management Can Enterprise Agile Be Bottom Up? Estimating Guidance Systems Thinking and Capabilities Based Planning What Can Lean Learn From Systems Engineering? Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Design Principles for Software Developers

From the Editor of Methods & Tools - Mon, 04/04/2016 - 16:01
Writing code is easy. Writing good quality code is an entirely different story. How can we measure quality of design? How do we know we’re doing the right set of things that will leads us to a better design? This video presents some core software design principles that help programmers everyday. Instead of talking about […]

A Wrap Up of the #NoEstimating Conjecture Analysis to Date

Herding Cats - Glen Alleman - Mon, 04/04/2016 - 05:26


The conjecture that we can make decisions in the presence of uncertainty without estimating the impacts of those decisions is without any principles that can be tested beyond personal anecdotes of I know people who spend other peoples money without providing estimates

Here's some reading to help understand why its bunk and how to learn to estimate in the presence of uncertainty in order to make better decisions.

This list starts with the earliest posts, beginning in 2009. 

So when you hear about all the posts about #NoEstimates, take a look here to see if those posts provide any actionable outcomes that can be put to the test on actual projects - other than Slicing. 

  1. A Decoder Ring for #NoEstimates - the post that started it all. Answers to questions that really have no basis, other then personal anecdotes
  2. The #NoEstimates Finale - Pat Richard wrote the blog I wanted to. I've had a conversation of sorts with one of the "leaders" of the #NoEstimates movement who talked in circles when asked where is this method applicable outside your examples of a 5 week project and a cleanup of bugs on another project? 
  3. Can We Make a Decision Without Knowing the Cost? - There is an immutable set of questions that need answers before we can determine the probability of success for our project. The NE advocates don't ask or answer these questions.
  4. How to Forecast the Future - In the YouTube presentation from the previous post, titled Predicting the Future, there was a statement made about minute 9:08 where it is stated the only way that you can estimate is if you can look into the future and that requires precognition, which we don't have. For those of us earning our living by looking into the future, this brings a smile.
  5. Predicting the Future - With the #NoEstimates topic still ringing in my ears, here's an interesting presentation from one of the supporters of this concept. It has many good concepts, one serious math error, and connects well with how we manage and work billion dollar programs.
  6. This Does Not Scale - If there are software development projects that can be executed without knowing how much it will cost in the end (an open ended spend plan), or projects where the budget is capped (a Not To Exceed Number) and we don't really need to know the upper bound of the features to be delivered, how large can this notion scale?
  7. How NOT to Estimate Anything - The #NoEstimates discussion now has something to talk about. There is a presentation titled Re-Estimating the Value of Estimating. While there little here that is applicable in our software intensive world, I had a smile when I came to this slide.
  8. What's Gonna Cost and When Will We Be Done? - What's it gonna cost and when will you be done? And oh yea, ...it will work enough to meet my mission success criteria right?
  9. Reference Design Concept - reference class forecast is the key to estimates if you've never done the work before
  10. No More #NoEstimates Discussion - I've made the mistake of engaging the #NoEstimates crowd in questions about the usefulness of their idea. Not a group that likes to get questions, by the way. They use the old Ron Jeffries approach (which has since passed for him) of well just try it to see if it works for you. 
  11. Why Estimating Is Mandatory - The #NoEstimates notion has merit in the right domain. If you're looking for motivation for estimates outside of the domain where the customer doesn't really care about the final cost, just the final product developed inside a "level of effort" budget, look here and remember.
  12. No Estimates Mean Better Estimates? - Value at Risk means how much money and time are you willing to risk without understanding how much time and money is at risk.
  13. Credible Estimating Processes - prediction is difficult, but prediction is the basis of all decision making. We need to learn how to predict with credible methods. And stop accepting the notion that prediction is simply not possible.
  14. Standing on the side of the road and pointing out problems -There a number of people in the Project Management world that seem to take delight in standing on the side of the road pointing out all the failures of projects, processes, and the people managing them.
  15. Planning, Plans, and Execution of the Plan - An interview with Jeff Sutherland and Hank de Velde brings up some important notions in program and project management.
  16. Hume's Advice for Theoretical Business Process Advice - Hume has some advice for the proffers of business or process improvement that fail to provide tangible evidence from the field that suchadvice actually works in a domain interesting to the reader
  17. Estimates and all that... - Esther Derby has a post on estimating. The thread seems to go that estimating is helpful but estimates are not. Let's start with estimating in a domain where we are spending other people's money. Better yet an environment where we are spending the money of a sovereign - the United States of America.
  18. How Many SW Projects Have No Concern About Budget or Schedule? - Rob Schneider posted a comment suggesting the PM 2.0 proponents "are people (that) tend to have experience/careers in industries and on projects where scope is fungible."
  19. Software Estimating - Pawel commented on the previous post about the difficulties in making estimates of duration and cost of software. From an introduction to a seminar conducted by the 309th SMXG in Ogden Utah.
  20. Using Estimates as a Management Tool - For some reason I've been hooked by David Anderson's conjectures about estimating. This has developed over time, mainly because my role on the current project is to aide in the production of a "credible" Integrated Master Schedule (IMS), where estimates of schedule and cost over the life of the program must be made during the proposal. This includes software, hardware, integration and test.
  21. Management is a Control System - With all the discussion about estimating, controlling, and sometimes even managing project it may be useful to have a paradigm of managing anything.
  22. A Fundamental Principle of Writing Software for Money - When there is a sunk cost of any development, be it software, hardware, concrete, a gene-editing anti-virus drug - the value of the resulting product or service is directly related to that sunk cost. 
  23. Reference Class Forecasting for Software Estimating - When it is conjectured You can't do estimates on software projects stop for a second and think about that concept? Really, "you have no idea what so ever about how long this will take and how much it will cost?" I don't want to estimate because I think it is a waste of time is a bit different. That says you're either too lazy to do the estimating, I don't you know how to do the estimating, or you really just want to get going and write software, because that's what you do for a living.
  24. Don't Do Stupid Things On Purpose
  25. Software Estimating Taxonomy
  26. The Problem Using Platitudes For Management Guidance
  27. Alternatives to Agile Estimation
  28. How to get a "D" in the Freshman Finance Class
  29. Why Hasn't #NoEstimates Produced Actionable Outcomes Yet?
  30. Forecasting The Future is Sporty Business, So Knowledge, Skill and Experience is Needed
  31. Want to Forecast the Future? Here's How - Part 2
  32. Critical Thinking Insight
  33. #NoEstimates Makes Contact With Reality
  34. Facts and Fallacies of Estimating Software Cost and Schedule
  35. Can We Make Decisions Without Feedback?
  36. Fooled By Randomness
  37. Coming to the Table with Facts Improves the Conversation
  38. Estimating Accuracy
  39. Nice Estimating Example
  40. Quote of the Day - More Statistics for Decision Making 
  41. How To and How Not To Make Credible Estimates of Cost and Schedule
  42. Books for Cost and Schedule Forecasting
  43. Indicators of project performance provide us with "Steering Inputs"
  44. How To Estimate Almost Any Software Deliverable in 90 Seconds - here's an example to debunk all those posts that say e can't possibly estimate things we don't knwo the details of. This is a Wide Band Delphi process that has been around for 
  45. Estimating Cost, Schedule, and Technical Peformance
  46. What Software Domain Do You Work In?
  47. How To Estimate, If You Really Want To (Updated)
  48. Five Ways To Rethink Software Projects
  49. Quote of the Day
  50. Statistical Process Control The Basis of All Modern Control Systems
  51. Quote of the Day
  52. Black Swans and "They Never Saw It Coming"
  53. Statistics, Bad Statistics, and Damn Lies
  54. Straight Forward, Logical Approaches to Spending Other Peoples Money
  55. Can There Be Successful Projects With Fixed Dates, Fixed Budgets, and Promised Minimal Features?
  56. All Value Production Is Time Phased
  57. All Value Assessments Must Know the Cost
  58. Alert - Was Poor PM the Root Cause of ACA Difficulties?
  59. The Value of Making An Estimate
  60. Processes for Increasing the Probability of Project Success
  61. How To Estimate Almost Anything If You Really Want To
  62. Is fine grained decomposition of work the same as "Not Estimating?"
  63. Managing In The Presence Uncertainty - Redux
  64. Quote of the Day
  65. How Not To Develop What "Done" Looks Like
  66. Elements of Project Success
  67. Resources for Moving Beyond the "Estimating Fallacy"
  68. How to Fib With Statistics
  69. 3 Impediments To Actual Improvement in the Presence of Dysfunction
  70. Three Kinds of Uncertainty About the Estimated Cost and Schedule
  71. It's an Estimating Problem not A Problem with Estimating
  72. Let's Stop Guessing and Learn How to Estimate
  73. Slicing Work Into Small Pieces
  74. Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices
  75. Quote of the Day - Capabilities state the intent of the commander
  76. Quote of the Day - Nice hypothesis you have there, be a shame if some were to test it
  77. Why Software is Like Construction and Why it is Not
  78. If This is How You See Management ...
  79. Some more answers to the estimating questions
  80. Back To The Future
  81. Danger Will Robinson - it's not your money
  82. Answers to Shim's Questions - answer's the Shim's questions about Estimates are Not Estimates
  83. Flaws and Fallacies in Statistical Thinking - all project work is probabilistic based underlying statistical uncertainty
  84. Cost is KING, No Way Out Of It
  85. Quote of the Day - Software intensive project work is indeterminate.
  86. 8 Reasons Why Estimates Are Too Low
  87. To Stay In Business You Need to Know Both Value and Cost
  88. Four Critical Elements of Project Success - each element has statistical behaviors that requires estimates to provide information for decisions
  89. DDSTOP Part Deux - Don't Do Stupid Things on Purpose - Part 2
  90. Project Finance - all project is guided by managerial finance and microeconomics of decision making, whether you know it or not
  91. How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps
  92. Elements of Project Success - project efficiency, impact on customer, business success, preparing for the future
  93. New Books for Work - making multiple decisions, forecasting and simulating software development projects, forecasting methods and applications
  94. Concept of Operations First, then Capabilities, then Requirements
  95. Connecting the Dots Between Principles and Practices of Project Success
  96. We Can Know the Business Value of What We Build?
  97. We're Asking the Wrong Question - does this suggestion (#NoEstimates) increase the probability of project success?
  98. IT Governance and Decision Rights - those spending the money rarely of ever have the right to decide how, unless explicitly given that right by those providing the money
  99. Is There Such a Thing As Making Decisions Without Knowing the Cost? - We can't make a decision without knowing the cost and benefits of the resulting decision
  100. The Calculus of Writing Software for Money, Part II - the microeconomics of decision making in the presence of uncertainty
  101. Why is Statistical Thinking Hard? - in the presence of uncertainty, probability and statistical is needed to make decisions
  102. Operationalism - When we hear about a process, a technique, or a tool, ask in what unit of measure are you assessing the beneficial outcome of applying those?
  103. Quote of the Day - Writing SW For Money Is Micro-Economics
  104. All Project Numbers are Random Numbers ‚ÄĒ Act Accordingly¬†-¬†The numbers that appear in projects ‚ÄĒ¬†cost, schedule, performance ‚ÄĒ¬†are all random variables drawn from an underlying statistical process.
  105. How to "Lie" with Statistics - much of the #NoEstimates argument is built on Bad Management and Bad Mathematics
  106. Why We Must Learn to Estimate
  107. How To Measure Anything - the notion that we can't estimate the future is nonsense, of course we can. To what precision and accuracy that's the question.
  108. Quote of the Day¬†-¬†Probability theory is nothing but common sense reduced to calculation ‚ÄĒ Pierre-Simon Laplace1749-1827)
  109. Making Estimates For Your Project Requires Discipline, Skill, and Experience
  110. An Agile Estimating Story
  111. Response to Consolidating #NoEstimates
  112. Staying on Plan Means Closed Loop Control
  113. More Than Target Needed To Steer Toward Project Success - successful projects need closed loop control, and that means Estimate to Complete and Estimate At Completion 
  114. The Use and Misuse of Little's Law and Central Limit Theorem in Agile - misuse of Little's Law is common in Kanban and Agile
  115. Can Enterprise Agile Be Bottom Up? - YES
  116. How To Make Decisions
  117. Why Project Management is a Control System
  118. How Not To Make Decisions Using Bad Estimates
  119. The Myth of Incremental Development
  120. The Power of Misattributed and Misquoted Quotes
  121. The Failure of Open Loop Thinking
  122. Control Systems - Their Misuse and Abuse
  123. Quote of the Day - Gentlemen, we have run out of money; now we have to think - Winston Churchill
  124. Critical Thinking Skills Needed for Any Change To Be Effective
  125. The Value of Information - Since all variables on all projects are random - cost, schedule, and delivered capabilities, in the economics of projects, the chance of being wrong and the Cost of being wrong is the expected opportunity cost.
  126. How to Estimate Software Development - Update
  127. Estimating Software-Intensive Systems
  128. No Estimates Needs to Come In Contact With Those Providing the Money
  129. Making Choices in the Absence of Information
  130. An Example of Complete Misunderstanding of Project Work
  131. The Cost of Value in the Future
  132. Statistical Significance
  133. Quote of the Day - All Things Project Are Probabilistic
  134. Management is Prediction - W. Edwards Deming
  135. What I Don't Know Can Actually Hurt Me - The notion of not knowing the impact of decisions, choices, approaches is like putting your head in the sand because you don't like the answer or don't what to know the answer.
  136. Complex Project Management - only de minimis project are interesting for #Noestimates approach
  137. Estimating on Agile Projects
  138. Constructing a Credible Estimate
  139. Software Estimating for Non Trivial Projects
  140. Show Me Your Math
  141. When the Solution to Bad Management is a Bad Solution - the core notion of #Noestimates is it is the smell of dysfunction. This is a symptom not a cause. Removing estimates does not fix the cause of Bad Management.
  142. Estimating Guidance - With the plethora of opinions on estimating - some informed, many uninformed - here's my list of books and papers that inform our software estimating activities for Software Intensive Systems.
  143. Quote of the Day - The most unsuccessful three years in the education of cost estimators appears to be fifth-grade artihmetic - Norman R. Augustine
  144. Should I Be Estimating My Work?
  145. Basis of #NoEstimates are 27 Year Old Reports - one of the original advocates of #NoEstimates is basing his argument on a 27 year old report.
  146. Baloney Claims: Pseudo‚Äďscience and the Art of Software Methods¬†
  147. Decision Making Without Estimates?
  148. Intentional Disregard for Good Engineering Practices? - It seems lately there is an intentional disregard of the core principles of business development of software intensive systems.
  149. All The World's A Random Process 
  150. The Actual Science in Management Science¬†-¬†Planning for an uncertain future calls for a shift in information management ‚ÄĒ from single numbers to probability distributions ‚ÄĒ in order to correct the "flaw of averages."
  151. Planning is the Basis of Decision Making in the Presence of Uncertainty
  152. Decision Making in the Presence of Uncertainty
  153. The False Notion of "we haven't seen this before"
  154. Your Project Needs a Budget and Other Things 
  155. Closed Loop Control - Writing software for money is a Closed Loop Control System.
  156. The Myth and Half-Truths of "Myths and Half-Truths" - I love it when there is a post about Myths and Half-Truths, that is itself full of Myths and Half Truths.
  157. Conveniently Unburdened by Evidence
  158. Risk Management is Project Management for Adults - this is a core concept for all project success. Risk management requires estimating probabilities of occurrence, ranges of variance, and probabilities of impact. Take Lister's advice to heart. Not doing Risk Management is managing other people money like a Child would.
  159. Three Increasingly Mature Views of Estimate Making in IT Projects - Update
  160. Estimating Guidance - Updated - some more updates to how to estimate. No reason not to learn how.
  161. Real Life Sources of Empirical Data for Project Estimates - want empirical data, here's where to find it. No eason to claim we've never done this before. Go find the data or  someone who knows the data.
  162. Intellectual Honesty of Managing in the Presence of Uncertainty
  163. Software Engineering is a Verb - I advise my students to listen carefully the moment they decide to take no more mathematics courses. They might be able to hear the sound of closing doors - James Caballero. "Everyone is a Mathematician," CAIP Quarterly 1989. All projects are probabilistic, estimated are needed to manage them. Learn to estimate.
  164. A Theory of Speculation
  165. Here, There Be Dragons - value at risk is a core concept when deciding how much effort is to be applied to estimating outcomes for the future.
  166. Quote of the Day - Ensure good data get to the Bad Decision Makers
  167. What does it mean when we say 80% confidence in a number?
  168. Sources for Reference Class Forecasting - Reference Class Forecasting is a core process by which estimates can be made for work you personally have not dome before. There is NO excuse for not seeking out reference classes other than laziness.
  169. We Suck At Estimating - this is the lamest excuse I've every heard. Here's how to fix that.
  170. Estimating is Risk Management - if Risk Management is how Adults manage projects, then Adult manage projects with estimates.
  171. Planning And Estimating Is Required for Project Success - can't be any clearer.
  172. Bayesian Statistics and Project Work - one of the original NE'ers claimed to be using Bayesian Statistics, Doubt that. Here's how.
  173. Critical Success Factors of IT Forecasting  - quantifying IT forecasting is straight forward, here's how.
  174. Flaw of Averages - there's a misplace notion that averages the number of stories completed in the past will provide a forecast of the future. Start with The Flaw of Averages. Next, the future is rarely like the past. So on both accounts this is a bad idea in the absence of actual statistical analysis of the numbers.
  175. Risk Management is How Adults Manage Projects - another post on behaving like an adult when spending other peoples money.
  176. The Microeconomics of Decision Making in the Presence of Uncertainty - Re-Deux - microecon is the basis of making decisions in the presence of uncertainty. #Noestimates willfully ignores these principles. 
  177. Five Estimating Pathologies and Their Corrective Actions
  178. Managing in Presence of Uncertainty - more managing guidance when spending other peoples money
  179. When Is Delivering Early Not That Much Value? - one of the myths of agile is deliver early deliver often. Without a domain and context, doing this may have no value and may in fact create more trouble for the project.
  180. Quote of the Day - t's not so much about the creativity of the work, it's about emoting on an economically based schedule- Sean Penn talking with John Krakauer. The whole notion of Value is misguided in many agile conversations. Value ot who? What are the units of measure for Value?
  181. Estimating Probabilistic Outcomes? Of Course We Can! - anyone conjecturing you can't estimate a future outcome needs to learn 
  182. Empirical Data Used to Estimate Future Performance Re-Deux - Came across this puzzling tweet today ... real empirical data & using probability to forecast are worlds apart. I don't buy "estimation uses data" argument. If more reason to learn how to do this and learn to call BS on those that don't.
  183. Open Loop Thinking v. Close Loop Thinking
  184. Managing by (mis)quoting Deming
  185. Criteria for a "Good" Estimate
  186. Fibonacci Numbers, Agile, and the Actual Mathematics
  187. Managing in the Presence of Uncertainty - All project work is driven by underlying uncertainty from people, processes, technology, and tools. Let me restate for clarity Certainty is an Illusion, if you're looking for certainty, you're not going to find it in the project domain. You're not going to find it anywhere in the real world.
  188. The Cost Estimating Problem - In probability theory, de Finetti's theorem† explains why exchangeable observations are conditionally independent given some latent variable to which an epistemic probability distribution would then be assigned. It is named in honor of Bruno de Finetti.
  189. Quote of the Day - those suggesting we abandon the principles of Microeconomics of Software Development, it just ain't so
  190. Risk Management is How Adults Manage Projects - again just for reminder
  191. I Think You'll Find It's a Bit More Complicated Than That - When we encounter simple answers to complex problems, we need to not only be skeptical, we need to think twice about the credibility of the person posing the solution.
  192. How We Make Decisions is as Important as What We Decide
  193. Forecasting the Future is Critical to All Success
  194. The Flaw of Empirical Data Used to Make Decisions About the Future - a popular meme Probabilistic forecasting will outperform estimation every time "It is not only not right, it is not even wrong."
  195. Build a Risk Adjusted Project Plan in 6 Steps - if you're going to be an adult about spending other peoples money, time to act like.
  196. Want To Learn How To Estimate? Part Troisième
  197. Doing the Math - In the business of building software intensive systems; estimating, performance forecasting and  management, closed loop control in the presence of uncertainty for all variables is the foundation needed for  increasing the probability of success.
  198. Estimates - Estimation and measurement of project attributes are critical success factors for designing, building, modifying, and operating products and services.
  199. Economics of Software Development
  200. Approximating for Improved Understanding
  201. Debunking¬†-¬†‚ÄúThere‚Äôs nothing more dangerous than an idea ‚Äď or a person ‚Äď that‚Äôs almost right.‚ÄĚ ‚Äď Bono
  202. Qui Bono - Estimates for example are for the business, why would the business no longer what an estimate of cost, schedule, or technical performance of the provided capabilities?
  203. Who Builds a House without Drawings?
  204. The Flaw of Averages and Not Estimating - another Flaw of Averages post. A must read for any hearing #NoEstimates using average past performance.
  205. The Microeconomics of a Project Driven Organization
  206. Capability Maturity Levels and Implications on Software Estimating
  207. Making Decisions in the Presence of Uncertainty - If you're on a project that has certainty, then you're wasting your time estimating. If you are certain things are going to turn out the way you think they are when you have choices to make about the future, then estimating the impact of that choice is a waste of time.
  208. Decision Analysis and Software Project Management
  209. How to Avoid the "Yesterday's Weather" Estimating Problem
  210. Some More Background on Probability, Needed for Estimating
  211. What Happened to our Basic Math Skills? - If the future is not identical to the past, how can we make a decision in the presence of this future uncertainty?
  212. Making Decisions In The Presence of Uncertainty - Decision making is hard. Decision making is easy when we know what to do. When we don't know what to do there are conflicting choices that must be balanced in the presence of uncertainty for each of those choices.
  213. Information Technology Estimating Quality
  214. Climbing Mountains Requires Good Estimates - The quote was Getting better at estimates is like using time to plan the Everest climb instead of climbing smaller mountains for practice. Is another example of clueless NE advocates misusing a paradigm.
  215. Carl Sagan's BS Detector - along with the Debunking posts, BS Detectors are very useful for sorting out all the noise around NE
  216. Myth's Abound - Myths, misinformation, and magic bullets abound in the software development business. No more so than in the management and estimating of complex development projects.
  217. Eyes Wide Shut - A View of No Estimates - When we hear all the difficulties, misuse, abuse, and inabilities for making software development estimates, the real question is what does the business think of this?
  218. Humpty Dumpty and #NoEstimates - is the classic example of how #NoEstimates redefined the term Estimate to fit their needs.
  219. Who's Budget is it Anyway?
  220. The Dysfunctional Approach to Using "5 Whys" - Redux - the original poster of NE seriously misuses the notion of 5 Whys
  221. Essential Reading List for Managing Other People's Money
  222. Monte Carlo Simulation of Project Performance
  223. Just Because You Say Words, It Doesn't Make Then True - some moe debunking of #NoEstimates claims
  224. The Fallacy of the Planning Fallacy - another common misuse of ideas
  225. Let's Stop Guessing and Start Estimating
  226. A Framework for Managing Other Peoples Money
  227. Anecdotes versus Numbers (Statistics) - #NoEstimates is nothing but anecdotes. Show me the numbers
  228.  Why Bother with Probability and Statistics?
  229. One More #NoEstimates Post
  230. Observation Issues and Root Cause Analysis - if you don't have the Root Cause, suggesting #NoEstimates isn';t going to fix anything
  231. Is #NoEstimates a House Built on Sand? - Estimates have little value to those spending the money.
    Estimates are of critical value to those providing the money.
  232. How To Make Decisions - Decisions are about making Trade Offs for the project
  233. Earned Value + Agile a Match Made in Heaven? - Yes
  234. How To Lie With Statistics - is a critically important book to have on your desk if you're involved any decision making
  235. The Flaw of Averages - more cautions from original #NE'ers about using past performance and just averaging the numbers to forecast future performance.
  236. No Signal Means, No Steering Target, Means No Corrective Actions
  237. Flaws and Fallacies of #NoEstimates - The decision maker is asked to express her beliefs by assigning probabilities to certain possible states of the system in the future and the resulting outcomes of those states. This is how it works in the real world of business.
  238. Why Guessing is not Estimating and Estimating is not Guessing
  239. Making Conjectures Without Testable Outcomes
  240. Estimating and Making Decisions in Presence of Uncertainty
  241. Estimating Processes in Support of Economic Analysis
  242. Are Estimates Really The Smell of Dysfunction? - answer NO They're Not. That was a BS conjecture. Go find the Root Cause and fix that. Estimates are just a tool of all business decision making.
  243. What's the Smell of Dysfunction? - a follow up from the nonsense that estimates are the smell of dysfunction
  244. Risk Management is How Adults Manage Projects - another view of Tim Lister's quote
  245. Software Engineering Economics - all decisions are economic decisions. Learn to use economics when spending other peoples money
  246. Deterministic, Probabilistic, and Empiricism - empirical data is the favorite term for #NoEstimates. Doubt they actually know what that means.
  247. The Economics Of Software Development
  248. Slicing Work Into Small Chunks Is Not Without Hazard
  249. The Myth of INVEST and Actual Systems
  250. The Hard Headed Realism of Business Decision Making - it's not your money, act accordingly
  251. The Water Fall Myth - yet another #Noestimates myth busted
  252. Why We Need To Estimate Software Cost and Schedule
  253. SLOC (Source Lines of Code) - this post created a !@#$ storm from those unfamiliar with embedded controls systems and the near 1:1 relationship between SLOC and cost. Threatening to never use a product built with SLOCV estimates. You know airplanes, cars, train controls and the like. It's gonna be a long walk to work.
  254. Bayesian Decision Making - again Bayesian statistics is very useful for estimating.
  255. Decision Support is a Core Business Process
  256. Estimates and Commitment 
  257. Decision Making Means Making Inferences
  258. All The World's a Random Variable
  259. A Core Business Concept - The Investors concern about returns over a limited horizon is a pervasive feature of all business management decision making.
  260. Estimating Software Intensive Systems - Estimation and the measurements that result are critical success factors for Sofware Intensive Systems.
  261. Debunking: The Five Laws of Software Estimating - The Five Laws of Software Estimating contains several Bunk ideas. let's look at each of the Five
  262. Decision Making in the Presence of Uncertainty
  263. Immutable Principles of Managerial Finance When Spending Other Peoples Money - One of the primary responsibilities of  management is to make decisions during the execution of projects so that gains are maximized and losses are minimized. Decision analysis is critical for projects with built-in flexibility, or options. when these choices operate in the presence of uncertainty.
  264. The Twilight Zone Approach to Business Decision Making - When we hear about focusing on value first, delivery early and often, there is rarely any mention of the cost of that delivery.
  265. Risk Management Is How Adults Manage Projects: Agile is Not Risk Management (Alone)
  266. The Unmyths of Estimating
  267. Another Myth Busted - There is a common misinformed conjecture that large programs are managed just like a military operation. Both these concepts are wrong - dead wrong.
  268. Empirical and it's Use in Agile
  269. Produce Shippable Software Every Sprint? Really - There is a popular notion is some circles of Scrum, that Sprints need to produce shippable software at the end of every Sprint. This of course depends as always on the domain.
  270. Drip Funding, Slicing, Decomposing Large Projects Into Small Projects? - A domain is always needed before any suggestion for anything can be assessed to be applicable and useful beyond personal anecdotes.
  271. The Economics of Sofware Quality - To 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. 
  272. Agile at Scale - A Reading List (Update 9) of the Day - Planning is Everything, Plans are Nothing - a reminder that the misuse of quotes is rampant in #Noestimates, from Deming to Eisenhower.
Related articles Four Critical Elements of Project Success Sources for Reference Class Forecasting Software Requirements Are Vague What Informs My Project Management View #NoEstimates episode 2 - THE ANSWERS Let's Stop Guessing and Start Estimating Managing Your Project With Dilbert Advice - Not!
Categories: Project Management

Software Development Conferences Forecast March 2016

From the Editor of Methods & Tools - Tue, 03/29/2016 - 14:41
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 […]

Thu, 01/01/1970 - 01:00