Top Tags

  • All Tags 0

Add 3 Simple Metrics to Show What Your Burndown Chart is Not Showing

Jun 16, 14 10:47 PM

Every scrum master has created a Burn Down chart by hand at some point in their career. If you haven’t, or hadn’t in a while I highly recommend you do just to re-acquaint yourself with not only how you do it but, why you are doing it. What I have often found in working with peers who are using automated tools is that it has become a ceremonious act with only one purpose. The manager wants it so, you create it.  If this is why you are creating charts then it’s time to hit the reset button on that way of thinking.

I like pictures, images, or charts that move me from a resting state of mind to an actionable, transformative state of being. There’s a tacit understanding that takes place when data strikes a chord in you. So, why create a Burn Down chart that does nothing other than to serve the purpose of being another ‘information only’ chart in a Power Point presentation? Let’s create something that rallies the troops!

There are metrics you can add to a Burn Down chart that are great for starting a conversation with your product/program manager about your team. or team of teams. By the end of this article, you will see that it’s not how much you burn it’s the quality of the burn. You will also be able to answer the question, “What is holding us back from delivering more?”, in a chart that everyone is familiar with.

Now, I know that most of you are seasoned professionals and some of you might be tuning out right about now. Heck, you can speak from your gut about what is holding your team back why isn’t it obvious to everyone else? In part, you are right and that’s a good starting point. But the reality is that working from instinct only is not compelling enough without data. With these suggested enhancements to a simple Burn Down chart you can not only show what is happening and why impacts overall team productivity, you can discuss the issues with management and take action. It may well be all you needed to get the support you need to overcome what I refer to as a  ‘productivity plateau’. Teams committed to agile best practices will agree with the following:

Every team member that is not constantly reassessing and learning how to increase productivity is on a plateau and doesn’t know it.

Shining a light on that plateau is often enlightening and empowering to a team and it’s members.

First, let’s look at a standard Burn Down chart:

basic burn down chart

For the sake of  this discussion we will use the same data. Here we see story points on the left vertical axis and time on the horizontal axis.

We can see that this team rarely hit its planned cadence. From looking at this can you tell what happened?

Now let’s add a some thinking to the chart.

1). Technical debt is nothing new. In a Burn Down chart however, it can give us insight into the ebb and flow of the debt and helps explain why we are not as productive as we could be. The list of done vs. undone work that leads to technical debt can be quite extensive. Here are some typical ones:

  • Requirements / Data Analysis
  • Design
  • Dependency Analysis
  • Refactoring
  • Stability testing
  • Performance testing
  • Integration and implementation coordination with the work of other teams
  • Release notes
  • Regression testing
  • Code reviews

If any of the above are left undone then you can expect a good amount of technical debt  to carry over plus a high likeliness for defects to pop up in your next sprint.  The definition of done is all about completeness with quality. This is something I learned on working for my father’s construction company. If my dad came on a job site and saw work that wasn’t completed with high quality he would have the crew do it again, He would then tell the crew that if they did a sloppy, low quality but quick job it would require more time and money to do it over again than if they had taken the time to do it right the first time. A worker on one job once said to him that he couldn’t guarantee he could deliver that all the time since he was new to the work. My dad pulled him aside and told him, “It’s not that you can’t do it right, it’s that you don’t know how to do it right. So, I’m going to show you how.”.  Then, my dad would proceed to show him and his crew how. If after being shown how to do it right these folks still did a sloppy job they were paired with someone as their mentor.

2. Defects. Also not new. Let’s see how many and when they are happening.

3. Daily points completed. Seeing this metric helps a team better understand and gauge their productivity especially when compared to the other charted variables.

Here’s what the above chart looks like with 3 new data sets:

Sprint A Burndown Update

