Archive for August, 2014

Agile Verification – Iterations and Bug Tracking

Posted on: August 29th, 2014 by admin No Comments

Agile Verification Blog Recollection

In our past blog posts we discussed a conventionally executed (staged gate) project with constituent parts (the verification) being executed using agile techniques. We realized we missed some pertinent information in our series post of agile verification in a conventional project.

Agile Verification Prediction

We talked about the burn up chart based upon the estimated number of hours / days required to verify the entire system. Additionally, we illustrated the tracking of the faults found during the work.

We failed to adequately demonstrate the loops or iterations of the sprints, as there were multiple iterations of this agile verification  activities for this project. This organization practices incremental and iterative product development even if the organization employs stage gate project management mechanisms.


Fault tracking over agile verification sprint iterations.

Fault tracking over agile verification sprint iterations.

Not only do we monitor the rate of execution per test loop, but we also track the issues found during the testing of the iterations. We are also able monitor the rate of defects witnessed across iterations. The sum of the faults found in the iteration is then tracked so we see how the product matures.  The first prototype (Proto 1) is actually a few iterations of small builds. Starting with the second prototype, the 6 week sprint duration is employed.  Prior to that, the scope was handled the same way (list did not change) but there was no time window identified.

Organizational Learning – Team and Management

Posted on: August 28th, 2014 by admin 2 Comments

Organizational Learning Differences for the Team and Management

(Mental Models)

By Shawn P. Quigley

In a previous post, we discussed the five principles behind Organizational Learning (L.O.). In this post, we will discuss how the different levels of an organization view the principles and why these different views make it difficult to obtain a learning organization. We will divide an organization into two levels; worker and management. As we have previously discussed perception does not change reality, but it does change how we respond to it. With that, lets’ begin our discussion.

Mental Models

Mental model or as we have previously called it the open mental model is the topic for this discussion. As we have previously stated an open mental model is the action of continually clarifying and improving upon our perspective of a situation or environment. This requires that we listen to the positive and negative perspectives of others and weigh how those perspectives can applied to clarify or improve our own perspectives. If that we not challenging enough there is another part to the application of the open mental model, position within an organization. It should be all too evident that where you stand determines what you are seeing and what you see shapes your perspective on everything.

Team and Management Perspectives

The position of a worker is obviously a subordinate role to that of management. It is this position that commonly hinders an individual from providing or even approaching a management team member with a perspective that differs from what they see as the management’s perspective. In some cases, this concern of possibly challenging the perspective of management can become so ingrained in an individual that even larger issues go unreported until something dramatic occurs. How does a worker overcome this dilemma? Usually they do not and if they do, they become fearful that their position is in jeopardy. This concern about having an open dialogue is often referred to as office politics by the individual harboring the concern.  So how is this dilemma overcome by the worker? It cannot be done solely by them. This requires an environmental change by the management team. This environmental change to promote useful and open dialogue can only occur from the top down if it is to succeed.

Team has No Fear of Reprisals

That brings us to the management team’s role in fostering an open mental model. The irony of why some members of the management team do not promote this environment is that they also are concerned about their position of power. This is to mean that if a manager were to allow his/her employees to modify his/her perspective. What would happen next? Would the employee replace the manager? What most managers fail to realize is that one of their purposes is to facilitate their personnel to grow and develop. Without this constant development of their employees, management team members themselves will not be able to advance. So actually promoting an environment where an open mental model can flourish aids employee, manager and employer.

Organization Environment

In summary, the first step to having an environment where an organization can reap the benefits of an open mental model requires trust in people’s desire to better themselves and the organization. With establishing a good method for sharing perspectives within an organization, some of the concerns of negative results can be minimized. Thus aiding in the development of the desired state of openness and sharing of perspectives. However, as stated previously the first set toward this goal must come from the management team and it must be supported honestly.

Agile and Monitor and Control

