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!

Herding Cats - Glen Alleman
Syndicate content
Performance-Based Project Management¬ģ Principles, Practices, and Processes to Increase Probability of Project Success
Updated: 7 hours 52 min ago

How to Talk About Estimates

Sat, 04/29/2017 - 22:31

What is an estimate?

An estimate as a noun is an approximate calculation or judgment of the value, number, quantity, or extent of something.

An estimate as a verb is to roughly calculate or judge the value, number, quantity, or extent of.

But those estimates, nouns, and verbs themselves's have other attributes. They have precision and accuracy

Screen Shot 2017-04-29 at 3.12.09 PM

We can't talk about estimates or estimate, without also talking about the precision and accuracy of the estimate (the noun) after we have performed the estimate (the verb).

 

The precision and accuracy of the desired estimate and the produced estimate, the noun,  before and after the verb estimate, needs to be determined by those making and those asking for the estimate. 

The best starting point for determining the NEEDED precision and accuracy is to determine the Value at Risk. 

If I'm risking two weeks of work for the Scrum team of 5 people it's a much different need from the risk of a $10B manned spaceflight program being supported to congress for budget authorization. 

This is course is why we develop software for that manned spaceflight program using Scrum, because delivering small pieces of functionality on small grained boundaries greatly reduces the risk of being overbudget and behind schedule, and answers to critical success factor question

How long are we willing to wait before we find out we're late?

Answer 2 weeks. Every two weeks there is a mid-month flash report sent to NASA. Every month there is a Month End reports, both showing cumulative cost to date, cumulative schedule performance, and Physical Percent Complete.

Estimating and the resulting Estimates must be described by their accuracy and precision. If you hear any other description, like estimates can't be precise, or estimates are never accurate, those words are mathematically incorrect.

Point estimates without variance (accuracy and precision) are never right

Don't fall into the trap that estimates are wrong, estimates are not precise, precise estimates are a waste or any other malarkey about estimates that don't include the measures of precision and accuracy. 

Finally, the accuracy and precision themselves have accuracy and precision. This is the error on the error - the confidence in the error - that is needed.

To learn more about estimating on Agile programs read Chapter 5 of the bibliography below. There you'll also find materials on risk management, capabilities-based planning, and other agile processes as they are applied to Software Intensive System of System for mission critical programs where we work.

Screen Shot 2017-04-29 at 3.26.44 PM

Related articles Let's Stop Guessing and Start Estimating Why Guessing is not Estimating and Estimating is not Guessing Estimates IT Risk Management
Categories: Project Management

The Premises of Rational Management

Thu, 04/27/2017 - 14:58

Organizational Effectiveness is a basis of rational management.

The organization is one of mankind's all-time greatest inventions. An organization is intended to operate as one unit, with all its parts in efficient coordination. But all too often it does not. The parts operate as disparate levels of efficiency, or they overlap, or they work against others interests. There is misunderstanding and miscomunictaion. Things get done, progess is made. But not enough of the right things get done or as well as they should. Progress, however it is defined, does not meet expectations.

from The Rational Manager, Charles Kepner and Benjamin Tregoe, 1965

When we hear about dysfunction and things that are the smell of that dysfunction and have not identified the root cause of that smell, we are simply treating the symptom. Whatever suggested solution there is has no hope of ever fixing the problem, it's simply a placebo at best and a diversion a worst.

Picture1

This book in its original form and the updated version in 1997 provides the foundation for decision analysis in the presence of uncertainty. Decision making and the analysis that accompanies it are the basis of success for business and those providing the solutions the enable the success of business.

Any suggestion that decisions can be made in the presence of uncertainty without estimating the outcomes of those decisions on the probability of success of the business as no basis in principle or practice of business management. Such suggestions are logically fallacious.

Related articles Making Conjectures Without Testable Outcomes Essential Reading List for Managing Other People's Money Making Decisions In The Presence of Uncertainty
Categories: Project Management

Quote of the Day

Wed, 04/26/2017 - 06:18

Reality is that which when you stop believing in it, doesn’t go away - Philip K. Dick

Categories: Project Management

Bad Management Behaviours

Sun, 04/23/2017 - 23:19

 I belong to an invitation blog for military people. In a recent post, they had a post from the York Region District School Board D'Youville College, Aleksandr Noudelman about leadership.

This post resonanted with me when I hear about simple and simple minded soultions to symptoms that involve bad management. Of course these solutions don't address the Root Cause, so they never get fixed 