Technical debt is the gray line that  undulates throughout the project. It aligns with the right vertical axis. The ups and downs are a drag anchor on your productivity potential. The blue line is the defect count and also aligns with the right axis. The green bars along the bottom are the daily points completed.  We can now see more clearly how technical debt and defects can tamp down productivity in terms of daily points completed. In essence, the team has ‘plateaued’. Every day the team spends churning on technical debt and defect management is another day of lost potential. The lesson is that you might hit the velocity you planned but is there a stretch goal you just can’t quite hit? Perhaps, it’s time to dig deeper.

Here’s the data for all of the Burn Down Charts:

DATA Sprint A with 0 defects and High TD

What about when you do not clean up all of your technical debt and defects in a sprint?

Here’s what that looks like:

Sprint B BurnDown Update

DATA Sprint B Update

Now, we’ve got trouble brewing for the next sprint. Technical debt and defects are spilling over and the team is starting to get frustrated with the amount of work they have to accomplish. Sound familiar? How does your team address this? What do you proactively do to prevent or, mitigate this? In my next article I will show how we can enhance a Burn Up chart to help in catching issues early on!

Note: If you would like a copy of the chart in Excel to work with please write me – adjust the data to the way your team works and how your management  measures teamwork. 

Leave a comment

A problem is a gap that exists between a concrete reality and a desired outcome that is time bound. The Great Disconnect – Part 2

May 8, 14 11:04 PM

Has a critical part of your project ever gone awry due to a team members inability to deliver consistent, reliable, quality output. a  resource manager ever made you promises on behalf of their team, they can’t possibly keep? Ever had a management team ask a single team member for an estimate for a particular piece of functionality that required multiple inputs from many sources? What typically happens next is that the estimate which was not vetted becomes fixed and the team that has to do the work becomes disillusioned.

The weakest link on your team is the one that thinks it’s OK to hide their flaws from the rest of the team that is depending on them. Certainly, there is the benefit of doubt when it’s the first time that it happens, but if it is not addressed you will often see it happen again. Giving someone the benefit of the doubt repeatedly combined with a lack of empathy for the ones that are impacted is just another way for team dysfunction to persist. In essence, you create a promisory performative in the hope that the future might be more productive if viewed this way.

Problems can take many forms, show up in the oddest places, but always at the wrong time. It’s that part that most people forget – the time bound factor that makes a problem “special”.  How many problems you face depends upon how many solutions to problems you are capable of handling or not.  Dependent on time and how you solve for it, one problem can be nearly impossible to manage when there too many weak links in the process of delivering a solution. The Titanic comes to mind. For others one problem a minute is the norm’. A customer service representative comes to mind.

One could argue that one doesn’t deserve the problems one is confronting. That may be true, but what are you going to do about it? One thing I have learned is that when you don’t solve a problem you are facing the first time you are confronted with it you get an automatic ticket to that very same problem again and again.  So, you have problems to solve? Well, after you’ve blown off a little steam go take another  look at the problems you are facing and get to work on solutions. Reach out to your mentors and peers for assistance. You will quickly find that you are not the only one who has ever encountered the problems you are facing. Think of it this way, if you find that your peers have all encountered a problem similar to yours and have come out the other side then you were the weakest link in your circle of peers with respect to being a problem solver. Your peers will respect you for coming forward and you will learn how to be a better problem solver.

Leave a comment

Who’s Going To Pay For This? The Great Disconnect – Part 1

Nov 14, 13 7:30 PM

How many projects have you worked on where, before the project has even kicked off or, started sprinting, everyone from mid-level management to the developers, UX engineers , scrum masters. project managers and BA/SA and QA analysts are asking “who’s funding this?” It’s almost always followed by “If no one is funding this we shouldn’t or can’t work on it.” I applaud good project budget management embraced by a team. The timing and the audience is what concerns me. There appears to be a growing disconnect between understanding what is and isn’t a real program or project and it’s stalling team progress. I believe the problem can be solved by turning the budget planning over to the working team members. Managements role would be to mentor and guide the the ones who have to commit to the work on how to prepare a budget plan.