Posted on: August 26th, 2014 by admin No Comments

With Agile, Every Day is a Review Day

The constant reviews of status of the project activities via daily Agile sprint meeting, provides the mechanism for the latest state of the project.  This includes the scrum master and product owner apprised of the situation.  I like the analogy of a pilot making course corrections. If the pilot waits until significant part of the trip is concluded before measuring where they are, a vacation trip to someplace warm can end up in someplace really cold.  These daily discussions also help ferret out the risks to the project as well, specifically, the question regarding impediments.  An impediment is an obstacle to our objective and therefore it is a risk.  This constant directing of the team attention to the immediate task at hand and measuring is the exact opposite of distraction.

Agile and Stakeholder Management

Unlike in conventional projects where the sponsor of the project informs the team of what they want and then runs off, agile puts demands on the product owner to participate.  This scripted inclusion of the stakeholder is helpful as any question the team may have regarding implementation is more readily answerable.

The Hype / Myth of Multitasking

One of the downsides of conventional projects can be the lack of focus. Seldom will we see daily meetings to monitor progress in conventional projects. In fact, this type of monitoring will only happen when the project is in a bad state.  Daily meetings to discuss status after we are already way behind do little to help as once the project is late – it is late.  Conventional projects also can distract the team by presenting a constant barrage of work upon which the individuals must focus as the individual may carry multiple roles within a project.  Experience also suggests, we diffuse the capability of the team member by assigning them to multiple projects.  Long periods between monitoring and multiple projects make hyper focus on the immediate task at hand for a specific project all but impossible.  Couple this with cell phones, YouTube, nonproductive but required meetings and the myriad of other daily obstacles, and it is easy to see why projects fail.

Multitasking is not something to be lauded.  This is one of the biggest damages to productivity and creativity in my opinion.  It is at times necessary, perhaps, however the long term negative consequences are much worse than any small benefit.

Scrum a Business Management Tool

Posted on: August 25th, 2014 by admin No Comments

The following text is the Preface to Scrum Project Management written by Kim H Pries and Jon M Quigley and published by CRC Press from Boca Raton Florida published in 2011


Agile Book

Scrum Project Management Shows how to Apply for other than Software Projects


Product development is becoming ever more complex. The pace of technological change is ever increasing, leaving little time to accumulate expertise before development of a particular product is to start.  Acquiring enough experience to be able to predict the risk, and the courses of action during the development is difficult and often happens in the course of the live fire of the development project. This creates a need taping into all of the players in the development effort and relying less on the heroic figure to save the day and carry the project and product to a successful conclusion. Even when there is a heroic figure, and he does carry the day, the organizations loss of this individual will be detrimental to the organization. The recovery period could be quite long.

We are presenting a modified version of the agile software development tool Scrum as an alternative to traditional program management and even as a tool for standard line management. Both of us have experience deploying and implementing the tool. We understand the pitfalls, which we will illuminate during the course of this book.
This is not to say that we believe the waterfall approach is condemned to obscurity or that we are calling for the death of this model. In fact, we know of very few organizations that take the waterfall method as it is often portrayed in books as a very rigid and one-way pass through the development process. In fact, there are some similarities between the methods, although scrum approach throughput can be much quicker and keeps people focused upon what is deemed important by the project. Additionally, the team aspects of the method – moving toward self-directed work teams, means the actions the team need to be successful are largely in the teams hands. Of course, this means you must have a motivated and skilled team to achieve. It is not possible to condemn the conventional tactics across the board, when frequently the conventional tactics are not executed well. Poor execution does not improve the possibility of delivering a quality product no matter the model or method of execution.

We like to call this style of getting things done “high-intensity management.” We demand and we see acceleration of tempo, focused completion of tasks, and improvement in project backlogs like we have never seen before. With one example, we were able to drop a production test equipment (automated test equipment) organization projects list from sixty items to thirty items to twenty items in less than three months! We had never been able to achieve these kinds of results until we implemented the relevant portions of the scrum approach to accomplishment.

