Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Five Immutable Principles of Project Success

Herding Cats - Glen Alleman - Sun, 05/01/2016 - 15:34

All successful projects adhere to these five immutable principles during the lifecycle of the design, development, deployment, and operation. These principles are independent of any project or program domain or context in that domain. They are also independent of any project management method or product development method, including agile.

They ask five questions that must have credible answers that establish the foundation for success. Without credible answers to these 5 questions, the project has little hope of success.

This paper is the basis of the book, Performance-Based Project Management. and a review from Max Wideman

So if you hear some unsubstantiated conjecture like ... decisions can be made without estimating ask how any or all of the 5 immutable principles can be met?

 

Related articles Principles Trump Practices Managing in Presence of Uncertainty Domain and Context Are King, Then Comes Process and Experience
Categories: Project Management

Podcast About Geographically Distributed Agile Teams

Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site.

We covered how you can think about your geographically distributed agile team:

  • Why you want a distributed agile team (yes, there are some great reasons)
  • How you might organize your team.

Here are the articles I mentioned:

Managing Multicultural Projects with Complementary Practices

I wrote about the timezone bubble chart in Managing Timezones in Geographically Distributed Agile Teams

Here are three posts about Geographically Distributed Teams Have Choices for Lifecycles about options for how you might do agile with a geographically distributed agile team.

I even had a chance to rant about management. We had a blast, as you can tell. Hope you enjoy it.