Avoid making a bad budget plan everyone’s problem by involving the resources who do the work (a development team for example) that can learn how to create a budget plan. They will manage to their own plan better than someone else’s. The team members involved should be capable of delivering quality work. There is no real gain in trickling down the inner working of the budget process to all of the working team members. You have to strike a balance while also not relying on your ‘gut’ too much.

What’s happening now?

Budgeting is done by only senior level management. The team members see a final budget number later after a list of new work is published.

Considering that the ability to estimate can be further eroded by policies that undermine the process of budgeting resource managers are trying to manage to, one could say that the accuracy workers hours of allocation in a budgeting tool are mostly intuition with a little luck thrown in.

There are a myriad of reasons as to why this is happening. Here’s a typical scenario in seven steps:

1)a senior manager has five team managers each with 5 employees

2)the sr. mgr. must ensure that all of his team managers are allocating all of their employees at 100% capacity.

3)since most projects cannot keep one person on them @100% allocation, the 5 team managers spread each employee across multiple projects with the goal of achieving 100% assigned to budgeted work.

4)fast forward to project planning – the scrum master takes the backlog and starts the sprint planning with the team.

5)the individual team members are asked to give their high level effort estimations for the tasks they are going to work on.

6)team members ask for a budget code to bill to which shows an allocation that was established with no prior knowledge of the work.

7)the project begins and the budget is now being tracked against numbers based on deploying resources to meet a 100% allocation requirement found nowhere in the effort based estimation of the work.

In this scenario, you can clearly see how the allocation of budget is completely disconnected from the effort estimated by the team members. Before your company ‘digs’ into effort estimation numbers and tries to make a one to one connection by tying it back to the budget there’s a couple of caveats you might want to share with them.

There is hope. Early planning by the team members that will be doing the work in collaboration with the budget planning process is a viable option to consider. In fact, it will build earlier commitment to a project since the team was a part of the actual budget estimation. The tools we have today can aid in the collaboration process. Currently, most companies do not leverage or include the right people, process or, the tools to achieve better budget planning results.

Leave a comment

No One Here Gets Out Alive

Jul 24, 13 4:01 AM

A highly functional team knows each others strengths and weaknesses. Over the years, I have watched many teams and bright individuals follow processes that were more akin to a Rube Goldberg without questioning each other, the creators of the process or even their management. It’s always the same reason. We are taught to avoid conflict to stay out of trouble. Drawing attention to ourselves is not good business acumen.  While in most situations that can be true, avoiding healthy conflict is a sure way to stifle positive change, creativity and innovation for the good of all. Not knowing what should be addressed (“know which battles are the right ones” as one great mentor I had once told me)  simply to avoid all conflict actually encourages unhealthy conflict. Let’s explore the single most important asset you have when  trying to solve a problem. People are your most important asset.

Therefore, the bottom line to fixing a big problem is to be tough on the problem, not the team or the people.

A good process, a great set of rules or guidelines, can aide in binding new teams together and advance team productivity. Bad ones can too if the team is already highly functional. However, it cannot accelerate productivity on its own.  It’s an “all in” (or, fall short of the goal) commitment. What makes bad processes, rules or, guidelines worse? When they are at their core a disincentive to follow let alone commit to.

How do you make a necessary process worth using with a new or,  highly functional team? Let’s presume that incentive (the “carrot”) is the approach we will take, not disincentive tactics (the “stick” i.e. “do it, or else”).  If a process already exists, you can apply the same “all in” approach with the people who will be using it by diving into and understanding the data collected from different feedback channels.  For example, monitoring metrics on how many times a process flow is followed. When a workflow begins is it; a) 100% complete/correct,b) partially complete/correct, or c) incorrectly applied. Additional metrics such as where in the flow was the process subverted and why?  When was it not used altogether? Talking to a random sample of users whom you have collected metrics on to understand the data also puts it into the context needed to fully grasp the problems within a process.