Here are seven key behaviors that can be found a weak leader:

  1. Their team routinely suffers from burnout ‚Äď Being driven and ambitious are important traits for successful leaders. However, if you are excessively working your people or churning through staff then you aren‚Äôt effectively using your resources. You may take pride in your productivity, in doing more with less. However, today‚Äôs success may undermine long-term health. Crisis management can become a way of life that reduces morale and drives away or diminishes the effectiveness of dedicated people. With any business, there are times when you have to burn the midnight oil but it should be accompanied with time for your team to recharge and refuel.
  2. They lack emotional intelligence ‚Äď Leaders who are weak are always envious of other peoples' successes and are happy when other people fail. They see themselves in fundamental competition with other executives and even with their subordinates. Such envy is a root cause of the turf wars, backbiting, and dirty politics that can make any workplace an unhealthy one.
  3. They don‚Äôt provide adequate direction ‚Äď Failing to provide adequate direction can frustrate employees and will hinder their chances at completing tasks correctly and success. Poor leaders might not tell employees when a project is due or might suddenly move the deadline up without regards for the employee who's doing it. Project details can also be vague, making it difficult for staff to guess what factors the leader considers important. If a project involves participation from more than one employee, a poor leader may choose not explain who is responsible for what part. Good leaders provide adequate direction and are always there to provide descriptive feedback when it is needed.
  4. They find blame in everyone but themselves ‚Äď Weak leaders blame everyone else for their mistakes and for any mishaps that happen to them and their division/company. Every time they suffer a defeat or a setback, a subordinate is given the talk down, or worse, an ax. Great leaders don't do this and they always stay positive no matter what the circumstances are. They are accountable for the results and accept full responsibility for the outcomes.
  5. They don‚Äôt provide honest feedback ‚Äď It is very difficult for weak leaders to give the honest messages or constructive feedback to their subordinates. When they have to say something negative to someone, it's always someone else, usually a superior, who has told them to do. By that time it is too late and the leader hasn't really identified the problem before it reached the climax. They also make it a point to let the individual know that it's not their idea. Good leaders speak from the heart and provide honest feedback that is backed up by facts. They never wait for superiors to identify problems for them.
  6. They're Blind To Current Situation ‚Äď Because weak leaders are egocentric and believe that their way is the only way, their followers are afraid to suggest anything new. Those who follow such leaders only give them praise or the good news. Such appreciation only gives a boost to their status and ego and the leader is left clueless as to what the current situation is as well as the changing trends in the marketplace.
  7. They're Self-Serving ‚Äď If a leader doesn't understand the concept of ‚Äúservice above self‚ÄĚ they will not retain the trust, confidence, and loyalty of their subordinates. Any leader is only as good as their team‚Äôs hope to be led by them. Too much ego, pride, and arrogance are not signs of good leadership. Long story short; if a leader receives a vote of non-confidence from their subordinates‚Ķthe leader is a weak one.

The leaders mentioned in the orginal post are military leaders. But the same behaviours can be found in our commercial leaders. 

Related articles Root Cause Analysis Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

#NoEstimates Book - Chapter 1 Summation

Fri, 04/14/2017 - 06:11

I posted some comments on the #NoEstimates book awhile back.  I have a break this week and would like to sum up Chapter 1.

Chapter 1 Introduction

  • Why estimates don't work - Carmen is assigned a project that will make or break the company. Carmen has never managed a project this size.
    • This is a¬†classic example used in the book of making seriously bad management decisions.¬†
    • Why would the manager assign Carmen that project?

Then comes one of three quotes that are the basis of the argument for NOT estimating. The most egregious is Hofstadter's Law, which says It always takes longer than you expect, even when you take into account Hofstadter's Law

This quote is misused to suggest that estimating can't be done. On page 152 of Gödel, Escher, Bach: an Eternal Golden Braid, Hofstadter explains the context and meaning of Hofstadter's Law.

Hofstadter is speaking about the development of a Chess playing program - and doing so from the perspective of 1978 style software development. The game playing programs use a look-ahead tree with branches of the moves and countermoves. The art of the program is to avoid exploring every branch of the look-ahead tree down to the terminal nodes. In chess - actual chess, people - not the computer - have the skill to know what branches to look down and what branches to not look down. 

In the early days (before 1978) people used to estimate that it would be ten years until the computer was a world champion, But after ten years (1988) it was still estimated that day was still ten years away. 

This notion is part of the recursive Hofstadter's Law which is what the whole book is about. The principle of Recursion and Unpredictability is described at the bottom of page 152. 

For a set to be recursively enumerable (the condition to traverse the look ahead tree for all position moves), means it can be generated from a set of starting points (axioms), by the repeated application of rules of inference. Thus, the set grows and grows, each new element being compounded somehow out of previous elements, in a sort of mathematical snowball. But this is the essence of recursion - something being defined in terms of simpler versions of itself, instead of explicitly. 

Recursive enumeration is a process in which new things emerge from old things by fixed rules. There seem to be many surprises in such processes ...

So if you work on the development of recursive enumeration based software designs, then yes - estimating when you'll have your program working is likely going to be hard. Or if you work on the development of software that has no stated Capabilities, no Product Roadmap, no Release Plan, no Product Owner or Customer that may have even the slightest notion of what Done Looks like in units of measure meaningful to the decision makers, then probably you can apply Hofstadter's Law. Yordan calls this type of project A Death March Project - good luck with that.

If not, then DO NOT fall prey to the misuse of Hofstadter's Law by those likely to not have actually read Hofstadter's book, nor have the skills and experience to understand the processes needed to produce credible estimates.

So Why Is It Important to call out something like the misuse of a quote? Simple, if you can't get the simple understanding of what someone said, how they meant, and in what context they said it, how can you have a coherent message for the message you're trying to convey? Several other "agile" books do the say they. This is why Agile! The Good, the Hype, and the Ugly is a mandatory read 

Some More nonsense quotes Out of Context or Without ANY Context and Bad Management Being Done on Purpose