For some time now, organizations have been attempting to empower the employees. Some organizations have moved to self directed work based teams.  This means pushing down much of the decision and execution aspects of organization. In his book, Leading Self-Directed Work Teams, Kimball Fisher provides a comparative list of attributes for self-directed work teams and the traditional organization[1].  Scrum puts the control of how the product gets produced, in the hands of the individuals responsible for delivery. This is within the confines of the organizations philosophies and constraints.

Empowerment = f(Authority, Resources, Information, Accountability)

Empowerment = 0, if Authority = 0; or Resources = 0; or Information=0; or Accountability = 0

Fisher takes the word empowerment from being a business buzzword and puts some meat on it. He also makes it clear what factors must be available for empowerment to take place.


[1] Kimball Fishser, Leading Self-Directed Work Teams (New York, NY; McGraw Hill, 1993) page 14

Conventional and Agile Project

Posted on: August 23rd, 2014 by admin 1 Comment

Conventional Project

The previous two blogs demonstrated a way to employ agile techniques. At the top level the project was executed as a conventional project.  The project had gates, a steering committee and numerous schedule layers.  The organizational structure is balanced matrix (for the most part).  The organization is distributed both by function and geographic region.  The verification team discussed in the previous blogs, received components, both software and hardware. The hardware consisted of embedded parts as well as purely electrical, for example wire harness.

Collection of Sub Projects

The conventional project was responsible to deliver a new vehicle to the manufacturing facility.  This includes many smaller projects to deliver numerous of sub-assemblies that comprise the entirety of the system.  All of these sub-projects delivering these components follow the gates of the top level project.  That includes the agile like executed portions of the project.

A delivery to Conventional Project – Testing Results

The function area for the work was the verification and test group that is responsible for the sub-assembly and systems integration verification activities. The scope of the verification was larger than that illustrated on the graphics.  Specifically the company builds many iterations and permutations of the product and testing all instantiations to exhaustion is not possible.  The team had hardware and software in the loop tools as well as specialty fixtures to test sub-assemblies and the system. That includes testing on the end system, which in this case includes vehicles.

Large Projects are Really a Collection of Projects

In the end it is possible to view a large project as a collection of smaller projects, and in fact though the schedule, milestones and gate reviews may set the pace, it is possible to approach the specific contiguous area of scope as a unique project. Not unique in the sense of a stand alone project but unique in manner of execution that will most probably yield success.  I have heard the debate, agile is better than conventional project management.  Do not buy into that hype or way of thinking. The real answer is, it is not that simple, and it depends. It is possible to select the correct approach for the type of work and the assets available to the team (namely talent) and the risks associated.  It is also possible to mix attributes of these two approaches to produce other was to deliver the project objectives.

Agile Practices Applied to Line Management – Monitor

Posted on: August 22nd, 2014 by admin No Comments

Situation Review

From our earlier blog post, we have a road map that resembles an agile burn down (inverse) chart for our expected rate of test case accomplishment. We are tracking our actual rate of accomplishment toward this expected rate.  These only help us understand the rate of accomplishment and an expected conclusion date of the test case execution. This does not inform us in any way about the quality of the product and the system, but we have a way of adding that.

Defect Arrival

As we execute the test cases, we will likely find failures. These failures or faults will be reported into a reporting system that will allow us to track the failure resolution.  We can also use that here in our progress tracking sheet. Ultimately we want to learn two things – one is the expected conclusion date of the testing, and most important predict (in as much as that is possible) the quality of the system / product that is being tested. We can do this by adding a second scale to the progress tracking for the defect or fault reporting.

“Sprint” Meeting