The best way to capture the essence of what’s going on is to commit to the whole process not just a part of it. Unsurprisingly, there are no shortcuts to gaining proper insight.  What’s surprising  is that once a new process is launched in the name of continuous improvement,  ownership is disbanded. The application of Deming’s principle A Constancy of Purpose used temporarily is like washing your hands only when you think it’s a good idea.

When you are working with a new or highly dysfunctional team,  it can  feel like you’re watching a relay race of runners without a baton. The people on the team forget that the ‘baton’ is the process not them. They act independently of the actual goal of a team moving a baton forward as quickly as possible for the best possible outcome. The total amount of time and  money it takes to complete the entire task or, provide meaningful information as to where the baton is, is not a concern by anyone on the team. Then, there are those who “know the rules” of the game who are often more interested in pedantic catechism than in rendering an actual service. The absence of team spirit and customer advocacy (two things that make the baton real) becomes palpable when people use a process to absolve themselves of accountability to the whole purpose of what is supposed to be accomplished. What they have forgotten is that they unwittingly malign a company’s name and reputation more than their own when they do this.

So, if you find yourself bogged down by  a process or on a team that’s less than desirable, remember that no one here gets out alive. Meaning, make the most of what you have, while you have it. Success that comes with knowing that you have tried your best is carpe minutam more so than carpe diem. You’ll know who your peers are by how well they function when nothing is going as planned. Theses are the ones you can count on. The other ones, the ones that turn on each other need to know that they count on you and others like you to show them how to rise to the challenge. These are the ones that know the right baton for each sprint, by following the process and carrying on.

Leave a comment

One metric you should consider for showing how quality pays for itself

Oct 8, 12 7:18 PM

Processes improvement initiatives everywhere and not a single measurement to explain them.

How many slide decks have you seen where the cost savings shown seem more hypothetical and unrealistic than reality? I got into the habit of creating a folder in my mail inbox labeled ‘PIFMA’ which stands for ‘pulled it from my a$$’.

My rule of thumb is, if you can’t carry it forward into a working model using a standard measurement checklist (the result of answering a series of measurement review questions) then you’re either guessing, or you carry a lot of implicit knowledge and believe you are an SME, aka the informed guesser, or perhaps,  you carry a lot of weight and no one challenges your numbers out of fear.

I prefer to start with good old fashioned heuristics and clear and concise KPI’s that have been baselined by them. Does it take more would than whipping up a bunch of fluff numbers? Yes! Unlike fluff numbers, is it more reliable and capable of building an economically fundable model that can withstand the test of time, scope and quality? Yes!

Here’s one metric that I have used when creating executive slide decks for CIO’s, CTO’s and COO’s to secure funding and then putting into practical use with a team to be measured by.

Defect removal costs per function point

Let’s say, I wanted to make sure a team was focused on the defect removal costs per function point and not the cost per defect metric. My conversations central theme is that I want to prove that with quality built into a product early I can substantially lower the cost per defect. How would I talk a team through this?

Assume, all defect removal operations have a significant quantity of fixed costs associated with them. It follows that, as the number of defects reported declines, the cost per defect must rise. It is reasonable to argue that cost per defect is not valid for serious economic analysis because every downstream activity will have a higher cost per defect than upstream activities. Therefore, it’s important that discussion around measurement stays focused on the right metric.

Example:

I have a software application that contains 100 function points. During each of my quality assurance processes the software will go through three consecutive test stages, each of which will test 50 percent of the function points. Writing the test cases for each test stage costs $1,000. Running the tests for each stage costs $1,000. Fixing each discovered defect costs $100. What is the economics of the three test stages?

In the first test stage, the costs were $1,000 for writing test cases, $1,000 for running test cases, and $5,000 for fixing 50 defects, or $7,000 in all. The “Defect removal costs per function point” for test stage 1 would be $70. Consider, there were 50 function points tested out of 100 total function points. This amounts to $140 per test.