This Chapter contains many bogus quotes, examples of Doing Stupid Things on Purpose, here are a few examples:

  • A Late Change in Requirements is a Competitive Advantage - is only true if that change enhances the value of the product and the cost of that change does not impact the ROI of the product
  • 80,000 lines of code won't fit on a 20-page contract - never seen a contract to stated how many lines of code. A simple letter contract for the development of an IT Ticketing systems can be stated in 5 pages of less. Yet another example of stating nonsense with no context.
  • Figure 4 shows the inability of the team and management to actually flow the principles of Scrum. This is a picture of a bad scrum team. they need an intervention from a Scrum coach to get them back to actually providing value to their customer

Chapter 1 Ends With the #NoEstimates Argument But Ignores the Uncertainties of all Project Work

If it is so hard to estimate software work, can you predict when a particular project will end? Yes, you can. And that is the right question. Instead of asking how long the project will take, ask instead: ‚Äúgiven the rate of progress so far, and the amount of work still left, when will the project end?‚ÄĚ Or, a similar question: ‚ÄúGiven the rate of progress, how much of the work can be finalized by date X?‚ÄĚ

This is possibly the case IIF (If and Only  If):

  • All the work is of equal effort
  • All the work is of equal duration
  • All the workers have consistent productivity over the life of the work
  • There are no aleatory uncertainties in any of the processes
  • There are no epistemic uncertainties in any process, people, or tools

In other words, the work is non-variable, equal size and effort, and the developers work at an unchanging rate, and the arrival of the work is constant. This the definition of a Machine Based process. Not likely ever to be true.

So at the end of Chapter 1, No estimates is based on a set of conditions that are NEVER present on actual project

Intro the Chapter 2

Chapter 2 starts with a scene of sending poor Carmen on a Death March. 

  • This was not Carmen‚Äôs first project, but until now she had managed to give fair estimates on her projects because they were small and somehow similar.
  • But this was a different kind of beast. New technologies, new client, new domain, new product.

So does Carmen have any reference classes for making estimates of the new project? How about some models with scaling parameters? How about an understanding of the uncertainties involved in the project? The reducible uncertainties (Epistemic) the irreducible uncertainties (Aleatory) both of which create Risk for the success of the projects. Does Carmen have a Product Roadmap where these uncertainties can be assessed? Does Carmine have a Product Owner, an Agile estimating process? A Release Plan?

Does Carmen have anything she needs for success? Sounds like she's being tossed to the Wolf's in pursuit of a predefined conjecture that estimates can not work. This is the style of writing here. If this is appealing to you - make up a bad situation, where the protagonist is sacrificed to the Gods of Bad Management, then the solution is just as incredible, then keep reading. I'll take a break before Chapter 2 for all these contrived plot twists based on contrived examples of Bad Management. 

Related articles Systems Thinking, System Engineering, and Systems Management Humpty Dumpty and #NoEstimates Why Guessing is not Estimating and Estimating is not Guessing Why We Need Governance The Microeconomics of Decision Making in the Presence of Uncertainty Agile Software Development in the DOD Economics of Software Development Two Books in the Spectrum of Software Development
Categories: Project Management

The Bad Apple Syndrome in Process Improvement

Thu, 04/13/2017 - 19:54

When process improvement starts with the solution, it's common to anchor this improvement on the Bad Apple syndrome. The Dilbert Manager, the bad apple on the team, and another example of starting with the symptom and skipping to the solution, bypassing the root cause.

When this happens, those selling the solution need to defend the solution in the presence of hard questions:

  • Will your solution actually¬†correct my problem?
  • Will your solution actually prevent the problem from coming back?
  • What is the reason for that? Have you made a¬†cause and effect assessment of the problem to the solution, to the sustainment of that solution?

This, of course, is the basis of Root Cause Analysis.

Screen Shot 2017-04-12 at 8.00.34 AM

ISO/IEC 17025:2005 (4.11.2) ‚Äí The procedure for corrective action shall start with an investigation to determine the root cause(s) of the problem.

Here's a simple perspective for problem-solving

  • Every problem in our lives, personal, business, civic, technical¬†has three basic elements connected through causality
  • Each effect has to two causes
    • An Action
    • A Condition

Screen Shot 2017-04-12 at 8.04.49 AM

Before looking further, here's a principle that has served us well. 

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?

- from The Apollo Method, orginall from 

This Action and Condition are critical to finding the solution. The classic misuse of the Five Whys of the root cause is the conjecture.

So when you hear a story about some undesired outcome - labeled as a dysfunction - and then here a quick and dirty solution to that dysfunction ask if there has been a Root Cause Analysis of the situation?

No? Then it's likely the person making the suggestion is trying to sell you something. A conference, a book, a consulting gig. Especially if that person's suggestion violates several of the principles of business and technical management.

And we're all selling all the time, but in our Federal Acquisition Regulation environment and other contract domain, there is a Past Performance Volume with a formal evaluation. So when a suggestion is made to a client (of ours) that Past Performance section must state what we did, what was the outcome, and what are the tangible benefits of that outcome to the decision maker. Always ask for those pieces of information before spending any more on anything.

Long ago a very senior piping engineer on a multi-billion refinery piping design system, asked us software weenies 

That a nice idea boys (there were no females working there) what have you done for me lately

One of the engineers for the product we were using (Evans and Sutherland Picture System) went on to found Adobe. He asked if we wanted to join the startup. Na, I don't want to move from Southern California (Irvine) to Northern California. They had written a driver for a CalComp bed plotter to plot our 3D piping diagrams (ISOs) and were getting ready to approach laser printer manufacturers. That protocol was called PostScript.