Categories: Project Management

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Herding Cats - Glen Alleman - Wed, 04/27/2016 - 04:55

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (not de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considered those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz word without knowing what they actually mean.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made with estimates,” and continue on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money
2. Unrealistic cost and schedule estimates – the source of poor estimating
3. Inadequate assessment of unmitigated risk exposure
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

Can You Make a Decision in Presence of Uncertainty Without Estimating?

Herding Cats - Glen Alleman - Tue, 04/26/2016 - 21:50

The answer to this question starts with a simple principle based notion.

Can you make a non-trivial (de minimis) decision in the presence of uncertainty?

The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considered those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that in the future.

The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.

Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.

Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz word without knowing what they actually mean.

From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.

These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made with estimates,” and continue on with “estimates are a waste of developers time, they should be coding not estimating.”

It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”

In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs –  IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.

As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money
2. Unrealistic cost and schedule estimates – the source of poor estimating
3. Inadequate assessment of unmitigated risk exposure
4. Unanticipated technical issues.

Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.

So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”

As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”

Related articles Managing in Presence of Uncertainty Here, There Be Dragons Estimating Processes in Support of Economic Analysis
Categories: Project Management

Software Development Conferences Forecast April 2016

From the Editor of Methods & Tools - Tue, 04/26/2016 - 10:09
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 […]

Quote of the Day

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

For the great enemy of truth is very often not the lie ― deliberate, contrived, and dishonest ― but the myth ― persistent, persuasive, and unrealistic. Too often we hold fast to the clichés of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought. ― John F. Kennedy

Take care when you hear any opinion not based on principles, for you are succumbing to those opinions produced by personal anecdotes - untested outside that personal experience - are the basis of myth. When those making those untested personal anecdotal conjectures vigorously criticize those asking for evidence, be more careful. For the smell comes from the propagation of the myth not the facts. 

Related articles Good Project and Bad Project How We Make Decisions is as Important as What We Decide. The Cognitive Illusion of Bad Software Project Outcomes Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Small-World Networks Article Posted

I’m a new contributor to the TechBeacon site. I have an article up, called Small-world networks: a lightweight alternative to SAFe for scaling agile.

 Scaling Collaboration Across the OrganizationYes, it’s based on Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Hope you enjoy the article.

Categories: Project Management

Governance and Estimating

Herding Cats - Glen Alleman - Mon, 04/25/2016 - 14:18

If your business is not subject to any external governance process, you’re free to spend your money as you please. But you’re not free to suggest your approach is applicable to those who are governed by external frameworks of spending and accountability for that spend, without a testable confirmation this idea doesn’t violate those governance principles.

Governance includes: Responsibility for a specific duty, task, or decision. Authority to influence behaviours. Communication of decisions. Empowerment to give individual's authority to act.

The governing of IT systems has two distinct components.

  1. A structural component that pertains to the organisation’s information technology activities, the way those activities support the goals of the business, and the people who help manage those activities.
  2. A process component that defines the decision-making rights associated with IT as well as the mechanisms and policies used to measure and control the way IT decisions are made and carried out within the organisation.

All businesses that operate inside governance frameworks, which address:

  • Risk, Conformance and Compliance - COSO, CoBit, ISO 27001, ISO 38500
  • Development Change control - ISO 12207, CMMI, CoBit, OPM3, Prince2
  • Information & Technology Balance Sheet - Balanced Scorecard, Zachman 
  • Operations - ITIL, ITPO, PCI DSS, BCM/BS25000, ISO 20000, TCO/ROI, ISO 27001, CoBit
  • Business Strategy - Balanced Scorecard

make use of estimates in their decision support processes. To suggest Not Estimating can be the basis of those decision making process is to willfully ignore these principles.

If it’s not your money, you don’t get to do as you please. If it’s your money, do as you please no one really cares. If it’s your customer’s money, confirm with them how they expect you to behave when spending that money.

Categories: Project Management

How to Save Your Business

NOOP.NL - Jurgen Appelo - Sun, 04/24/2016 - 14:00
how-to-save-your-business

When it comes to transforming their organizations, people often ask me the same silly questions.

Imagine a village of people who have successfully lived in a forest for hundreds of years. Some have grandiose tree houses; others have excavated spacious homes under the ground. Some villagers are specialized woodcutters; others prefer to hunt or gather nuts and fruit. And a few of the villagers are officials who take care of this small but thriving society. They see to it that all specialist jobs are adequately covered and that all are properly represented on the Village Council.

Recently, however, there has been some unrest in the village: There is a strong wind from the west and it carries with it the faint odor of… fire.

=8-C

This is a metaphor that we can use for almost every company that has made good money in the past and that is now facing the threat of eradication by globalization, innovation, and a relentless pace of change.

As a public speaker, I travel around the world quite a bit, and I encounter many of such villages, small and large. Fortunately, almost everyone I meet has realized that their village cannot escape the fire. To survive, the villagers will have to move elsewhere. But the people in these villages have a lot of questions for the traveling visitor:

Where is the environment safe?

Everywhere but here! The question assumes that there are safe and unsafe places for organizations to exist. Well, guess what? The world of business is changing faster and faster. Most places are variously safe and unsafe at different times. Fires, tsunamis, and earthquakes can now happen everywhere. The goal for a business should not be to resettle in a “safe” environment. Workers should learn to become organizational nomads: get used to the idea of packing your bags and relocating the whole organization to another business environment.

Which framework do we implement?

A framework for what? Do you want a predefined migration plan? Do you want a Gantt chart for turning a village into a caravan? I suggest you get people to figure out how to make vehicles from your tree houses and appoint some scouts who are willing to explore other environments. You can pick up books such as Out of the Forest, Escape Your Tree, and Business Nomads. They may speed up your learning. (You’re not the first to run from a fire.) You move your village by forcing everyone to accelerate their exploration and learning, not by arguing about the best framework for implementation of a plan.

How long will the transformation take?

Every time you ask a silly question, it takes one minute longer. How long does it take to get a group of people on the move? It depends on how many people you have, how willing they are to leave their homes behind them, how smart they are learning new skills, and whether the fire is still far enough so that you have some time to properly pack your bags. If you can see the fire, drop everything and run! Travel will be slower without preparations, but at least you’ll live. As a villager, you can estimate all these things better than I can, as a visiting traveler.

Should the transformation be bottom-up or top-down?

Is that in any way relevant? The fire is coming sideways! Everyone in the village will have to prepare for the move. Some will start earlier than others. Some will learn faster than others. And some will do more than others. Failed transformations are those where people waste time debating endlessly who should take the lead. The fire doesn’t care if the officials are leading the escape or not. Leaders are those whose bags are packed first and then show others how to do it. In an escape, there’s no bottom-up and top-down. There’s only inside-out.

How do we convince the managers?

Convince the managers of what? That there’s a fire coming? If they don’t smell it, I would start packing my bags without permission of the managers. But managers often know quite well that the village isn’t safe anymore. The usual problem is that they want to manage the migration the way they always managed the village. They want to apply the laws for tree houses also to mobile homes. But a band of travelers is different from a group of villagers and thus, they need different rules. Tell your managers that the road trip needs management with new rules.

Are OutOfTheForest and BusinessNomads just buzzwords?

Who cares? Smell the fire! Don’t just stand there discussing proper terminology. Start leading the escape!

Organizations change and survive when people accelerate their pace of exploration and learning. The way a company was managed in its old environment doesn’t work that well when it’s moving about, finding a new environment. And another one. And another one. Even worse, none of the same rules apply to the transformation itself. The migration, at least in the beginning, is all improvisation!

So, instead of your usual plans, targets, performance evaluations, committees, and policies, I suggest you hold a regular corporate huddle or town hall meeting and get everyone involved in updating each other on the status of the danger, the opportunities for safer places, and the progress of the travel preparations. Each person, from their own discipline, takes responsibility for learning how to be a valuable community member among the new business nomads.

That’s how you save your business.

photo: (c) 2006 Ervins Strauhmanis, Creative Commons 2.0

The post How to Save Your Business appeared first on NOOP.NL.

Categories: Project Management

Software Development Linkopedia April 2016

From the Editor of Methods & Tools - Wed, 04/20/2016 - 09:07
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 scaling Agile, Test-Driven Development, recruiting developers, managing technical debt, distributed teams, breaking the rules, test automation, Agile metrics and machine learning. Web site: Agile Scaling Knowledgebase Blog: What do you […]

Sprint Planning for Agile Teams That Have Lots of Interruptions

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

Many teams have at least a moderate ability to plan and control their time. They're able to say, "We will work on these things over the coming sprint," and have a somewhat reasonable expectation of that being the case.

And that's the type of team we encounter in much of the Scrum literature--the literature that says to plan a sprint and keep change out.

But what should teams do when change cannot be kept out of a sprint?

In this post, I want to address this topic for two different types of teams:

  • A team that has occasional, but not excessive, interruptions
  • A team that is highly interrupt-driven
Planning with a Moderate Margin of Safety

Many teams will benefit from including a moderate amount of safety into each sprint. Basically, these teams should not assume they can keep all changes out of the sprint. For example, a team might want to leave room when planning a sprint for things like:

  • Fixing critical operational issues, such as a server going down
  • Fixing high-severity bugs
  • Doing first- or second-level tech support

There could be many other similar examples. Consider your own environment. You want to try to set a high threshold for what constitutes a worthy interruption to a sprint. Teams really do best when they have large blocks of dedicated time that will not be interrupted.

To accommodate work like this, all a team needs to do is leave a bit of buffer when planning the sprint. Let’s see how that works.

The Three Things That Must Go into Each Sprint

I think of a sprint as containing three things: corporate overhead, and plannable and unplanned time. I think of this graphically as shown in Figure 1.

Figure 1:

Corporate overhead is that time that goes towards things like all-company meetings, answering emails from your past project, attending the HR sensitivity training and so on. Some of these activities may be necessary, but in many organizations, they consume a lot of time.

I put Scrum meetings (planning, daily scrum, etc.) in the corporate overhead category as well.

Plannable time is the second thing that goes into a sprint. This is the time that belongs collectively to the team.

But the team does not want to fill the entire remainder of the sprint with plannable time. The team needs to acknowledge the need to leave room for some amount of unplanned time.

Unplanned time goes towards three things:

  • Emergencies
  • Tasks that will get bigger than the team thinks
  • Tasks that no one thinks of during the sprint planning meeting
The Appropriate Percentages

I’m frequently asked what percentages teams should use for each of the three categories. I can’t answer that. But I can tell you how to figure it out:

After each sprint, consider how well the unplanned time the team allocated matched the unplanned time the team needed for the sprint. And then adjust up or down a bit for the next sprint. This is not something a team can ever get perfect.

Instead, it’s a game of averages. The team needs to save the right amount of time for unplanned tasks on average. Then some sprints will have more unplanned tasks occur and some sprints will have fewer.

When fewer occur, the team should get ahead on their work. so they’re prepared for when more unplanned tasks occur.

What to Do When a Team Is Highly Interrupt-Driven

The preceding advice works well for the majority of agile teams--those that are only interrupted a moderate amount. Some teams, however, are highly interrupt-driven.

Again, I want to resist putting actual percentages on the regions in Figure 1, but I’m describing a situation in which the area of “unplanned time” becomes much larger than shown.

I actually want to talk about the cases in which unplanned time becomes the dominant of the three areas. Such teams are highly interrupt-driven.

These teams still want to include space in their sprints for unplanned time. But there are usually a few other things you may want to consider if you are on a highly interrupt-driven team.

First, you may want to adjust your sprint length. One option is to go with a long sprint length. Increasing sprint length has the benefit of making the rate of interruption more predictable because the variance will not be so great from sprint to sprint.

To see how that works, imagine you chose a one-year sprint. (Don’t do that!) It’s easy to imagine with such long sprints, the fluctuations a team faces with short sprints will wash out. Sure, this year (this sprint) might have more interruptions than last year (last sprint), but it’s such a long period that the team has time to recover from any excessive fluctuations.

The other option is to go with short, one-week sprints and just live with the unpredictability. The team will be less able to assure bosses “we will be done with this” by a given period, but I find that to be a worthwhile tradeoff.

Second, a highly interrupt-driven team should make sprint planning a very lightweight activity.

Sprint planning should be a quick effort to grab a few things the team thinks it can do in the coming week, and that’s that. It should be a very minimal effort--15 or 30 minutes for many teams.

To illustrate this, think about planning a party, and imagine a spectrum with planning a wedding reception on one end. That’s some serious party planning. At the other end of the spectrum is inviting some friends over tonight to watch the big game on TV. To plan that, I’m going to check the fridge for beer and order a pizza. That’s a different level of party planning.

Sprint planning for a highly interrupt-driven team should be much more like the latter--quick, easy and just enough to be successful.

What Do You Do?

How do you handle interruptions on your agile team? Please share your thoughts in the comments below.

30 Problems That Affect Software Projects

Herding Cats - Glen Alleman - Mon, 04/18/2016 - 15:10

From Estimating Software Costs: Bringing Realism To Estimating, 2nd Edition.

  1. Initial requirements are seldom more than 50 percent complete
  2. Requirements grow at about 2 percent per calendar month during development
  3. About 20 percent of initial requirements are delayed until a second release
  4. Finding and fixing bugs is the most expensive software activity
  5. Creating paper documents is the second most expensive software activity
  6. Coding is the third most expensive software activity
  7. Meetings and discussion are the fourth most expensive activity
  8. Most forms of testing are less that 30 percent efficient in finding bugs
  9. Most forms of testing touch less than 50 percent of the code being tested
  10. There are more defects in requirements and design than in source code
  11. There are more defects in test cases than in the software itself
  12. Defects in requirements, design and code average 5.0 per function point
  13. Total defect-removal efficiency before release averages only about 80 percent
  14. About 15 percent of software defects are delivered to customers
  15. Delivered defects are expensive and cause customer dissatisfaction
  16. About 5 percent of modules in applications will contain 50 percent of all defects
  17. About 7 percent of all defect repairs will accidentally inject new defects
  18. Software reuse is the only effective for materials that approach zero defects
  19. About 5 percent of software outsource contracts end up in litigation
  20. About 35 percent of projects greater that 10,000 function points will be canceled
  21. About 50 percent of project greater than 110,000 function points will be one year late
  22. The failure mode for most cost estimates is to be excessively optimistic.
  23. Productivity rates in the U.S. are about 10 function points per staff month
  24. Assignment scopes for development are about 150 function points
  25. Assignment scopes for maintenance are about 750 function points
  26. Development costs about $1,200 per function point in the U.S.
  27. Maintenance costs about $150 per function point per calendar year
  28. After delivery applications grow at about 7 percent per calendar year during use
  29. Average defect repair rates are about ten bugs or defect per month
  30. Programmers need about ten days of annual training to stay current

Agile addresses 1, 2, 3, 4, 5, and 6 well. 

So if these are the causes of project difficulties - and there may be others since this publication, what are the fixes?

 

Categories: Project Management

What Is Management in the Context of Agile

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

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

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

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

Screen Shot 2016-04-17 at 4.03.36 PM

 

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

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

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

It is common to use the phrase 

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

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

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

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

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

Apollo

 

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

Project Breathalyzer

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

Screen Shot 2016-04-12 at 5.11.38 PM

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

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

 

 

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

My Book Tour in North America

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

This year in June, publisher John Wiley & Sons will release Managing for Happiness, the updated version of my very successful #Workout book. To celebrate this, I have a special offer for event organizers in the USA and Canada.

For an appearance at any event (either public or in-company) during my book tour, I offer 100 copies of my new book for free, and for anything above that number, I offer a 50% discount from the catalog price (USD 35). This only applies to events taking place during my book tour in North America from June 30 to August 31.

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

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

Categories: Project Management

Announcing My First Certified Scrum Master Course in Austin

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

I'm coming to Austin!

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

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

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

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

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

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

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

Where to Next?

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

Quote of the Month April 2016

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

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

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

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

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

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

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

The Seven Steps are:

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

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

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

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

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

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

 

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

Process Improvement In the Second Grade

Herding Cats - Glen Alleman - Fri, 04/08/2016 - 02:53

Our daughter is an elementary school teacher in Austin - and a Graduate student at UT Austin in the Board Certified Behavioral Analyst program. When I hear about some corrective action to an unnamed cause - not the symptom but the cause -  like estimates are the smell of dysfunction, I think of a chart she has hanging in her room for her students, where they are learning critical thinking skills they will need in life. 

Screen Shot 2016-04-02 at 5.45.46 PM

  • Focus Question - what is the question we're trying to explore? Is that question clearly formed?
  • Prediction - is there a prediction of what the possible outcomes might be when we discover the answer to the question? This is important, because we need to separate the answers into plausible answers and implausible answers. That way we can sort out the Wheat from the Chaff. Which is a nice way of saying sorting out the BS from the plausible.
  • Plan - OK, now what's our plan to start exploring. This is exploring is a directed exploring. Not a wandering around looking for Unicorns in the forest. That is called a Snip Hunt. There is no Snip to hunt, but it's a fun thing to do for novice and naive tenderfoots in the scout pack or the business of spending other people's money. 
  • Data - what data will we need to develop to support our search for the answer to the Focus Question? Where would we  find this data? How will we be able to validate this data. Is this data personal anecdotes or is it from a principled framework that can be tested in the absence of the person providing  the data.
  • Claims & Evidence - when claims are made, is there any testable evidence of that data? And most importantly is there any testability that supports the Focus Question?
  • Reflection - with this process, what do we learn? Was there a prediction that could be tested - estimates are the smell of dysfunction? How would you test that conjecture? What would the predicted outcome of that Focus Question and Prediction in terms of measurable evidence? Do we have a Plan to explore that question - or are we  just going to wander around looking for that mythical Unicorn that will bring Rainbows and Sunshine to our project? Where is this data? How did we find it? Journal papers, books, actual data collected ourselves using good data analysis techniques - not the pesky Flaw of Averages approach, but an actual data collection process? For claim to be credible there needs to be evidence to support the claim.

So in the end if 2nd graders in Austin Texas can figure this out, why can't adults tasked with spending other people's money do this as well?

Related articles Everything I Learned About PM Came From a Elementary School Teacher Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management