In the second test stage, the costs were $1,000 for writing test cases, $1,000 for running test cases, and $2,500 for fixing 25 defects, or $4,500 in all. The “Defect removal costs per function point” for test stage 2 would be $45. Considering there are now 25 function points tested out of the remaining 50 the cost is $180 per test.

In the third test stage, the costs were $1,000 for writing test cases, $1,000 for running test cases, and $1,200 for fixing 12 defects, or $3,200 in all. The “Defect removal costs per function point” for test stage 3 would be $32. With only 12 tests remaining the cost jumps to $267 per test.

As can be seen from this example, the fixed costs of writing and running test cases tend to drive up the later per test costs at each stage even where few defects are found. However the cost of defect removal per function point decreases.

That is a metric you should consider for measurement. Granted, it’s only one – there are and can be many more – but, this is where you can start the conversation that drives home the main point of your discussions central theme.

Note: One could argue that defect cost does not rise because resource costs are fixed. Therefore, defect removal costs remain the same no matter which environment or stage the defect was found in. Considering how many more resources are involved in the removal of a defect as it migrates through your ecosystem and not forgetting the potentially irreparable damage caused by defects found by your customers it’s not as easy to dismiss the metric I am proposing. Granted, you should always be rigorous in your metric assumptions, consider other models, calculations and provide real examples that apply to your projections. The design of your experiment must be suited to your situation.

Leave a comment

Review, Approve, Verify – Part 2 – Right Approach, Applied Correctly

Oct 7, 12 6:45 PM

It’s been going on since the first tool was made. Since the first process was created companies have been trying on catchy names in the name of improving what is, into what could be better. Today, a corporation attempting to achieve qualitative and quantitative change to either make themselves more lean, shorten their sales cycle is a sure way to add to profits. How do you know if your are succeeding in changing organizational culture or behavior, lowering the cost of doing business, eliminating duplication of common services, or even creating new markets from current intellectual property, or patents or products without the right people, processes and tools? There have been numerous books written on re-engineering the corporation, transformational leadership and change. Enter the words ‘transforming an organization’ into an advanced Google search and thousands of  will pop up. Imagine, for moment that each book contains a unique aspect on the approach and when it’s appropriate to apply it. That would imply that we have thousands of  ‘right approaches’ and we need to know which one is the right one to apply in each situation when transforming an organization.

Transformation is a way to qualitative and quantitative change what’s not, or could be working better for a company, and companies are clearly looking for guidance from professionals who can help them. Rarely, do publishers publish what does not sell.

So, how does any of this relate to review, approve, and verify? Those three words put into practice have the ability to transform your organization.

There may be some reading this that believe there is a ‘one size fits all’ approach to delivery quality processes. Solving problems is as simple as creating one, simple flow chart, prescribing it to a plethora of challenges and the rest will solve itself. In the long run leadership at companies looking to transform need to ask themselves if they would prefer a doctor who prescribes for them the same medicine dispensed to all patients without  fully understanding or offering professional guidance regarding not only what ails them, but what caused what ails them and how to get on a road to recovery?

There are four quadrants that you should be conscious of when choosing a quality process and deciding how to go about implementing it shown here:

Right Approach, Applied Incorrectly(Message is on key people ‘get’ what the process is, it’s the delivery mechanism/forum that is off-base). Your processes and leadership (a person or team) is in place, however; a groupthink mindset due to a lack of sustained momentum and low quantitative and qualitative data exists. This is a ‘I understand it, we do things differently here or, I just do what I am told’ mentality. Right Approach, Applied Correctly(The right message, delivered the right way)Processes and leadership with the ability to sustain momentum has encouraged and mentored a framework that nurtures and sustains qualitative and quantitative data that is vital to building a continuously aware, transformational organization.
Wrong Approach, Applied Incorrectly( Message is incorrect or, makes the process appear more opaque than it already was and the delivery mechanism/ forum are both inappropriate)It’s an “every man for himself” attitude coming from most team members nearly all the time. Data that is available is meaningless because the processes that allow for the collection of data is flawed, transformation is unthinkable. This is the “Why should I care about this?” Or,  “how is this connected to my work?” Wrong Approach, Applied Correctly(The message is incorrect, addresses partial goals, and has adverse effects even though the delivery mechanism/forum was appropriate)There is no sustained leadership. Sadly, the teams’ awareness of the ever changing approach and application with each new manager’s spin on following ritual will merely reaffirm their attitude to slog through the project more or less, to stay in sync or, out of trouble with the middle managers goals while losing sight of overall quality. This sustains mediocrity.