Related articles Estimating and Making Decisions in Presence of Uncertainty Are Estimates Really The Smell of Dysfunction? Myth's Abound Herding Cats: Where is the Adult Supervision on this Program?
Categories: Project Management

Planning is King

Thu, 04/13/2017 - 16:58

There has been lots of buzz in the project management space lately about the benefits of planning. Planning is one of the Five Immutable Principles of project success. Planning tells us, in units of measure meaningful to the decision makers, what Done looks like.

No Plan? You can't know what Done looks like, until time and money runs out.

Screen Shot 2017-04-13 at 9.50.45 AM

Plans are strategies for success. Strategies are hypotheses. Hypotheses needed tests to verify their correctness. Tests are working products, models, feedback - some tangible evidence that the work produces the desired outcomes.

And as always, planning and the resulting plans are estimates of the desired outcomes and the path to get there. With these estimates, the steps needed to reach the desired outcomes can be assessed to make corrective actions.

Related articles Mr. Franklin's Advice Capabilities Based Planning Carl Sagan's BS Detector Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Debunking
Categories: Project Management

Some Dark Sides to Agile

Wed, 04/12/2017 - 23:16

I work agile programs that are subject to FAR 34.2 and DFARS 234.2 These are Software Intensive System of Systems, starting at $20M in some domains and $5M in others and going much larger. Many are household names in space and defense business. These programs integrate Earned Value Management with Agile software development to great advantage.

But there are some Dark Sides to agile in this domain and context.

Screen Shot 2017-04-12 at 11.32.21 AM

Like all processes and tools that support them, there is a Dark Side.

Here are some Dark Sides to the integration of Agile and EVM.

  • One of the principles of Agile is the encouragement of Late Changes. This allows the project to adapt to emerging needs. But someone has to pay for this non-recoverable sunk cost that results from the changes that don‚Äôt appear in production.
  • These changes may also impact the PMB, and drive changes to the baseline. The accounting processes will be burdened as well, with BCRs.
  • In the EVM world, CPI can forecast cost overruns. In Agile the cost spreads are fixed by the flat staffing profile during the sprints. Unfavorable CV is not possible. Undelivered functionality is.
  • SV is problematic in normal EVM. What does it mean to be $250K unfavorable to schedule (SV) unless you know the burn rate?

Screen Shot 2017-04-12 at 11.35.19 AM

There is no field in the IPMR for Story Points or Stories. The WBS at the Control Account and Work Package level is assigned Dollars. Performance is measured by Physical Percent Complete against BCWS ‚Äď in dollars.

Related articles Deadlines Always Matter Thinking, Talking, Doing on the Road to Improvement The Art of Systems Architecting The Fallacy of the Planning Fallacy Just Because You Say Words, It Doesn't Make Then True Herding Cats: Velocity versus Speed There is No Such Thing as Free Who's Budget is it Anyway?
Categories: Project Management

Book of the Month

Mon, 04/10/2017 - 16:41

Short Term ForecastingI've been working in the probabilistic estimating business for a decade or two. 

One of the seminal books that started it all is Short-Term Forecasting. This is the basis of Box-Jenkins and Mr. Jenkins quote that is universally misquoted by most people in the Agile community.

All Models are Wrong, Some Models are  Useful

As well - of course - is the nonsense that Forecasts are not estimates, popularized by #NoEstimates advocates.

The Box-Jenkins modeling process expands to the ARIMA (Auto-Regression Integrated Moving Average) models we use for cost and schedule models. This approach makes use of past performance to forecast future outcomes. This empirical method is used nearly universally for forecast time series in the past for outcomes in the future. From stock markets to Estimates to Complete and Estimates at Completion. In our domain, we archive all the performance numbers and then compare them against the planned performance models. This is then used to make adjustments to the Plan or the Estimate from the Root Cause of the variance.

This is called Close Loop Control, and that works on all domains where stochastic process underly the work process, from software development, to process control, to flight control systems, the natural systems.

Related articles The Flaw of Empirical Data Used to Make Decisions About the Future Do The Math Humpty Dumpty and #NoEstimates The Flaw of Averages and Not Estimating Herding Cats: Median, Mean, Mode without Variance is Worthless Doing the Math 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

Book of the Month

Mon, 04/10/2017 - 16:41

Short Term ForecastingI've been working in the probabilistic estimating business for a decade or two. 

One of the seminal books that started it all is Short-Term Forecasting. This is the basis of Box-Jenkins and Mr. Jenkins quote that is universally misquoted by most people in the Agile community.

All Models are Wrong, Some Models are  Useful

As well - of course - is the nonsense that Forecasts are not estimates, popularized by #NoEstimates advocates.

The Box-Jenkins modeling process expands to the ARIMA (Auto-Regression Integrated Moving Average) models we use for cost and schedule models. This approach makes use of past performance to forecast future outcomes. This empirical method is used nearly universally for forecast time series in the past for outcomes in the future. From stock markets to Estimates to Complete and Estimates at Completion. In our domain, we archive all the performance numbers and then compare them against the planned performance models. This is then used to make adjustments to the Plan or the Estimate from the Root Cause of the variance.

This is called Close Loop Control, and that works on all domains where stochastic process underly the work process, from software development, to process control, to flight control systems, the natural systems.

Related articles The Flaw of Empirical Data Used to Make Decisions About the Future Do The Math Humpty Dumpty and #NoEstimates The Flaw of Averages and Not Estimating Herding Cats: Median, Mean, Mode without Variance is Worthless Doing the Math 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

Median, Mean, Mode without Variance is Worthless

Sun, 04/09/2017 - 16:54

Just had a conversation of sorts where it was stated, I look at the median EQF of a portfolio as one gauge of the quality of the overall underlying data. The problem is without the variances of any single point metric, that metric is pretty much worthless.

Here's a little exercise we use at conferences and training sessions.

  • I'm going to send you on a mission to determine the Mode of a measurement. You'll get a clipboard, a hat, a folding chair, and a few other items. You'll go to two locations for 365 days and record the high temperature of the day.¬†
  • Let's start with Trinidad-Tobago. You've got your clipboard, a nice folding chair sitting on the beach, a good sun hat and sunscreen.¬†
  • Next, you'll go to Cody Wyoming, just north of my home and do the same thing

Now let's look at the Mode of those numbers. Why the Mode. It's the most recurring value in a time series. This is what we use when modeling - Estimating - variables in project planning. The Mode of a Task's work duration is the Most Likely value drawn from a sample of possible values in the Probability Distribution Function. It is the value that occurs most often in the Task's life. If we have a similar Task - through a Reference Class Forecasting process, we want to use the Mode of the duration. Not the Mean (average) or the Median (the middle most). The Mode is what the Task will take most of the time.

So now let's look at the data.

  • For Trinidad-Tobago, the number that occurs¬†most often across the 365 days of sitting in your chair writing down numbers is 84¬į F
  • In Cody Wyoming, the number that occurs¬†most often in the 365 days is - wait for it - 84¬įF

Now, these are the Mode numbers. The Most Likely To Occur. For temperatures, this is a bit of a stretch because temperatures are driven by a periodic cycle of seasons and weather.

But for task durations, this is a legitimate starting point for estimating. What is the most likley duration for this work? Without the variance on the Mode or the Mean, the Median is the middlemost number, there can be no confidence you wouldn't freeze to death in February if you go to Wyoming in your shorts and teeshirt

Related articles How to Avoid the "Yesterday's Weather" Estimating Problem Want To Learn How To Estimate? Capabilities Based Planning
Categories: Project Management

Median, Mean, Mode without Variance is Worthless

Sun, 04/09/2017 - 16:54

Just had a conversation of sorts where it was stated, I look at the median EQF of a portfolio as one gauge of the quality of the overall underlying data. The problem is without the variances of any single point metric, that metric is pretty much worthless.

Here's a little exercise we use at conferences and training sessions.

  • I'm going to send you on a mission to determine the Mode of a measurement. You'll get a clipboard, a hat, a folding chair, and a few other items. You'll go to two locations for 365 days and record the high temperature of the day.¬†
  • Let's start with Trinidad-Tobago. You've got your clipboard, a nice folding chair sitting on the beach, a good sun hat and sunscreen.¬†
  • Next, you'll go to Cody Wyoming, just north of my home and do the same thing

Now let's look at the Mode of those numbers. Why the Mode. It's the most recurring value in a time series. This is what we use when modeling - Estimating - variables in project planning. The Mode of a Task's work duration is the Most Likely value drawn from a sample of possible values in the Probability Distribution Function. It is the value that occurs most often in the Task's life. If we have a similar Task - through a Reference Class Forecasting process, we want to use the Mode of the duration. Not the Mean (average) or the Median (the middle most). The Mode is what the Task will take most of the time.

So now let's look at the data.

  • For Trinidad-Tobago, the number that occurs¬†most often across the 365 days of sitting in your chair writing down numbers is 84¬į F
  • In Cody Wyoming, the number that occurs¬†most often in the 365 days is - wait for it - 84¬įF

Now, these are the Mode numbers. The Most Likely To Occur. For temperatures, this is a bit of a stretch because temperatures are driven by a periodic cycle of seasons and weather.

But for task durations, this is a legitimate starting point for estimating. What is the most likley duration for this work? Without the variance on the Mode or the Mean, the Median is the middlemost number, there can be no confidence you wouldn't freeze to death in February if you go to Wyoming in your shorts and teeshirt

Related articles How to Avoid the "Yesterday's Weather" Estimating Problem Want To Learn How To Estimate? Capabilities Based Planning
Categories: Project Management

Same Same but Different †

Sun, 04/09/2017 - 16:47

Much of the conversation in social media around agile techniques seems to be based on the differences between the variety of choices of a  method, a process, or a practice and definitions of terms for those choices. There seems little in the way of shared principles, when in fact, there is a great deal of sharing of principles.

I work in a domain where systems are engineered for the customer. These systems fall into the Software Intensive System of Systems (SISoS) category. In this domain innovation is the basis of success. The notion that innovation and engineering - software engineering - are somehow in conflict is common. 

... creativity is simply the production of novel, approprioate ideas, from science, to the arts, to education, to business, to everyday life. The ideas must be movel - different from what's been done before - but they can't be simpmply bizarre; they must be appropriate to the problem or opportuntiy presented. Creativity is the first step in innovation, which is the successful implementaion of those novel, approproate ideas. And innovation, is absolutley vital for long-term corporate success - "Motivating creativity in organmizations: On doing whay you love and loving what you do," [2]

In many conversations about managing in the presence of uncertainty - which is the ubiquitous condition for all non-trivial software development projects - the notion that principles, processes, and practices of Engineered Systems appear to be the antithesis of Agile software development in some quarters. 

