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

Do The Math

Herding Cats - Glen Alleman - Mon, 05/11/2015 - 16:18

MathAll project work is probabilistic. All decision making in the presence of probabilistic systems requires making estimates of future emerging outcomes.

But to do this properly we need to have a standard set of terms that can form the basis of understanding the problem and the solution.

When those terms are redefined for what ever reason, the ability to exchange ideas is lost. For example there is a popular notion that defining terms in support of an idea is useful

  • Forecasting and estimating are different things
    • Estimating is about past, precent and future
    • Forecasting is an estimate about the future
  • Monte Carlo Simulation is the same of Boot Strapping sampling
    • ¬†Monte Carlo is an algorithm process of selecting data from under a probabilistic distribution function
    • Boot ¬†strapping is sampling existing data from past samples
    • MCS uses a PDF not past data
  • Probabilistic ¬†forecasting outperforms estimating every time¬†
    • Probabilistic forecasting IS estimating
Related articles The Flaw of Empirical Data Used to Make Decisions About the Future Economics of Software Development Who Builds a House without Drawings? Herding Cats: Decision Analysis and Software Project Management
Categories: Project Management

Mr. Franklin's Advice

Herding Cats - Glen Alleman - Mon, 05/11/2015 - 16:04

Quote-if-you-fail-to-plan-you-are-planning-to-fail-benjamin-franklin-46-18-75 Quote-plans-are-nothing-planning-is-everything-dwight-d-eisenhower-56565

 

 

 

 

 

So what does this actually mean in the project management domain?

Plans are strategies for the success of the project. Strategies are hypothesis. Hypothesis needs to be tested to determine their validity. These tests - in the project domain - comes from setting a plan, performing the work, accessing the compliance of the outcomes with the plan, that corrective actions in the next iteration of the works.

This seems obvious, but when we hear about the failures in the execution of the plans, we have to wonder what went wrong. Research has shown many Root Causes of project shortfalls. Here are four from our domain:

  • Unrealistic performance expectations, missing Measures of Effectiveness and Measures of Performance.
  • Unrealistic cost and schedule estimates based on inadequate risk adjusted growth models.
  • Inadequate assessments of risk and unmitigated exposure to these risks with propers handling plans.
  • Unanticipated technical issues without alternative plans and solutions to maintain effectiveness.

The root cause for each of these starts with the lack of the following

Unrealistic Performance Expectations

When we set out to define what performance is needed we must have a means of testing that this expectation can be achieved. There are several ways of doing this:

  • No Prototypes
  • No Modeling and Simulations of performance outcomes
  • No reference design to base modeling on to discover needed changes in baseline system architecture
  • No use of derived products

Unrealistic Cost and Schedule Estimates

  • No basis of estimate
  • Optimism bias
  • No parametric models¬†
  • No understanding of irreducible uncertainties in duration for work
  • No reference classes.

Inadequate Assessment of Risk

  • Not understanding "Risk management is how adult manage projects" - Tim Lister
  • No risk register connected to planning and scheduling processes
  • No Monte Carlo assessment of risk impacts on cost and schedule
  • No risk mitigation in baseline
  • Inadequate Management Reserve developed from modeling processes

Unanticipated Technical Issues

  • No Plan B
  • No in depth risk assessment of technologies
  • No "on ramps" or "off ramps" for technology changes

Each of these issues can be addressed through a Systems Engineering process using Measures of Effectiveness, Measures of Performance, and Technical Performance Measures. The planning process makes use of these measures to assess the credibility of the plan and the processes to test the hypothesis. 

Related articles Want To Learn How To Estimate? Debunking Let's Stop Guessing and Start Estimating Complex, Complexity, Complicated Estimates
Categories: Project Management

Understanding Software Projects Lecture Series

10x Software Development - Steve McConnell - Thu, 05/07/2015 - 16:24

Check out my new lecture series, "Understanding Software Projects." In this lecture series, I explain The Four Factors Lifecycle Model and how understanding that model means understanding virtually every significant aspect of software project dynamics. Current lectures are always free. Check it out at https://cxlearn.com/catalog/22.

Here's a longer description from the website:

Steve McConnell is the author of software industry classics including Code Complete, Rapid Development, and Software Estimation. He has been recognized as one of the three most influential people in the software industry, along with Bill Gates and Linus Torvalds. 

Join Steve for this Groundbreaking Lecture Series that unlocks the secrets of effective software development. These lectures distill hard-won insights from decades of research and experience. They present learnings from Steve's work with hundreds of companies and thousands of projects. Lectures are 10-20 minutes each and are easy to include in your work day.  

Lecture Series Focus

In this lecture series, Steve explains The Four Factors Lifecycle Model, and he explains how understanding that model means understanding virtually every significant aspect of software project dynamics. Topics include:  

  • The role of Size in the Four Factor Model
  • The role of Uncertainty in the Four Factors Model
  • The role of Human Variation in the Four Factors Model
  • The role of Defects in the Four Factors Model 
  • Numerous case studies that illustrate how to apply the model to gain insights into your software projects  
Benefits 

With the deeper understanding of software projects you gain from this lecture series, you will be able to:  

  • Plan your projects to meet their cost, schedule, quality, and functionality goals
  • Diagnose and correct your project's problems faster and more confidently
  • Accelerate the rate of improvement in your organization
  • Respond appropriately to new developments including new technologies and new software development practices  
Accessing the Lectures 

Although the lectures build on each other, they may also be accessed individually. The series is planned to consist of about 50 lectures total. Lectures will be released through 2015 and 2016. 

Steve's most recent lectures will be complimentary at CxLearn.com for the duration of the lecture series. The full set of archived lectures can be accessed for $99; they are also included in Construx eLearning's All Access Pass. 

 

Let's Stop Guessing and Start Estimating

Herding Cats - Glen Alleman - Thu, 05/07/2015 - 15:24

What’s the difference between estimate and guess?

One way to distinguish between them is degree of care taken when we arrive at a conclusion. A conclusion about how much effort work will take. How much it will cost to perform that work. If that work will hve any risk associated with it. 

Estimate¬†is derived from the Latin word¬†aestimare.¬†‚ÄúTo Value.‚ÄĚ The term estimate is also the origin of¬†estimable, ¬†meaning ‚Äúcapable of being estimated‚ÄĚ or ‚Äúworthy of esteem", and of¬†esteem, which meaning ‚Äúregard."

To make an estimate means to judge - using some method - the extent, nature, or value of something, with the implication that the result is based on expertise, data, a model, or familiarity. An estimate is the resulting calculation or judgment of the outcome or result. The related term is¬†approximation, meaning ‚Äúclose or near.‚ÄĚ Estimates have a measure of¬†nearness to the actual value. We may not be able to know the actual value, but the estimate is¬†close to that value. The confidence in the estimate adds more information about the¬†nearness of the estimate to the actual value.

To guess is to believe or suppose, to form an opinion based on little or no evidence, or to be correct by chance or conjecture. A guess is a thought or idea arrived at by one of these methods. Guess is a synonym for  conjecture and surmise, which like estimate, can be used as a verb or noun.

One step between a guess and an estimate is an educated guess, a more casual estimate. An idiomatic term for this conclusion is ‚Äúballpark figure.‚ÄĚ The origin of this American English idiom, which alludes to a baseball stadium, is not certain. One conclusion is is related to ‚Äúin the ballpark,‚ÄĚ meaning ‚Äúclose‚ÄĚ in the sense that one at such a location may not be in a precise location but is in the stadium.

We could have a hunch or an intuition about some outcome, some numerical value. Or we could engage in guesswork or speculation.

An interesting idea is ‚ÄúDead reckoning‚ÄĚ means the same thing as¬†guesswork, though it originally referred to navigation based on reliable information. Near synonyms describing thoughts or ideas developed with more rigor include¬†hypothesis¬†and¬†supposition, as well as¬†theory¬†and¬†thesis.

A guess is a casual,  spontaneous conclusion. 
An estimate is based on some thought and/or
data.

If those paying you can accept a Wild Ass Guess then you're probably done. If they have tolerance (risk tolerance) for loosing their value at risk if you're guess is wrong, then go ahead and Guess. Otherwise some form of estimate is likely needed to inform your decision about some outcome in the future that is uncertain.

Related articles How We Make Decisions is as Important as What We Decide. The Flaw of Empirical Data Used to Make Decisions About the Future Build a Risk Adjusted Project Plan in 6 Steps Want To Learn How To Estimate?
Categories: Project Management

The Newest Management 3.0 Game: Improv Cards

NOOP.NL - Jurgen Appelo - Wed, 05/06/2015 - 16:04
Improv Cards

The Improv Cards game contains 52 playing cards with pictures on them. You play it with at least three people, though best is probably a table of four to six players.

The post The Newest Management 3.0 Game: Improv Cards appeared first on NOOP.NL.

Categories: Project Management

A Framework for Managing Other Peoples Money

Herding Cats - Glen Alleman - Tue, 05/05/2015 - 17:06

Managing other people's money - our internal money, money from a customer, money from an investor - means making rational decisions based on facts. In an uncertain and emerging future, making those decisions means assessing the impact of that decision on that future in terms of money, time, and delivered value.

To make those decisions - in the presence of this uncertainty - implies we need to develop information about the variables that appear in that future. We can use past data of course. That data needs to be adjusted for several factors:

  • Does this data in the past represent data in the future?
  • Does this data have a statistical assessment for variance, standard deviation, and other¬†moments that we can use to assess the usefulness of the data for making decisions in the future?
  • Are there enough data points to create a credible forecast of the future?

No answers to these questions? That data you collected not likely to have much value in making decisions for the future.

Categories: Project Management

Getting Comfortable with Not Signing Up for Tasks in Sprint Planning

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

In last week’s blog post, I wrote about whether team members should sign up for tasks during sprint planning. I concluded that team commitment goes up when names are left off specific tasks during sprint planning, and this is a good thing.

But, starting a sprint without names on any tasks can also feel very unsettling to teams and ScrumMasters who are new to Scrum. So, I want to offer some advice on how to get comfortable with this idea.

If you’d prefer to leave sprint planning with a name on every task, go ahead; have team members sign up for tasks and make sure each task has a name next to it. Do this for perhaps a team’s first five sprints until everyone is comfortable with the process.

Then switch to having people sign up for only about half of the tasks in the sprint. This will be more than enough to get started and probably won’t feel any worse—or any better—than when everything had a name next to it at the start of the sprint.

But it’s an important first step in the direction of getting out of the habit of allocating tasks to individuals during sprint planning.

Do this for two sprints. After two sprints, have team members sign up for only one-fourth of the total tasks in the sprint. At this point, you’ll almost certainly start to see most of the benefits of a real-time sign-up strategy.

You can stop there if you’d like. Or allocate 25 percent of tasks for two sprints and then go all the way to 0.

How We Make Decisions is as Important as What We Decide.

Herding Cats - Glen Alleman - Mon, 05/04/2015 - 15:36

Working over the week on a release of a critical set of project capabilities and need a break from that. This post will be somewhat scattered as I'm writing it in the lobby to get some fresh air.

Here's the post asking for a conversation about estimates. Here's a long response to that request.

Let's ignore the term FACT for the moment as untestable and see how to arrive at some answers for each statement. These answers are from a paradigm of Software Intensive Systems, where Microeconomics of decision-making is the core paradigm used to make decisions, based on Risk and Opportunity Costs from those decisions.

  • FACT: It is possible, and sometimes necessary, to estimate software tasks and projects.
    • It is always possible to estimate the future. This is well established in all domains. The mathematical means to makes estimates is readily available in any book store, college campus, and on the web.
    • The confidence in the estimate's value is part of the estimating process. Measurement of Error, Variance, Confidence Intervals, Sample Sizes for past performance, and a myriad of other measures are also readily available for the asking
    • The¬†value at risk¬†is one attribute of the estimate
    • Low¬†value at risk¬†provides a wider range on the confidence value
    • High¬†value at¬†risk¬†requires higher confidence
  • FACT: Questioning the intent behind a request for an estimate is the professional thing to do
    • Introducing the profession card is a common tactic. Developing software for moment is not a profession. A profession requires prolonged training, requiring recognition of professional qualifications.¬† Directive on Recognition of Professional Qualifications (2005/36/EC) ‚Äúthose practiced on the basis of relevant professional qualifications in a personal, responsible and professionally independent capacity by those providing intellectual and conceptual services in the interest of the client and the public‚ÄĚ.
    • Programmers are not professions in that sense.
    • To the CFO with a CPA ‚Äď which is a profession ‚Äď the intent of estimates is to inform those accountable for the money to make decisions about that money informed by the¬†value at risk.
    • To question that intent assumes those making those decisions no longer have the fiduciary responsibility for being the stewards of the money. And that responsibility is transferred to those¬†spending¬†the money.
    • This would imply the¬†separation¬†of concerns¬†on any¬†governance¬†based business has been suspended.
  • FACT: #NoEstimates is a Twitter hashtag and was never intended to become a demand, a method or a black-and-white truth
    • The Hash Tag's original poster makes a clear and concise statement.
      • We can make¬†decisions¬†in the absence of¬†estimating¬†the impact of those decisions.¬†
    • Until those original words are addressed, clarified, and possibly corrected, or even withdraw, the hashtag will remain contentious.
    • Since the original post would mean the principle of Microeconomics would not longer be applicable in the development of software using other people‚Äôs money in the presence of uncertainty.
    • Continually redefining the meaning of #NoEstimates to address the willful ignoring of Microeconomics is simply going in circles.
    • If it is possible to make a decision about the future in the presence of uncertainty about that future, uncertainty about the cost of achieving a beneficial outcome from the decision, about the uncertainty of the cost and time needed to achieve that probabilistic outcome ‚Äď WITHOUT estimating, let‚Äôs hear it.
    • And by the way, using past performance samples ‚Äď and small ones at that ‚Äď does not remove to need to estimate the future outcomes. It only provides one way to information the probabilistic behavior of that future outcome. It is still estimating. Calling it No Estimates and using past performance, no matter how poorly formed, does not replace the misuse of the term.
  • FACT: The #NoEstimates hashtag became something due to the interest it generated
    • This is a¬†shouting fire in a theater¬†approach to conversation
    • Without a domain and governance paradigm, the notion of¬†making decisions in the¬†absence¬†of¬†estimates¬†has no basis for being tested.
  • FACT: A forecast is a type of estimate, whether probabilistic, deterministic, bombastic or otherwise
    • Yes, forecasting is estimating outcomes in the future. The weather forecast is an estimate of the future behavior of the atmosphere.
    • Estimates of past and present can also be made.
  • FACT: Forecasting is distinct from estimation, at least in the common usage of the words,¬†in that it involves using data to make the ‚Äúestimate‚ÄĚ rather than relying on a person or people drawing on ‚Äúexperience‚ÄĚ or guessing
    • These definitions are not found outside the posters personally selected operational definitions. No probability and statistics book uses that definition. If there is one, please provide the reference. Wikipedia definitions from other domains don‚Äôt count. Find that definition in the estimating software systems and let‚Äôs talk further.
    • Texts like¬†Estimating Software¬†Intensive¬†Systems¬†do not make this distinction, nor do any other books, papers, and resources on estimating.
    • Estimating is about past, present, and future approximation of value found in system with uncertainty.
      • Estimate ¬†- a number that approximates a value of interest in a system with uncertainty.
      • Estimating - the process used to make such a calculation
      • To Estimate - find a value close to the actual value. 2 ‚Čą 2.3. 2 is an approximation of the value 2.3.¬†
    • Forecasts are about future approximations of values found in systems with uncertainty.
    • Looking for definitions outside the domain of software development and applying to fit the needs of the argument is disingenuous¬†
  • FACT: People who tweet with the hashtag #NoEstimates, or indeed any other hashtag, are not automatically saying ‚ÄúMy tweet is congruent and completely in agreement with the literal meaning of the words in the hashtag‚ÄĚ
    • Those who tweet with hashtag are in fact retweeting the notion that decisions can be made without estimates if they do not explicitly challenge that notion.
    • If that is not established, there is an implicit support of the original idea
  • FACT: The prevailing way estimation is done in software projects is single point estimation
    • This is likely a personal experience, since many stating that have limited experience outside their domain.
    • It is simply bad mathematics, well known to anyone who took a High School statistics class. If you did take that class and believe that, you get a D
  • FACT: The prevailing way estimates are used in software¬†organizations¬†is a push for a commitment, and¬†then an excuse for a whipping when the estimate is not met.
    • Again likely personal experience.
    • If the poster said¬†in my experience...¬†that would establish the limits of the statement.
    • ‚ÄúIME‚ÄĚ takes 3 letters. Those are rarely seen by those suggesting¬†not¬†estimating¬†is a desirable approach to managing in the presence of uncertainty while spending other people money.
    • Those complaining the phrase¬†spending other peoples money¬†are likely not dong that, or not doing that with a substantial¬†value at risk.¬†
  • FACT: The above fact does not make estimates a useless¬†artifact, nor estimation itself a useless or¬†damaging activity
    • Those proffering decisions can be made without estimating have in FACT said estimating are damaging, useless, and a waste of time.
    • Until that is countered, it will remain the basis of NoEstimates.

So if the OP is actually interested in moving from the known problem of using estimates in a dysfunction way, let's stop speaking about how to make decisions without estimates, and learn how to make good estimates needed for good decisions.

This issue of Harvard Business Review is dedicated to Make Better Decisions. Start with reading how to make good decisions. There is a wealth of guidance how to do that. Why use Dilbert-style management examples. We all now about those. How about some actionable corrective actions to the root causes of bad management. All backed up with data beyond personal anecdotes. Reminds me of eraly XP where just try it was pretty much the approach. So if the OP is really interested in...

Let’s use our collective influence and intelligence to take the discussion forward to how we can cure the horrible cancer in our industry of Estimate = Date = Commitment.

Then there are nearly unlimited resources for doing that. The first is to call BS on the notion decisions can be made without estimates, without stating where this is applicable - first. Acknowledge unequivocally that estimates are needed when the value at risk reaches a level deemed important by the owners of the money, and start acting like the professionals we want to be and gain a seat at the team to improve the probability of success of our projects with credible estimates of cost, effort, risk, productivity, production of value, and all the other attributes of that success. 

For those interested in exploring further how to provide value to those paying your salary, here are some posts on Estimating Books

Categories: Project Management

Forecasting the Future is Critical to All Success

Herding Cats - Glen Alleman - Fri, 05/01/2015 - 18:47

Skate to Where Puck Will BeFull attribution to Gaping Void for this carton. http://gapingvoid.com/2010/05/03/daily-bizcard-11-fred-wilson/

Wayne makes realtime estimates on every skate stroke of where he is going, where the puck is going, and where all the defensemen are going to be when he plans to take his shot on goal.

When we hear we can make decisions about the future without estimating the impact from those decision or using only small sample, non-statistically adjusted measures, or ignore the stochastic behaviors of the past and the future we'll be ion the loosing end of the shot on goal.

There simply is no way out of the need to estimate the future for any non-trivial project funded by other peoples money. Trivial project? Our own money? Act as you wish. No one cares what you do. Make a suggestion it works somewhere else, better come to the table with some testable data independent of personal anecdotes. 

Related articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future The Flaw of Averages and Not Estimating
Categories: Project Management

Fit for Purpose and Fit for Use

Herding Cats - Glen Alleman - Fri, 05/01/2015 - 07:15

ITILIn the governance paradigm there are two terms used to test ideas, processes, and their outcomes.

Fit for Purpose and Fit for Use

Both these terms are used to describe value of an IT outcome. A product or service value is defined by fit to purpose (utility) and fit to use (warranty).

Fit to purpose, or utility, means that service needs to fulfill customer needs.

Fit for use, or warranty, means that product or service is available when a user needs it.

From Phillippe Kruchten's The Frog and the Octopus we get 8 factors defining a context from which to test any  idea that we encounter.

  1. Size
  2. Criticality
  3. Business model
  4. Stable architecture
  5. Team distribution
  6. Governance
  7. Rate of change
  8. Age of system

So when we hear something that doesn't seem to pass the smell test, think of Carl's advice

Nice Hypothesis

And then when we hear you're just not willing to try out this idea, think of some more of his advice.

Tumblr_mizbc3VWht1ri1icuo1_500

Then ask, how is this idea of your Fit for Purpose and Fit for Use in those 8 context factors? Don't have an answer? Then maybe the personal anecdotes are ready for prime time in Enterprise domain.

Related articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct
Categories: Project Management

The #NoBureaucracy Discount

NOOP.NL - Jurgen Appelo - Thu, 04/30/2015 - 17:23
No Bureaucracy