In the next post I’ll talk about metrics that matter.

Leave a comment

Review, Approve, Verify – Part 1 – How necessary is quality to your bottom line?

Sep 30, 12 11:27 PM

Think about quality programs (if any) where you work. It might not surprise you to find that the quality is looked down on or thought of as a nuisance by some management or, perhaps not thought of as a continuous process. For quite a few of you it’s more likely that quality is thought of as more of a given, or it can be found only your branding, or your slogan or is associated with a piece of technology or machinery! Did you ever wonder why this is? Very few companies know how or, have the tools to master the concepts or transform them into a working, sustainable model for success. By tools, I do not necessarily mean a software product or automation tools though, it doesn’t hurt to invest in these things. If you do decide to do this, consider reading my upcoming chapter  on putting people before process and tools first!

In the 1980’s the Ford Motor company advertised the quality was job 1. That was their slogan. However, if that’s all there was to it then this would be a “see what happens when you don’t commit to quality?” discussion about not following through which would essentially make this blog a rant – and it is not that at all.

Ford did make quality job 1 and by the time Harold “Red” Poling (the CEO who made quality a priority) retired Ford had 5 of the top 10 best-selling, highest quality rated cars in the US.  What’s important to note here is that the road to quality was not the easy road to take. It included the closing of 8 plants, and reducing the automobile line up. It meant that a car with quality issues would not be sold to the public until all of the issues were resolved. Ford paid close attention to the details that mattered to their customers and it won their loyalty back and they went from burning $2bn a year in 1980 to profitable by 1983.

With the quality programs implemented Ford not only emphasized cost reduction and flexibility but also ergonomics. The improvement of the working environment (Maloney, 1994; Witt, 1995) made a difference in ways beyond the obvious ways one could easily guess. Ford workers not only suffered less fatigue they had higher morale. It change their attitude towards their work! So, improvements in the quality of physical comfort and work environment boosted morale. The kind of reenergized mindset that leaves your employees wanting to make great products for you. So, let’s put a new twist on the  belief that corporations are people. If corporations are people then Ford is the kind of person you want as an employer and a friend. Feeling good about the inner circle of friends you keep can go a long way.

Walk around a company where the morale is low and I guarantee the products or service they are putting into the marketplace are lower quality than the workplace with high employee morale. In fact, many investment firms send their top stock picking portfolio analysts to do exactly that. If you have ever watched Bloomberg TV you will hear one or more mentions to this in interviews about a company’s potential and products and whether or they are good investment or not.

“Our data show that customers who are highly satisfied remain loyal,” says
Louise Goeser, Ford’s vice president of quality. “In fact, one and a half points
of customer satisfaction drive about one point more loyalty. In North America
alone, this translates into more than $2 billion in incremental revenue and
roughly $100 million in profit.”

Today, quality at Ford continues to be rated highly for quality, customer satisfaction and loyalty with its cutomers and high company morale. They’ve managed to remain adaptive and responsive while executing their quality initiatives because they have mastered the ability to break up complex issues through direct and oblique responses and initiatives into uncomplicated, solvable actions items. Some of these actions had immediate payoff and others are paying back dividends over time. Ford understood they needed both.

Where does you company stand with regards to the necessity of quality? If you asked that question to your manager and then asked “Can you show me how we measure quality?” or,  “Can you show me an instance when we stopped a development project to address quality concerns?” what was the answer? If it was something like “Oh, we have 3 pre-prod environments, a DR and a prod-fix environment to cover all kinds of quality issues”  in fact, any sentence that has the word “quality” followed by the word “issues” should be a big billowy red flag. There’s a good chance your company has made quality an assumption.