Both agile advocates and engineered systems advocates practice innovation and creativity. Both fields are supported by a history of creating innovations - and in fact, collaborate on many of the programs I work. In the software engineering domain, like the developer domain, design is the basis of innovation. Design from a generalized perspective is purposeful ...

... thinking, problem-solving, drawing, talking, consulting and responding to a range of practical and aesthetic constraints to create - ideally - the most appropriate solution(s) under the given circumstances. - [3]

So why is there a great divide between the traditional engineered software-intensive system of systems and the current agile development paradigm that appears to reject the basic principles of developing value-based products from capital investments, using the core principles of managerial finance and microeconomics of decision making in the presence of uncertainty rejected by many in the agile development community? 

Why does the engineered system paradigm reject many of the practices of the agile community as undisciplined, ad hoc with little or no basis in the principles of management? 

Let's start with five core organizational principles of agile...

  1. Regular delivery of incremental business value - defined in a Product Roadmap, scheduled in a Cadence or Capability release plan.
  2. Iterative development focused on the delivery of Features that enable the needed Capabilities that fulfill the business case or accomplish the mission of the software system.
  3. Responding to changing requirements and priorities to assure continuous release of products needed to enable the needed Capabilities to be fulfilled.
  4. Engaging in multiple levels of planning with detailed planning occurring at the Sprint level to produce working software for needed Capabilities produced as planned in the Product Roadmap.
  5. Open and regular collaboration across teams and stakeholder to assure a shared vision of the desired project outcome.

The engineered SISoS domain has the same paradigm in principle because these principles and five implementation principles are Immutable. The five implementation principles are...

  1. What does done look like described in units of measure meaningful to the decision makers?
  2. What is the plan to reach done for the cost and delivery date to produce the needed value to those paying for the work?
  3. What resources are needed to provide the needed capabilities to fulfill the business case or accomplish the mission?
  4. What impediments will be encountered along the way to Done and what handling activities will be applied to remove or reduce these impediments?
  5. How will progress to plan be measured so the decision makers will have confidence their investment will be returned as planned?

So what's the disconnect we hear between Agile and Traditional systems development? 

The first is the principles listed above are not established first before idea exchange starts. So when there is a gap in the semantics of a conversation, there is no touchstone to go back to. Without this shared understanding of the principles, the conversation becomes self-centered (an echo chamber) and any possible exchange in pursuit of learning is lost.

Second is there is no shared domain as the basis for applying those principles. I work in the SW Intensive System of Systems world. Others work in website development, others work in internal IT shops. While the principles of developing software for money are likely to be the same, the processes and practices can be dramatically different. What is a good practice for our spaceflight avionics system development, is probably of little use to a web developer. And vice versa.

Until we come to agree that the principles are a starting point, and then put a shared domain on top of those, it will be an argument without end.

Same Same but Different

† "Same Same but Different" is a phrase used a lot in Thailand, especially in an attempts to sell something but can mean just about anything depending on what the user is trying to achieve.

[1] Same Same but Different Perspectives on Creativity Workshops by Design and Business," Alexander Brem and Henrik Spoedt, IEEE Engineering Management Review, Vol. 4, No. 1, First Quarter, March 2017, pp. 27-31

[2] "Motivating Creativity in Organizations: On Doing what you Love and Loving What You Do," T. M. Amabile, California Management Review, 40, pp. 39-58, 1997.

[3] The Design History Reader,  Grace Lees-Maffei (Editor), Rebecca Houze (Editor), Bloomsbury Academic, April 15, 2010.

Related articles The Customer Bought a Capability The Reason We Plan, Schedule, Measure, and Correct Who Builds a House without Drawings? Two Books in the Spectrum of Software Development Complex, Complexity, Complicated
Categories: Project Management

Quote of the Day

Sat, 04/08/2017 - 16:21

‚ÄúIf a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related‚ÄĚ ‚Äď Martin Shub

When there are practices suggested without principles, those practices have no way of being tested for applicability to the problem at hand. So when you hear We have a way to fix some problem, ask by what principles can you suggest your solution with fix the problem? And of course, ask have you found the root cause of the problem or are you just treating the symptom?

Categories: Project Management

Quote of the Day

Sat, 04/08/2017 - 16:21

‚ÄúIf a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related‚ÄĚ ‚Äď Martin Shub

When there are practices suggested without principles, those practices have no way of being tested for applicability to the problem at hand. So when you hear We have a way to fix some problem, ask by what principles can you suggest your solution with fix the problem? And of course, ask have you found the root cause of the problem or are you just treating the symptom?

Categories: Project Management

Velocity versus Speed (Update)

Sat, 04/08/2017 - 15:17

Velocity is a speed in a specific direction. Velocity is Distance traveled divided by time in a specific direction. This is defined as a Vector. Speed and Direction. 

Velocity

The direction can be a compass heading. A compass heading of an aircraft - 270¬į. The aircraft can have a 2nd dimension of measure - the compass heading and climbing or descending¬†at a¬†measure of feet per minute.

CompassImage005
Speed is Distance traveled over Time. When we are driving we have a speedometer. It says 55 Miles Per Hour. OK, I rarely drive 55 MPH but pretend I was. In one hour (time) I will cover 55 miles. This measure doesn't include the direction. We're driving on the road for the most part, so the direction is predetermined. With speed, we're measuring the distance over that road over time, no matter what the shape of the road is - straight or curved, flat or mountainous. 

Velocity in Agile Software Development

Velocity is a term used in agile development. In agile, A velocity is an arbitrary unit of measure, calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project. The velocity is calculated by counting the number of units of work (Stories or Story Points or any other arbitrary measure) completed in an interval of time (a Sprint), the length of which is determined at the start of the project (some small number of weeks).

These units can be Story Points, Stories, kumquats, or Corgi dogs, and the interval can be a Sprint of 2 or 3 weeks or any other unit. Usually, they are Story Points or Stories, but this is arbitrary. 

So 30 Story Points over 2 weeks means 15 Story Points per week - on average - or 5 Story Points per day - on average. This is the average Speed, the instantaneous speed is different, just like the instantaneous speed changes many times a minute. The speed in the agile example is the number of Story Points and the direction is toward the end - direction. But that end we need a  unit of measure as well. The Stories and Tasks from the Product Backlog is a direction. Those Stories are definitized from Features in the Prodict Roadmap and Release Plan. That's how we get direction in agile for Velocity.

Velocity = Speed in a Direction. Velocity is a Vector. Speed is a Scalar

Does Velocity effect Cycle Time? 

Cycle time is the total time from the beginning to the end of a work process. Cycle time includes process time, where the object under work is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action. For software development, the object is the Story and the development of the Code that implements the Story along with the testing and all the other activities of producing the outcome from the work effort.

If we think of cycle time as the time the Story spends being developed (including all the work to produce working software), over some period of time inside the Sprint, including the entire Sprint. Then we can say...

The cycle time for a Story is the total time from beginning to end for the production of Working Software. Howe long were we working on the Story. This is a unit used in Little's Law as well. The direction this Story is going is toward the end of the Sprint. So the Story has a Velocity. But since the direction is fixed - toward the last day of the Sprint, the passage of time from start to end of the development effort, is it's Seed.

So here's the Question

Does Velocity impact Cycle Time? Answer? YES It Does

Why? Cycle Time and Velocity - when there is a fixed direction (the Sprint) over a fixed duration (2 or 3 weeks where we work) affect the total amount of time the Story is being worked (as we say in our defense software development domain). This time being worked is the Cycle Time for that Story. How fast the work is being done (Speed, as in Velocity with a fixed direction) will impact how long the Story is being worked.

The faster we go the faster the Story will be completed. 

So yes,

Velocity does impact the Cycle Time. It impacts that Cycle Time directly. Go fast, finish fast. Finish fast, lower Cycyle Time

After talking this over this morning with a colleague who is responsible for many of the aspects of Agile development in manned and unmanned space flight systems where I work, here's a summary of the notion of Velocity from her point of view - which like mine is from Physics and Math

Screen Shot 2017-04-07 at 3.13.33 PM

  • Speed is the rate of the production of Story Points by the team over some time - the Sprint
  • The direction is the Product Roadmap -¬†where are we going. The Stories and the Features they implement need to have some reason for being there.

So velocity and throughput are directly related. The faster outcomes appear the larger the throughput, measured in a fixed block of time. Since Story Points are a relative (Ordinal) unit of measure expressing an estimate of the effort required to fully implement a product backlog item or any other piece of work, we can assign Story Points to the rate of movement - 20 story points per sprint. This can also be referred to as the capacity for work. Our team can deliver 20 Story Points per Sprint. 

And of course each of these variables are random variable impacted by uncertainty, so estimates are needed in the presence of this uncertainty to determine if we are going be delivering what we said we were going to deliver when the Sprint started.

Lastly, when we hear Story Points are not hours, that is also incorrect. We can assign the arbitrary unit of measure - the Story Point - to any Cardinal measure. One program I work assigns ONE Story Point to be 6 hours (an Ideal Day). This is purely arbitrary of course, but once we've exited Story Time where we use Story Points to prioritize the Story, they are converted into Ideal Days to confirm our capacity for work matches the calendar period of performance for that work. 

By the Way

There a poster on a cubical wall across from my cubical that says ...

Aardvark

Why is this important? The staff on that side of the passage are contract managers for a Manned Space Flight Vehicle. They are always arguing about the meaning of Affect and Effect and how contractually binding the words they are arguing about, usually some piece of hardware that was built or procured and how that piece of hardware is integrated into a larger piece of hardware - last week the connectivity bolts that attached the spacecraft to the adapter ring on top of the launch vehicle and how it's behaviour will AFFECT the performance of the system after the EFFECT of an explosive separation, which by the way must work 100% of the time or people die.

 

 

Related articles Estimates Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Same Same but Different †

Sat, 04/08/2017 - 00:19

Much of the conversation in social media around agile techniques seems to be based on the differences between the variety of choices of a  method, a process, or a practice and definitions of terms for those choices. There seems little in the way of shared principles, when in fact, there is a great deal of sharing of principles.

I work in a domain where systems are engineered for the customer. These systems fall into the Software Intensive System of Systems (SISoS) category. In this domain innovative is also the basis of success. The notion that innovation and engineering - software engineering - are somehow in conflict is common. 

... creativity is simply the production of novel, approprioate ideas, from science, to the arts, to education, to business, to everyday life. The ideas must be movel - different from what's been done before - but they can't be simpmply bizarre; they must be appropriate to the problem or opportuntiy presented. Creativity is the first step in innovation, which is the successful implementaion of those novel, approproate ideas. And innovation, is absolutley vital for long-term corporate success - "Motivating creativity in organmizations: On doing whay you love and loving what you do," [2]