On just a single day, I had to deal with various activities that I can only describe as bureaucracy.

The post The #NoBureaucracy Discount appeared first on NOOP.NL.

Categories: Project Management

Domain is King, No Domain Defined, No Way To Test Your Idea

Herding Cats - Glen Alleman - Thu, 04/30/2015 - 16:09

ValueStreamFrom Mark Kennaley's book. 

When we hear of a new and exciting approach to old and never ending problems, we need to first ask in what domain is your new and clever solution applicable

No domain, not likely to have been tested outside you personal anecdotal experience.

Here's Mark's Scaling factors. He uses Agile as the starting point, but I'm expanding it to any suggestion that has yet to be tested outside of personal anecdotes

  • Team size - 1 maybe 2 ‚ÜĒÔłé 1000's.
    • If you've tested your idea on a small team, will it work in a larger setting?
    • There are project where 1000's of engineers, developers, testers, support people work on the same outcome.
    • There are projects where 2 people work on the same project.
    • The business process usually defines the team size, not the method. Writing code for a family owned sprinkler company is not the same as writing code for a world-wide ERP system.
  • Geographic location - co located ‚ÜĒÔłé across the planet.
    • Having a co-located team is wonderful in some instances.
    • In other instances this is physically not possible.
    • In other cases, the customer simply can't be with the development team, no matter how desirable that is.
  • Organizational Structure - single monolithic team ‚ÜĒÔłé Multiple Divisions
    • Small firms with single structures¬†
    • Larger firms with "business units"
    • Even larger firms with separate companies under the same Logos
    • Your method doesn't get to say how the firm is¬†organized, it needs to adapt to that organization.
  • Compliance - None ‚ÜĒÔłé Life, financial, safety critical
    • Governance is a broad term, so is compliance
    • The notion of customer collaboration over contract negotiation is usually spoken by those with low value at risk.
  • Domain Complexity - Straightforward ‚ÜĒÔłé Very Complex
    • Complex and Complexity are relative terms.
    • For a developer who has built web pages for the warehouse, the autonomous rendezvous and dock flight software may appear complex.¬†
    • To the autonomous rendezvous and dock developers, the GPS ground system of 37 earth stations may appear complex.
    • ¬†Pick the domain, then assess the complexity
  • Technical Complexity - same as above

What's the Point?

When a new approach is being proposed, without a domain, it's a solution looking for a problem to solve.

Categories: Project Management

Software Development Conferences Forecast April 2015

From the Editor of Methods & Tools - Thu, 04/30/2015 - 13:57
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software […]

Two Books in the Spectrum of Software Development

Herding Cats - Glen Alleman - Wed, 04/29/2015 - 04:59

ValueStreamI had the pleasure of meeting Mark Kennaley a week ago in Boulder when he attended the Denver PMI conference. I have talked with Mark on several occasions on social media about the SDLC 3.0 book and concepts. And now his Value Stream: Generally Accepted Practice in Enterprise Software Development, which is a continuation of the first book, but focused not just in the development life cycle but the entire enterprise process.

I say all this for a simple reason. Mark's book is unique in that from the first page it resonated with the ideas I hold dear. It is not only well written, it contains powerful ideas that need to be read any anyone in the enterprise IT business. Mark signed the title page with a phrase that reflects my feelings on many modern topics in project management and software development.

UntitledThis pretty much sums up my World View for those suggesting solutions to complex problems can be had with simple and many time simple minded ideas. Mosty ideas borrowed from quotes about completely different domains, or recycle words like Systems and Systems Engineering into psycho-babble terms that cannot be tested in practice. 

I'm going to write a review of Mark's book chapter-by- chapter. I'm on chapter 3. So far it's a breathtaking read. Mandatory for anyone claiming to work in the Enterprise IT world and be accountable for the spend of other peoples money.

DownloadI also bought Ron Jeffries book to read on my two week assignment to a client site.

I met Ron at an Agile Development Conference long ago, where I was speaking about agile in government contracting. As well Ron spoke at a local ACM meeting that included many software engineering staff from US West, now Centurylink.

It was interesting to observe the interactions between eXtreme Programming and RBOC software engineers.