Even the ones who embrace quality sometimes falter. Ford’s lesson is a continuous one. They continue to learn how to improve and adapt as they go. The point is, not only does Ford recognize they will never be done improving they also know that anything they had done well is fair game to be criticized , torn down and rebuilt if it means better quality.

An assumptive statement to the effect of “quality is gift that we the employer demand instantaneous receipt of, because we have hired the smartest people and bought the most expensive tools” should neither be stated directly or implied in any business vision statement or, in any employees contract of employment. Everyone at Ford from the owners to the line managers knows they have to bring out the best in their people first before anyone delivers the level of quality that improves the processes that directly and indirectly improve the products that impact the bottom line. A committment to quality is necessary, real and lasting.

Leave a comment

Ready for an informal review?

Jul 17, 12 6:43 PM

There are times when you are absolutely certain that what you’ve written or coded is ready for a formal review or release. When you are certain about the artifacts contents, or its impact on the overall process is very low it’s a safe bet to publish and worry about the minutia later. Then, there are those critical artifacts that you might want to consider having informally reviewed by your peers because it does impact others or a critical process. Starting with an informal review will build your confidence in writing great requirements while it also builds additional team core strength.

An easy way to determine whether or not you need to have an informal review is to answer the following multipart question:

Is the unit of work under my span of control complete, such that I know I can

A)Hand it off to other teams to begin working on it without injecting defects into their work flow?

B)Pass a formal review in its current state with some minor tweaks?

If you strive to answer yes to all parts of this question then you are not only demonstrating your understanding of the assigned task, you are also fully committed to taking responsibility of the quality of the work. When you are proficient at this make it a practice to coach and mentor your peers accordingly. Note: being proficient does not mean answering yes to all of the question all of the time.

In my experience I have met many people who can answer yes to only one of the two completely, a few who can answer both the rare genius or a fools optimist . If you are wondering how to tell the difference the fool is the person who can say yes no matter what the facts are.

Leave a comment

Review, Approve,Verify

Jul 12, 12 4:16 PM

How important is it to get it right the first time?

In nature, species evolve over eons. It’s important to note that with changes gained there is always something lost. Nature often has a way of letting go of what is no longer necessary. That too, also takes a very long time. Everything around us is in the natural world is proof positive of a loosely coupled review, approve and verification process.

“The fossil record implies trial and error, the inability to anticipate the future, features inconsistent with a Great Designer (though not a Designer of a more remote and indirect temperament.)” ― Carl Sagan, Cosmos

Imagine, for a moment, what the dollar cost would be if one were to begin a program with the objective of creating homo sapiens starting with single-celled organisms? Carl Sagan had it right when he suggested a “… Designer of a more remote and indirect temperament.”

I have yet to meet a business partner, CFO, CEO, or a CIO with that kind of patience! In the software development world we strive to get it right the first time. Money is the usually the motivating factor that is used to start quality improvement programs. Expectations are then set to unachievable levels causing a failure to launch sustainable quality practices.

While it’s a certainty that the dollars saved from quality improvement initiatives should and will not be ignored, it is also important that money should not be the main focus. When it comes to problem solving, money is not the most compelling reason for changing the way things are. In fact, money often  stagnates clear thinking, logical thought and creative processes of innovation and change. It often gets you temporary results that do not stand the test of time. To be really good at review, approve and verification you have to be really good at staying focused on innovation and change.

Note to leaders who just read that and thought, “Good to know, let’s start a new quality improvement organization with zero budget and or, resources, leave the rest of the organization well-funded and disinterested and see what we get!” A bad, if not silly (by which I mean, really silly) idea.

In my next few blogs I am going to discuss the known and hidden benefits derived as a result of following lean six sigma review, approve and verify series of workflows that you can build into your current SDLC process.

Comments (1)