In many conversations about managing in the presence of uncertainty - which is the ubiquitous condition for all non-trivial software development projects - the notion that principles, processes, and practices of Engineered Systems appear to be the antithesis of Agile development in some quarters. 

Both agile advocates and engineered systems advocates practice innovation and creativity. Both fields are supported by a history of creating innovations - and in fact, collaborate on many of the programs I work. In the software engineering domain, like the developer domain, design is the basis of this innovation. Design from a generalized perspective is purposeful ...

... thinking, problem-solving, drawing, talking, consulting and responding to a range of practical and aesthetic constraints to create - ideally - the most appropriate solution(s) under the given circumstances. - [3]

So why is it there is a great divide between the traditional engineered software-intensive system of systems and the current agile development paradigm that appears to reject the basic principles of developing value-based products from capital investments? Why are the core principles of managerial finance and the microeconomics of decision making in the presence of uncertainty rejected by the agile development community? 

Why does the engineered system paradigm reject many of the practices of the agile community as undisciplined, ad hoc practices with little or nor basis in the principles of management? 

Let's start with five core organization principles of agile...

  1. Regular delivery of incremental business value - defined in a Product Roadmap, scheduled in a Cadence or Capability release plan
  2. Iterative development focused on the delivery of Features that enable the needed Capabilities that fulfill the business case or accomplish the mission of the software system
  3. Responding to changing requirements and priorities to assure continuous release of products needed to enable the needed Capabilities to be fulfilled.
  4. Engaging in multiple levels of planning with detailed planning occurring at the Sprint level to produce working software for needed Capabilities produced as planned in the Product Roadmap
  5. Open and regular collaboration across teams and stakeholder to assure a shared vision of the desired project outcome

The engineered SISoS domain has the same paradigm in principle because these principles and five implementation principles are Immutable. The five implementation principles are...

  1. What does done look like described in units of measure meaningful to the decision makers
  2. What is the plan to reach done for the cost and delivery date to produce the needed value to those paying for the work?
  3. What resources are needed to provide the needed capabilities to fulfill the business case or accomplish the mission?
  4. What impediments will be encountered along the way to Done and what handling activities will be applied to remove or reduce these impediments?
  5. How will progress to plan be measured so the decision makers will have confidence their investment will be returned as planned?

So what's the disconnect we hear between Agile and more Traditional systems development? 

The first is the principles listed above are not established first before idea exchange starts. So when there is a gap in the semantics of a conversation, there is not touchstone to go back to. Without this shared understanding of the principles, the conversation becomes self-centered (an echo chamber) and any possible exchange in pursuit of learning is lost.

Second is there is no shared domain as the basis for applying those principles. I work in the SW Intensive System of Systems world. Other work in website development, others work in internal IT shops. While the principles of developing software for money are likely to be the same, the processes and practices can be dramatically different. What is a good practice for our spaceflight avionics system development, is probably of little use to a web developer. And vice versa.

Until we come to agree that the principles are a starting point, and then put a shared domain on top of those, it will an argument without end

Same Same but Different

† "Same Same but Different" is a phrase used a lot in Thailand, especially in an attempts to sell something but can mean just about anything depending on what the user is trying to achieve.

[1] Same Same but Different Perspectives on Creativity Workshops by Design and Business," Alexander Brem and Henrik Spoedt, IEEE Engineering Management Review, Vol. 4, No. 1, First Quarter, March 2017, pp. 27-31

[2] "Motivating Creativity in Organizations: On Doing what you Love and Loving What You Do," T. M. Amabile, California Management Review, 40, pp. 39-58, 1997.

[3] The Design History Reader,  Grace Lees-Maffei (Editor), Rebecca Houze (Editor), Bloomsbury Academic, April 15, 2010.

Related articles The Customer Bought a Capability The Reason We Plan, Schedule, Measure, and Correct Who Builds a House without Drawings? Two Books in the Spectrum of Software Development Complex, Complexity, Complicated
Categories: Project Management

Quote of the Day

Thu, 04/06/2017 - 14:34

Cost estimation is part science, part art. There are many well-defined processes within the cost estimating discipline. There is also a subjective element to cost estimating that makes the discipline an art (NASA, 2004).

Categories: Project Management

Find Root Cause, Fix It, and Only Then Make Suggestions for Improvement

Thu, 04/06/2017 - 02:30

We hear all the time suggestions for improvement. Or suggestions for outright abandonment of established Processes and sometimes even established Principles.

Before listening to any of these and most important making any changes, do a Root Cause Analysis (RCA) of the problem. Most descriptions of a problem are actually descriptions of a Symptom, not the Cause.

If you don't find the cause, fix it, and monitor the fix, you will not actually be fixing anything.

Start here and learn how to actually make improvements by finding the cause of the problem and stop fixing symptoms that leave the problem in place or may even make it worse.

Screen Shot 2017-04-05 at 1.48.18 PM

Categories: Project Management

Quote of the Day

Wed, 04/05/2017 - 02:33

It is the mark of an instructed mind to rest satisfied with the degree of precision which the nature of the subject admits and not to seek exactness when only an approximation of the truth is possible - Aristotle, 384 ‚Äď 322 BC

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