Each morning, the team assembles in a meeting. This is a short meeting that follows and agile protocol.  The scrum master (line manager) asks the three questions of the team.  The team individually responds, reporting any problem with their ability to execute as well as any severe defects. Those defects are discussed and subsequently entered into the fault tracking system.  The number of test cases executed are also discussed to assess rate of progress.   The quick meeting is dismissed, and the team updates their respective portions of the tracking sheet that records the progress being made. The scrum master (line manager) will compile and add the defect arrival rate to the rate graphic.  This documentation (illustrated and discussed below) will be delivered daily to the conventionally executed project.

All About the Metrics

The graphic below illustrates the number of faults reported for each day’s worth of work.  In our testing we have a four-tiered fault points.  Not all faults generate the same response. Some are minor blemishes that may not be much of an issue. Some are serious performance issues in which a customer will not be happy.  Some can be catastrophic that are breach regulations or cause safety concerns.  For this reason, we break down the faults in a way that provides us with a snapshot of the defect arrival rate by severity and are able to make some statements about the system or product.


Progress of Test Case Execution and Faults Found

Progress of Test Case Execution and Faults Found

In the above example, we can see that after about 30% of the work accomplished, we see 14 faults reported.  Of those 14 faults reported, we see 6 of them are serious and require attention.  Yet we are only 30% of the way through our verification. What can we glean from that?

Well, one thing we can surmise – is that the remaining 70% will almost assuredly have problems and some of those problems will likely be of the top severity.  Knowing this allows our project management function to begin adjusting expectations of the stakeholders.  Tracking this over iterations informs the project manager and key stakeholders how the product is progressing.


With some creativity, line managers can employ the tactics of agile to improve throughput and enable clear articulation of testing progress. If your organization employs conventional project management techniques, there are still ways to benefit from agile concepts.  It is possible to use the concept even in a conventional project for example.  In this case, the testing for this project is treated as a sub-project and the planning and monitoring and control show a close resemblance to agile techniques. There were many iterations of the system in this project and these tools helped the speed and articulation of the progress beyond the immediate team.

Test cases may not be the “be all end all” of the verification world.  To be sure there are tests that are not documented as test case against requirements such as exploratory testing. However, neither are test cases against requirements trivial.  We can learn much about the product by a diligent and methodical approach to the testing and one element of that approach is the test case.


Agile Practices Applied to Line Management – Planning

Posted on: August 20th, 2014 by admin No Comments

Agile in Conventional Project Line Management

The following is a story from a couple of years back.  The story is about lengthy set of verification activities (multiple iterations) in a large conventionally run project.  As many a test engineer will relate, testing is always cramped for time. Meaning, the time we want the answers is much less than the time required getting those answers. This project was not different.  I have experience in agile and have used these tools in other project capacities.  However, this was a large project of which I was responsible for the verification group’s activities.  I am a line manager (in this instance the agile role more like a scrum master) in a matrix organization so the verification team members of the project report to me as well as the project manager.

Scope of Work

The first step is to identify the scope of the work.  We found all of the implicated specifications and identified all requirements within those specifications that are impacted. The team collaboratively identifies and assigns test cases (self directed work team another agile aspect). This sheet (columns omitted due to size) also has a column for the individual’s to report the progress (number of test cases completed per specification). This team progress reporting will be compiled and compared to a target daily.  We will end up using that later in the project and in subsequent blog.  The items are prioritized by how critical.  High priority are vehicle safety systems, and operational systems (vehicle must have to legally be on the road) next convenience features.  Analogous to the prioritized sprint backlog.

All of the requirements in the system are identified with peoples names to test.

All of the requirements in the system are identified with peoples names to test.


Progress Tracking Resembles Agile

I recognize the company’s need to have the verification progress as quickly as possible while conveying the progress to the next level of management.  To make this a simple view I chose to use a agile-like mechanism (analogous to the burn down chart). In this case, it is percent completion of the total test cases to the total to be performed. I had started out with actual test case number on the left vertical axis.  This line was generated by an “estimate” of the number of test cases per day per individual testing.

