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

How to Talk About Estimates

Herding Cats - Glen Alleman - 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

Herding Cats - Glen Alleman - 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

Software Development Conferences Forecast April 2017

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

New OnDemand Course - 10x Software Development, 2nd Edition

10x Software Development - Steve McConnell - Wed, 04/26/2017 - 11:54

How do you maximize team productivity? Decades of research have found at least a ten-fold‚ÄĒ‚Äú10x‚ÄĚ‚ÄĒdifference in productivity and quality between the best teams and the worst. The studies have collectively involved hundreds of professional programmers across a spectrum of programming activities. Specific differences range from about 5:1 to about 25:1, and in my judgment, that collectively supports the 10x claim. Moreover, the research finding is consistent with my experience, in which I have personally observed 10x differences (or more) between different programmers.

Fully updated from beginning to end, our 10x Software Development, Second Edition online course describes the Eight Key Principles of 10x software development‚ÄĒhow the most effective teams approach their work. The principles are: 

  • Avoid minus-x software development
  • Set direction
  • Attack uncertainty
  • Tailor the solution to the problem
  • Seek ground truth
  • Make decisions with data
  • Minimize unintentional rework
  • Grow capability

You’ll gain a deep understanding of these principles in this course, and you’ll learn specific tactics for turning your team into a 10x team.

New for the second edition are multiple activities to deepen your learning experience, including case studies, exercises, and quizzes; a reassessment and refreshing of every lesson in the course via full in-studio production (no ‚Äúvoice over PowerPoint‚ÄĚ); and the addition of tactic-specific resources to help you take your learning beyond our course. There‚Äôs literally nothing about this course that we haven‚Äôt improved!

Because 10x software development requires all roles to be strong, this course is appropriate for Managers, Technical Leads, Quality Leads, Test Leads, Developers, Testers, and other software project stakeholders. In other words, this is a good course for software development teams as well as individual practitioners.

After you complete this course, you will be able to: 

  • Apply tactics to address the classic mistakes your team is making
  • Identify the development fundamentals you need to grow
  • Make decisions that will stick

After your team completes this course, it will be able to:

  • Confirm that you are all aligned on the project‚Äôs objectives
  • Match your development lifecycle to your work rather than the other way around
  • Apply risk management appropriately
  • Plan the right kind of early defect detection
  • Review and enhance your feedback loops

If you’re not already a member of Construx OnDemand, start a free trial today and take your first steps toward 10x excellence!

For a description of the body of research proving the existence of the 10x phenomenon, see my earlier blog post ‚ÄúOrigins of 10X ‚Äď How Valid is the Underlying Research?‚ÄĚ

Quote of the Day

Herding Cats - Glen Alleman - 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

Does the Scrum Master Role Ever Go Away?

Mike Cohn's Blog - Tue, 04/25/2017 - 17:00

Scrum Masters coach, mentor, guide, and enable their teams to develop great products. For a new team in an organization that is also new to Scrum, this can be a challenging and time-consuming job.

At first, a Scrum Master may spend time educating the team about the Scrum framework itself. The Scrum Master may have to convince the team that, yes, something potentially shippable can be developed in less than three months. The Scrum Master may mentor the team on new practices, such as test-driven development or continuous integration. And the Scrum Master of a new team will spend time helping the new product owner learn how to do that job.

It can take a lot of work to do this. But, it does get easier.

The Scrum Master Role Gets Easier Over Time

Over time, the team improves. And the skills team members acquire from their first steps with agile help them learn, evaluate and adopt new practices.

It is perhaps comparable to learning a new language. At first we learn through memorization. Later, when we know enough to begin conversing in the new language, we can also learn through context: One word in a sentence is new to you, but the other words provide enough context that you can discern the meaning of the new word.

After seeing some early benefits of Scrum, teams don’t need as much convincing to try new agile practices. And, over time, the Scrum Master gradually removes organization impediments to agility. Perhaps an early battle was with the facilities group to move people so that the agile team could sit together. But once fought and won, that battle does not need to be fought again.

This argues strongly that the job of the Scrum Master does get easier over time. In general, it will take less time to be a good Scrum Master a year into a team’s agile journey than it did at the start.

Why the Job Gets Easier

The Scrum Master role gets easier in part because team members begin to take on parts of the job.

After a while, team members need less coaching. They learn how to facilitate some of their own meetings. Team members work more closely and directly with the product owner, so the Scrum Master is no longer needed to resolve communication roadblocks and resolve issues. There are fewer organizational impediments to agility. Those that remain can be particularly difficult to resolve, but there are fewer of them.

And so, the Scrum Master job starts to take less time as the team and organization become better at Scrum.

But Does The Role Ever Go Away Entirely?

But does the effort required to be a ScrumMaster ever go all the way to zero?

Not in my experience.

Even the best Scrum team continues to benefit from the coaching, guiding and mentoring provided by a good Scrum Master. With that being said, some high-performing teams might find they do not need a ScrumMaster full time anymore. They might, for example, opt to have a technical team member also function as the Scrum Master.

But my experience is that even the best teams benefit from having a Scrum Master.

What’s Your Experience?

What have you found to be true about the Scrum Master role over time? Do you agree it takes less time as the Scrum Master and team become more experienced? Have you worked on a team that had so fully absorbed the role of Scrum Master themselves that they did not benefit from a designated, even part-time Scrum Master?

Quote of the Month April 2017

From the Editor of Methods & Tools - Tue, 04/25/2017 - 08:49
The ScrumMaster is one of the most undervalued roles in Scrum and Agile. Most teams that are just starting out don‚Äôt see the value of having a full-time ScrumMaster, and they try to combine this position with that of a developer or tester so that the ScrumMaster is ‚Äúworking.‚ÄĚ It‚Äôs one of the most common […]

Bad Management Behaviours

Herding Cats - Glen Alleman - 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

Engineering the Software Engineer

From the Editor of Methods & Tools - Wed, 04/19/2017 - 14:54
What are the characteristics of a good software engineer? It‚Äôs a topic many people would argue endlessly about. This is not surprising given we are effectively living in the era of software alchemy. Some of the best programmers draw on a strong scientific and engineering background. They combine this with craft like coding skills in […]

Software Development Linkopedia April 2017

From the Editor of Methods & Tools - Wed, 04/19/2017 - 08:04
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about team complexity, developer burnout, blaming, tester skills, code coverage, integration testing, front end architectures and agile antipatterns. Text: Team of Teams & Complexity: An Approach for breaking down Silos Text: […]

#NoEstimates Book - Chapter 1 Summation

Herding Cats - Glen Alleman - 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

Herding Cats - Glen Alleman - 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

Team Size Matters, Reprise

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size¬†increases;¬† team communication paths square when the team increases linearly. Here is the¬†calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2.¬†

  • 4 people, (16-4)/2=6
  • 5 people, (25-5)/2=10
  • 6 people, (36-6)/2=15
  • 7 people, (49-7)/2=21
  • 8 people, (56-8)/2=24
  • 9 people, (81-9)/2=36
  • 10 people (100-10)/2=45

Here’s why the number of communication paths matter: we need to be able to depend on our team members to deliver. Often, that means we need to understand how they work. The more communication paths, the more the team¬†might have trouble understanding who is doing what and when.

When team members pair, swarm, or mob, they have frequent interconnection points. By working together, they reduce the number of necessary communication paths. Maybe you can have a larger team if the team mobs. (I bet you don’t need a larger team then

Categories: Project Management

Planning is King

Herding Cats - Glen Alleman - 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

Herding Cats - Glen Alleman - 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

Why Getting to Done Is So Important

Mike Cohn's Blog - Tue, 04/11/2017 - 17:00

One of tenets of Scrum is the value of getting work done. At the start of a sprint, the team selects some set of product backlog items and takes on the goal of completing them.

A good Scrum team realizes they are better off finishing 5 product backlog items than being half done with 10.

But why?

Faster Feedback

One reason to emphasize getting work to done is that it shortens feedback cycles. When something is done, users can touch it and see it. And they can provide better feedback.

Teams should still seek feedback as early as possible from users, including while developing the functionality. But feedback is easier to provide, more informed, and more reliable when a bit of functionality is finished rather than half done.

Faster Payback

A second reason to emphasize finishing features is because finished features can be sold; unfinished features cannot.

All projects represent an economic investment--time and money are invested in developing functionality.

An organization cannot begin regaining its investment by delivering partially developed features. A product with 10 half-done features can be thought of as inventory sitting on a warehouse floor. That inventory cannot be sold until each feature is complete.

In contrast, a product with 5 finished features is sellable. It can begin earning money back against the investment.

Progress Is Notoriously Hard to Estimate

A third reason for emphasizing getting features all the way to done is because progress is notoriously hard to estimate.

Suppose you ask a developer how far along he or she is. And the developer says “90% done.”

Great, you think, it’s almost done. A week later you return to speak with the same developer. You are now expecting the feature to be done--100% complete. But the developer again informs you that the feature is 90% done.

How can this be?

It’s because the size of the problem has grown. When you first asked, the developer truly was 90% done with what he or she could see of the problem. A week later the developer could see more of the problem, so the size of the work grew. And the developer is again confident in thinking 90% of the work is done.

This leads to what is known as the 90% syndrome: Software projects are 90% done for 90% of their schedules.

Not Started and Done

In agile, we avoid the 90% syndrome by making sure that at the end of each iteration, all work is either:

  • Not started
  • Done

We’re really good at knowing when we haven’t started something. We’re pretty good at knowing when we’re done with something. We’re horrible anywhere in between.

What’s Your Experience?

Have you experienced problems with teams being 90% done? How have you overcome these problems? Please share your thoughts in the comments below.

Book of the Month

Herding Cats - Glen Alleman - 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

Herding Cats - Glen Alleman - 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

Herding Cats - Glen Alleman - 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

Herding Cats - Glen Alleman - 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