I've just started this book, but thought it would be a good read just to see how far the eXtreme Programming paradigm has come. I expect I'll get something out of both books. I'll do the same chapter-by-chapter review here as I'll do for Mark's book. 

Related articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future Who Builds a House without Drawings?
Categories: Project Management

The Customer Bought a Capability

Herding Cats - Glen Alleman - Tue, 04/28/2015 - 15:33

Customers buy capabilities to accomplish a business goal or successfully complete a mission. Deliverables are the foundation of the ability to provide this capability. Here's how to manage a project focused on Deliverables. 

Deliverables Based Planning from Glen Alleman These capabilities and the deliverables that enable them do need to show up at the time they are needed for the cost necessary to support the business case. They're not the Minimal Viable Capabilities, they're the Needed Capabilities. Anything less will not meet the needs of the business.
Categories: Project Management

Should Team Members Sign Up for Tasks During Sprint Planning?

Mike Cohn's Blog - Tue, 04/28/2015 - 15:00

During sprint planning, a team selects a set of product backlog items they will work on during the coming sprint. As part of doing this, most teams will also identify a list of the tasks to be performed to complete those product backlog items.

Many teams will also provide rough estimates of the effort involved in each task. Collectively, these artifacts are the sprint backlog and could be presented along the following lines:

One issue for teams to address is whether individuals should sign up for tasks during sprint planning.

If a team walks out of sprint planning with a name next to every task, individual accountability will definitely be increased. I will feel more responsibility to finish the tasks with my name or initials next to them. And you will feel the same for those with yours. But, this will come at the expense of team accountability.

My recommendation is that a team should leave sprint planning without having put names on tasks. Following a real-time sign-up strategy will allow more flexibility during the sprint.

Quote of the Month April 2015

From the Editor of Methods & Tools - Mon, 04/27/2015 - 13:30
Code that doesn’t have tests rots. It rots because we don’t feel confident to touch it, we’re afraid to break the “working” parts. Code rotting means that it doesn’t improve, staying the way we first wrote it. I’ll be the first to admit that whenever I write code, it comes in its most ugly form. […]

The Flaw of Empirical Data Used to Make Decisions About the Future

Herding Cats - Glen Alleman - Sun, 04/26/2015 - 19:20

It's popular in the agile world and even more popular in the No Estimates paradigm to use the term empirical data as a substitute for estimating future outcomes. And my favorite meme that further confuses the conversation.

Probabilistic forecasting will outperform estimation every time

This of course is "It is not only not right, it is not even wrong."† Probabilistic forecasting IS estimating. Estimating is about the past, present, and future. Forecasting is estimating about the future. I'll save the embarrassment by not saying the name of the #NoEstimates person posting this. 

First a definition. Empirical  is originating in or based on observation or experience. But we all should know that that data needs to properly represent two sides of the problem, the past and the future.

Let's look at some flawed logic in this empirical data paradigm:

  • The past -¬†we took 18 samples from the start of the project till now and calculated the Average number of value and we'll use that as a¬†representative¬†number for the future.
  • The future - is the past a proper representation - statistically - of the future?¬†
    • It's taken 45 minutes from the driveway to the airport garage the last 5 times I¬†left¬†on¬†Monday afternoon to the remote site.
    • What's the probability it will take 45 minutes today?

One more technical detail.

  • The¬†flow¬†or¬†Kanban¬†style processes depend on a critical concept - Each random variable that is always present in our project must be Identical and Independently distributed.
  • This means each random variable has the same¬†probability distribution¬†as the others.
  • This CAN be the case in some situations, but when we are developing software in an emergent environment - not production line - it is unlikely.¬†¬†

So Now Some Issues Of Using Just Empirical Data

The future is emergent in most development work. If it's a production line, and software development is not production, then past performance is a good indicator of future performance. So let's ask some questions before using this past empirical data:

  • Is the data in the past properly assessed for variance, stability - stationarity, independence?
  • It is now of these, what are the statistical parameters. Especially¬†independence. The notion of ¬†INVEST in agile cannot be assumed without a test.¬†
  • Is the future going to be stable, stationary, independent and represented by the past?
  • What's the uncertainty in the future events?
  • What was the uncertainty in the past that was not recognized and influenced the statistics but was not represented?
  • What are the irreducible uncertainties in the future - the naturally occurring variances that will need margin?
  • What are the reducible uncertainties in the future that must be¬†brought down or have¬†management reserve?

Don't have the answers to these and working a non-trivial project? Our empirical data is not worth much because it doesn't actually represent the future. Might as well guess and stop using the term empirical as a substitute for you know know much of anything about the future.

With those answers we can build a credible model of the future, with interdependencies between the work, probability distribution functions for the statistical behaviors of the work elements and start asking the Killer question:

What's the probability of completing on or before the need date for the work we are producing?

This answer only tells us the probability, not the exact date. So here's the most important point.

  • When we have a model, we can test if there is an acceptable probability of success.
  • That's all we can do, model, test, assess, model some more.

All decisions about future outcomes in the presence of uncertainty need estimates that are placed in the model and assessed for their applicability.

This is called Closed Loop Statistical Process Control. And that's how non-trivial projects are managed. Low value at risk, no one cares if you estimate or not. 

† Which by the way is the situation with most of  #NoEstimates conjectures, starting with the willful ignorance of the MicroEconomics of decision making as an opportunity cost process. What will is cost us if we decided by multiple choices in the presence of an uncertain future? That questions can't be answered without making an estimate of that opportunity cost.

 

Categories: Project Management

Want To Learn How To Estimate? Part Troisième

Herding Cats - Glen Alleman - Sat, 04/25/2015 - 22:46

If you work in a domain, as I do, the need to answer the question when will we providing that needed capability to produce the planned value for the planned amount of money, then estimating is going to be part of answering those questions.

If you work where those paying for the work have little or no interest in asking these questions or knowing these answers, or have confidence you'll not overrun the cost, schedule, and deliver the needed capabilities as planned, then maybe estimates are needed.

Be interesting to hear from those actually paying for those outcomes to see what they need to make decisions in the presence of uncertainty.

Here's some more guidance for getting started with estimating software efforts.

And some tools to help out

So you see a trend here? There is nearly unlimited resources on how to estimate software development projects, how to manage in the presence of uncertainty, how to elicit requirements, how the plan and schedule software projects.

So if you hear we're bad at estimates, that's likely the actual experience for the person making that statement, because the person saying that hasn't yet learned how to estimate. Or when we hear estimates are a waste, it's likely it's not their money, so to them estimates take away from some other activity they see as more important. Why do they care of the project overruns it's budget, is late, or doesn't produce the needed value? Or my favorite estimates are the smell of dysfunction, when there is no domain, root cause, or corrective actions suggested, because that's actually hard work, and it's much easier just to point out bad management than provide suggestions of good management. 

Estimating is hard. Anything of value is hard. All the easy problems have been solved. 

But if we are to ever get a handle on the root causes of software project failure modes, we do need to seek out the root causes. A that means much more than just asking the 5 Whys. That's one of many steps in RCA and far from the complete solution to removing the symptoms of our problems. So start there, but never leave it there. 

Here's some approach we use

Unanticipated cost growth is a symptom of failing to properly estimate in the first place, update those estimates as the project progresses, and deal with the underlying risks that drive that cost growth. Same for lateness and less than acceptable delivered capabilities. Once the estimate has been established in some credible form, adjusted as the project progresses, you of course have to execute to the plan, or change the plan. It's a closed loop system

  • Target
  • Execute¬†
  • Assess performance
  • Determine error signal
  • Take corrective actions
    • Change target
    • Change execution processes
  • Repeat until complete

The answer to the root causes that create the symptoms we so quickly label as smells of dysfunction is NOT to stop doing something, but the learn what the actual cause is. Stopping before this knowledge is acquired leaves the symptom still in place. And that doesn't help anyone.

Related articles Who Builds a House without Drawings? Decision Analysis and Software Project Management Herding Cats: Five Estimating Pathologies and Their Corrective Actions Capability Maturity Levels and Implications on Software Estimating Economics of Software Development Qui Bono Want To Learn How To Estimate? Calculating Value from Software Projects - Estimating is a Risk Reduction Process Root Cause Analysis
Categories: Project Management

Thinking About #NoEstimates?

I have a new article up on agileconnection.com called The Case for #NoEstimates.

The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!

This column is the follow-on to How Do Your Estimates Provide Value?

If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)

Categories: Project Management