This sheet tracks the progress made by the team against the target so we can assess.

This sheet tracks the progress made by the team against the target so we can assess.

This provides a nice map of the expected or planned rate of accomplishment over a period of time. The number of test cases to be executed is a few thousand, hence the number of days to conclude.

You can see this fills a similar role to a burn down chart when it comes to progress tracking. The chart is the estimated amount of time (subtracting weekends) to perform the work, over the work week of the number of people available. In this case, the entire scope of the work needed to be accomplished in one setting so it was not possible to use 2-4 weeks. So we have a plan based upon the scope of the work (number of test cases), that is also connected to the available talent and their hours. Very similar to an agile project burn down chart except instead of a decreasing of the available hours, it is the sum of the hours taken against the expected hours to complete.

Agile in the Midst of a Conventional Project

Posted on: August 18th, 2014 by admin No Comments

Agile Applied to Verification

Agile practices can apply to more than just project management approach, or even only to agile projects.  The techniques can help line management functions or used in subsections of projects that are otherwise conventionally developed and executed.  In the next series of blog posts, we will show how these techniques used in the successful delivery of the verification activities of a large conventionally executed project.  In fact, this company only employed conventional project techniques in their operation.

I bring this story to light since I have received many questions (in classes and speaking events) on how to use agile when the company already is entrenched in conventional project management.  Of course, there are many ways to make that happen, none of which involve over night.  However, I hope this story makes it easier to see how this transition can happen and without executive edict.

Application of Agile Techniques

We should be on the look out for any opportunity to make our conventional project management better, that includes borrowing a few items from agile practice.  For example, nowhere does the project manager get counsel to leave the team alone, not talking to them on a daily basis.  Consider for example, the Hawthorne effect or observer effect.  Both of these suggest that the simple process of observing changes the situation.  While the Hawthorn effect has some questions on the validity, many more questions remain from the study[1].

The original data have since been re-analysed, and it is not so clear whether the original results hold up. Nevertheless, the concept has been established – the very fact that people are under study, observation or investigation can have an effect on them and the results.”
(Earl-Slater, 2002)

If the simple act of participating or showing an interest in the team members contribution can change the outcome, is it not prudent to take that participation seriously?  Perhaps the daily sprint meetings are a large contribution to the success of agile.  At any rate, any of the techniques from agile deemed beneficial, easily port over to conventional projects.  Just as this string of blog posts show how agile fits within a conventional project, so too can the techniques fit conventional projects.

Conflict or Problem and the Learning Organization

Posted on: August 7th, 2014 by admin 1 Comment

What is the meaning of conflict and problem?

Let us start our discussion today with a few definitions of the words “Conflict” and “Problem”. There are so many definitions and we needed a common starting point to allow for an informative discourse.

Conflict is defined by Merriam-Webster as:

“A struggle for power, property, etc., strong disagreement between people, groups, etc., that results in often angry argument, and a difference that prevents agreement: disagreement between ideas, feelings, etc.” (Merriam-Webster “Conflict”)

The book Creative Approaches to Problem Solving describes a Conflict as:

“This factor deals with the presence of personal and emotional tension in the organization, and it is the only dimension that does not contribute positively to creativity.” (Isaksen, Treffinger, & Dorval, 2011)(pg.189)

Problem is defined by Merriam-Webster as:

“Something that is difficult to deal with: something that is a source of trouble, worry, etc., difficulty understanding something, and a feeling of not liking or wanting to do something.” (Merriam-Webster “Problem”)

The book Creative Approaches to Problem Solving describes Problem Solving as:

“A process of closing the gap between what is and what is desired”. (Isaksen, Treffinger, & Dorval, 2011)(pg.19)

Problems can produce conflict

From the definitions above, we can draw a simple conclusion that conflicts have an emotional overtone and a problem is merely the tension between an actual situation and the desired situation or end state. Having said that we can also conclude that conflicts rarely just arise, they usually start as a problem and become a conflict due to the manner in which they were (or not) resolved. Also, knowing that we cannot devoid ourselves from emotion, some problems will inevitably become conflicts solely due to their nature or may seem to be a conflict due to the initial emotional response by one if not all parties.

The Learning Organization’s Approach

A learning organization will view a problem or conflict as an opportunity to analyze or analyze its’ perspective of their current position or state against the desire position or state. Several of our previous discussions have touched on the topic of perspectives.  We have shown how this influences the direction of an organization. This continual evaluation by the organization of itself is an example of the theory of double loop learning by Chris Arygris and Schon.

Double Loop Learing

Double Loop Learing

 (Schon & Argyris)

We have briefly discussed why problems and conflicts can be seen as beneficial. Now we can look into ways a learning organization would help in handling them. To do this effectively we must remember both problems and conflicts provide us an opportunity for growth and development.

Not all problems or conflicts can be solved amicably. If we approach a problem with an open mental model, the possibility of inadvertently escalating to a conflict is reduced.  The premise of the mental model is continual evaluation of our perspective of the actual state of our organization and us. To do this we must create an environment that allows others to share their perspective(s).  This does not mean that we are required to agree with them, but we should analyze what they are offering. It is not enough that we listen to their perspective, but we must understand the why(s) behind them.

This will aid us in our systems thinking as it will afford us the opportunity to see the system interrelations from another’s perspective. This seeking to understand another individual’s perspective creates a positive experience for both parties. In our discussion of the leadership equation, we saw how providing a positive experience has a dramatic effect on individual behavior. The effect of providing an individual with positive experiences should decrease the emotional aspect of newly developing issues and help them feel a sense of shared vision; another L.O. principal. Additionally, having a shared vision will promote ownership of problems, which will in turn promote the individual to seek a solution that betters the entire system. This will demote conflicts to the problem level through the lessening of the personal emotional aspects of a conflict. The reduction of the emotional aspect will then in turn afford an easier dialogue between parties thus starting the cycle at a better state in future instances.


While all of this makes conflict resolution and problem solving sound simple we all know there is more to this topic. However, this discussion merely focuses on how conflicts and problems; when handled using some of the principals of a learning organization, can provide growth for both the individual and the organization. In later discussions, we will address other aspects of opportunities presented by conflicts and problems when handled through learning organizational.


Isaksen, S. G., Treffinger, D. J., & Dorval, K. B. (2011). Creative Approaches to Problem Solving, A Framework for Innovation and Change. In S. G. Isaksen, D. J. Treffinger, & K. B. Dorval, Creative Approaches to Problem Solving, A Framework for Innovation and Change (p. 291). Los Angeles, CA.: Sage.

Merriam-Webster “Conflict”. (n.d.). Retrieved August 4, 2014, from Merriam-Webster:

Merriam-Webster “Problem”. (n.d.). Retrieved August 4, 2014, from Merriam-Webster:

Schon, & Argyris, C. (n.d.). Double Loop Learning. Retrieved August 4, 2014, from Double Loop Learning: Argyris & Schon:

Right Manufacturing

Posted on: August 4th, 2014 by admin No Comments

Successful product development requires, ultimately, the delivery through manufacturing. After all, we are most likely for profit entity, and even if we were not for profit, in our effort to maximize our resource usage we should act as if we were a for profit.  Specifically, we do not squander our available resources. 

Mass production has many approaches, depending upon quality desired, and volume of parts to be produced as well as product and development cost constraints.  Selecting a manufacturer with a variety of possibilities is important, as it is then possible to explore the most promising method for the production run of this product.  Cultivating a relationship with such a supplier, makes it possible to bring your developed product to fruition quickly, and expediently to market.  It is not in your best interest to wait or stand idle. One such example of this type of supplier found at:

 We will write more about these alternatives in subsequent blogs.

Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO