Archive for December, 2015

Off Topic – Family

Posted on: December 30th, 2015 by admin 1 Comment

This blog is usually about technical topics and product development and learning focused. Today is different. Today I am going to write about something that has been on my mind for many weeks now, though I am not very good at expressing.  That uneasiness of expressing has contributed to my starting and stopping with this post.  However, given this time of year, and my many blessings, of which people are significant, I felt compelled to follow through.

In July of this year (2015), I was called by one of my high school friends and informed that his dad had died.  I have been thinking on this blog post since his death and the funeral at which I was a pall bearer.  I had not returned to where I grew up too frequently, in fact it has probably been more than a decade.  Life, work and other family obligations kept me from going home.  However, over the years my mind would wonder back to those days, often in the most unusual places.  I remember being in Gothenburg Sweden for my job. It was late at night, after work, and I was having dinner in a Chinese restaurant not far from the hotel.  As I ate, I noticed the music and it was James Taylor and I had an instant flashback of the many times I had been around a camp fire with my brothers, and more importantly and sadly, how staying in touch over some 35 years was inconsistent.

This was the last of the fathers of my best friends in high school to die.  It was the last of my fathers to pass.  I count myself fortunate indeed to have been a part these families growing up.  I will not discuss my family life only to say that all families, like individuals, are a combination of strengths and weaknesses. I was fortunate to be part of these families, as their strengths were not the same as my family and no doubt this has made a significant difference.  I would not like to think of a life in which these families did not take me in as their own, I learned much from my extended family, the Olive’s, and the Mendoza’s.   At no time did I ever feel like a friend, but something much greater, and even still today though many years have passed.  I owe them greatly for the many contributions they have made to my life that have allowed me to wend my way here.  Though genetically we could not prove related, we most assuredly are, and I am ever so grateful and blessed for being part of their family.

Emotional and Organizational Maturity

Posted on: December 21st, 2015 by admin No Comments


I have recently had an exchange with Thomas Cagley on LinkedIn in response to an article “The Agile Mindset“.  Comments around emotional and organizational maturity were made and Thomas Cagley asked the questions about which one comes first.

I said I think emotional maturity must come first.  Without the ability to handle the “real” situation, you are unable to understand and resolve those things related to organizational maturity.  You must emotionally be able to handle the present situation then think clearly and grow the organization and build (hiring, coaching, process improvement) the maturity in areas that are immature.  In this case, we are referring to how well we perform those technical aspects of the organization such as product testing, requirements and configuration management, project management and manufacturing to name a few.  You can find an example outlined extensively in the CMMI model.

My experience suggests people often want what they want when they want it. We do not realize there are often dependencies or prerequisites required to reach that “what we want” objective, or we do not want to recognize these limitations.  Sometimes this is referred to as delayed gratification.  Without emotional maturity, it is difficult to think clearly, learn, plan the moves and do the required work to be in a position to achieve those organizational maturity objectives.  This work I would submit is the act of improving our organization’s maturity but could not have happened without emotional maturity.

We have edited this post to include this paragraph.  We have found this article and believe it applies to organizations as well as training organizations. In fact, in our work should consist of some educational aspects, Shawn P Quigley and Jon M Quigley are working on a book that weds the organization’s work and learning.  So when we found this article we decided we should include this article from USATestPrep and a growth mindset.

Organizational maturity is our capability it is where we improve how we do the work that will allow us to reach our goals.  Our emotional maturity allows us to consider the situation as it presently exists, and think of ways to make the situation better rather than stomp around complaining about what is – yelling at team members, and demanding the impossible not just the improbable.  Without emotional maturity, we can ask our team members to jump to the moon and expect that to happen (improbable).  Without patience that comes with emotional maturity, we are unable to plan, grow our people and coach the team to the organizational maturity we need to remain competitive.

Time Boxing

Posted on: December 19th, 2015 by admin No Comments

Time boxed or time boxing is when we have a hard fixed time around the activity we are undertaking.  For example, we may decide that our team is allowed a fixed amount of time to plan or estimate.  A meeting has a fixed duration and done effectively an agenda that further breaks down the time into smaller increments directed at producing the results expected from the meeting. 

Time boxing puts pressure to answer the questions or address the topics under consideration quickly and effectively.  To paraphrase George S. Patton, A good plan quickly executed now is better than a perfect pan executed next week[1].  The term time boxing or “timebox methodology” for their iterative development is from Scott Shulz at Dupont[2].  In this historical context, time boxing referred to the development iteration envelope.  That is the time available for the developers to produce an instantiation of the product.  In the case of Scrum, that time is typically 2 weeks though can also be 4 weeks, and I have used 6 weeks for a series of sprints for a project.  The point is the duration does not change in spite of the situations that are presented to the project. Delivery is time / duration fixed, content is variable.

Time box is now also used to refer to any other part that is bound by time in agile.  Scrum daily sprint meetings are time boxed at typically 15 minutes.  Sprint planning, product demonstration and retrospective’s are likewise time boxed.  Time boxing then is a project time management mechanism shortening our planning event horizons by driving attention and focus.

Time boxing adds a measure of urgency as we are challenged to produce or solve the situation at hand within a finite amount of time.  Sometimes that time seems very small, so we must act efficiently and effectively.  Time boxing helps set the cadence or pace for the project.  We establish a sense of urgency and maintain a pulse of expectation for the team and the output.



[1] last accessed 12/18/2015

[2] Larman, C. (2004). Agile and iterative development: A manager’s guide (p. 87). Boston, MA: Addison-Wesley

Features and ROI

Posted on: December 17th, 2015 by admin No Comments

Features and Business Case

The last blog post was about how we justify the project and the business case from an agile perspective along with a study from The Standish Group.  The reason attaching the business case to the product backlog, or in the case of conventional project management specific requirements, is so we have a prioritization of the feature set that makes sense, specifically, connected to the value brought to the customer and by extrapolation to the organization.

Customer Features Use

In fact, the results of a study found in Agile & Iterative Development – A Manager’s Guide by Craig Larman shows that 45% of the features are never used. The graphic further details the actual use of features as illustrated below[1].


Customer Feature Use

Customer Feature Use


Value Equation and Feature Use

This means, the company took time, spent money and accepted additional risk to develop a feature that the customer will never use.  The cost incurred to develop features that are not used, must be covered by the product features used.  A simple equation for value is demonstrated below:


Rudimentary Value Calculation

Rudimentary Value Calculation


We see as the customer’s perceived benefits are based upon the feature content or how well the product meets their needs.  The cost is the product cost.  The product cost is based upon the material and labor cost, but also on the profit margins on the product the company must make to remain viable.  Features not used by the customer, are not valued by the customer and do not add to the PerceivedBenefits.  However, the Cost portion of the equation goes up based upon the money spent on developing additional features.  So the development of additional features is pointless and adds cost that the value proposition to the customer will not desire to support, thereby lowering the Value equation for the product.


Conclusion: Value, Features, and ROI

Using the ROI calculation to prioritize the individual features, whether for agile or for conventional projects is important as this streamlines the value proposition ensuring the best value to the customer and return on the investment for the company doing the development work.  As we can see, adding and paying for features not used erodes the value equation and that is not in the best interest of the customer or the company.

[1] Larman, C. (2004). Agile and iterative development: A manager’s guide (p. 57). Boston, MA: Addison-Wesley

Agile, Prioritization and ROI

Posted on: December 14th, 2015 by admin No Comments

Project Prioritization 

There are two levels of prioritization for agile. The first is the product backlog – the prioritization of the scope of the project.  The second prioritization is how we populate the sprint contents.  The top priority product backlog items are used for the decomposition for the sprint, but there may be prerequisites that must be included in the sprint; that are not specifically called out in the product backlog, technical prerequisites for example.

Return on Investment

Return on Investment



When it comes to the product backlog, cost and value determination there are at least two ways besides ignoring.  The first is more traditional look at the entire project costs compared with the return.  Using this approach we batch the estimated cost against the projected (also estimated) revenue generated.  

Agile and Prioritization

The second approach more agile friendly, and should be a significant input to the product backlog prioritization, is a more incremental approach. That is, instead of looking at the entire project, look at the cost and value for each requirement / user story and compare that to the estimated return or revenue generated (ROI).  That allows the product owner to prioritize the product backlog based upon the projected money brought back into the organization and the value of the product backlog item received by the customer, ensuring the team is working on those parts of the product that provide the greatest value.

Study of ROI and Requirements

This graphic below is from The Chaos Report 2015 from The Standish Group[1].  In this study of 300 companies, we see that 15% calculate for the overall project and then distribute that over the individual requirements, presumably based upon the estimated magnitude of the individual requirement. Only 14% calculate for each requirement and then sum that for the entire project. Those that take this approach will know the cost for the individual requirements which is the cost half of the equation.  At this point we need to understand the value to the customer (and by extrapolation our organization) and we will be sufficiently armed to answering priority questions.  

 estimate breakdown


The limits

The problem with the batch approach, whether you are using an agile approach or a conventional approach to the project, is the inability to prioritize the individual specific objectives.  In other words, we are unable to specifically and readily identify neither the value of nor the cost of each of the use cases or requirements.   Therefore, prioritization of the backlog and sprint are performed at a higher level of abstraction or based at least in part on intuition or subjective assessments.  The same would be true for conventional projects, we have not clear demarcation of the important parts of the project from lesser.  Subsequent blog will demonstrate this difficulty.


[1] The Standish Group International Inc. Chaos Report 2015 Modern Resolution For All Projects page 6


Study and Agile Implications

Posted on: December 9th, 2015 by admin No Comments

The Standish Group’s 2015 Chaos Report

I am pouring over the Standish Group’s 2015 issue of The Chaos Report.  I really enjoy reading and that covers a variety of topics.   Reading makes it possible to see things you would not normally be able to see, a glimpse of other perspectives, and sometimes it confirms what your experience tells you, and occasionally it flies in the face of what you think.

Success, Challenged and Failed

The latest Standish Group report details the percent of projects that are successful, challenged and failed and this includes agile.  This distribution has changed only moderately over the last five years.  That is, there have not been great and sustainable improvements over that interval.  I am not cognizant of the details of the data acquisition, and presume the companies in the study from 2011 are not necessarily the same companies in the 2015 version of the report.  I say this, because the distribution remains relatively unchanged, that is percent successful has not improved over time.  Experience suggests a company would put actions in place to improve the probability of success and over five years we would like to see a positive sloping trend line indicating an improving project success rate.  That does not match the reported data. 

The graphic below illustrates this variation over the years from The Standish Group’s 2015 Chaos Report[1].


Success, Challenged and Failed Projects over the Years

Success, Challenged and Failed Projects over the Years


Size Matters

The report also characterizes the performance of the project by sizes.  The results are interesting and mirror other articles and studies I have read in books that include software studies.  This also mirrors my personal experience as well.  There is an inverse relationship between the values provided by the project to the size of the project. Larger projects produce lower value.  This supports other studies and readings as well:

…research of many projects showed that 45% of features were not used – with an additional 19% rarely used[2]

Complexity also Matters

Larger projects, besides adding complexity add feature content and the value of that feature content for the customer is suspect when a feature is rarely used and an outright waste of effort for features that are never used.  I have worked for companies that would load up the project with all that can be attempted for a delivery.  Rather than do this, it would be better to prioritize the feature content based upon the value created.  Doing so for each feature allows the organization to apply resources to the best possible value for the customer and the organization.  This can have a significant positive impact on the company revenue since less, and on could argue, reckless spending on project attributes that bring no return.


I have used agile within a company that employs a stage gate type of project management.  Sometimes this is referred to as waterfall, but I have never seen a waterfall that matches the description generally given of it. That is, that we do all of one step before we move on to the next. For example, we do all of the requirements collecting and specification writing before we do the next step. I have never seen what is often referred to as waterfall applied to that extreme.  Therefore, I prefer to refer to that approach as stage gate, iterative and incremental deliveries mapped to project phases.  The study compares project execution methods of agile and waterfall.  The graphic below[3] comes directly from The Standish Group’s Chaos Report 2015.  


Agile compared to Waterfall

Agile compared to Waterfall


I am not a person to advocate one method of execution over another. To me it is selecting the correct approach for the objective and resources at hand.  However, after reviewing this report and numerous other similar findings, it is passed time to consider how we can improve the success rates of our projects.  Though none of my conventional project experience suggests a waterfall approach means all of one step before the next, it does suggest prioritization of scope of the project often does not happen.  

No matter the approach, fundamental project management and business techniques of qualifying the scope of the project are necessary.  Conventional project management also counsels this as well.  Agile does this particularly well qualifying the individual pieces that comprise the prioritized product backlog. In fact the ability to quickly reap the benefits of the work, monetarily, is part of the product backlog prioritization, though that need not be exclusive to agile.

[1] The Standish Group International Inc. Chaos Report 2015 Modern Resolution For All Projects page 2

[2] Larman, C. (2010). Agile and iterative development: A manager’s guide (12. printing. ed., p. 57). Boston u.a., MA: Addison-Wesley.

[3] The Standish Group International Inc. Chaos Report 2015 Modern Resolution For All Projects page 7

WBS Dictionary and Agile Definition of Done

Posted on: December 5th, 2015 by admin No Comments


Personally, I find connecting what I already know to some new thing I am learning facilitates and understanding of that new thing.  We have frequently compared agile and conventional project management on our blog, for example, Epic Project Management Battle: Retrospective vs. White Book.  Today we are going to compare the WBS dictionary with the Agile Definition of Done.

WBS Dictionary

To understand the WBS Dictionary we should probably start with the WBS or Work Breakdown Structure.  This is the decomposed scope to a list of things that must happen to deliver to the scope and project objective.  This decomposition is used to help establish the workflow, areas of responsibility and to estimate the cost of the project.  The WBS is a list of identifiers or names for each item or portion of the project.  There is no context or constraints with just the identifying word. That is the gap which the WBS dictionary will close, as it describes the acceptable or expected outcome for that item identifying what success for that item would look like.  Using just the WBS name, nearly anything could be proposed as meeting the expectation.  This definition quantifies and qualifies the item facilitating a common understanding of completeness for the WBS item as a comparison.

Definition of Done

In agile, we do not have a WBS, but we will likely have user stories.  These user stories provide a description of the user and their exchange with the product defining the objective for the team and the sprint.  The definition of done provides enough detail to the user story, a documentation of the common understanding between the team and the customer what completeness looks like – what success looks like.


There are fewer differences than we may think between conventional project management and agile.   That is not to say these are identical, but that knowing each of the artifacts or approaches,  makes it possible to assess the situation and make rational decisions on the appropriate approach.  If we have to, we can make up other ways to achieve the objectives, crafting our tack based upon the logic of the situation and risks.

Learning and The Unasked Question

Posted on: December 4th, 2015 by admin No Comments

By Shawn P. Quigley

If you have read any of our blog post you know that Value Transformation bases itself in an Organizational Developmental and Learning Organizational model. If you have not read any of our posts then we would suggest that you take a few moments and look through a few: The Leadership Equation, Office Politics, Communication, and External Drivers are just a few we would suggest. We have also developed a training course about Project Management and Learning Organizational principals. To keep in line with this model we are looking for your suggestions on what you would like to see in these training arenas. This is sponsored by the theory of an open mental model which is; as we have alluded to in our blog post, one of the pillars, if not the bedrock of both a learning organization and organizational development.

                It is the open and honest exchange of information that allows both individuals and organizations to determine their actual position in development.  It is this “true” starting point that allows for the determination of the direction that both individuals and organizations need to go. Tension can be defined as the difference between where someone “thinks” they are and where they think they should be. It is this tension that drives the desire of change. However, if the change starts from a false point it will likely end in a location that is not desired – if it does land where you want it is likely largely luck. Having said these things we again would request that you provide us with some topics for our elearning site that you believe will help you and your organization to grow.

Commodity or Talent

Posted on: December 3rd, 2015 by admin No Comments

First of all, I hate the word human resources for our employees.  This verbiage starts the discussion as if people were fungible.  That people, their talents, aspirations, motivation and capability are identical. That is simply not true.

 I just got out of a discussion with a company that left me feeling hopeful.  After working in a company that appeared to be unable to differentiate commodity from the knowledge area or discipline of the employee, this was refreshing.  It was wonderful to hear a company that seems to really value the employee and the skills and talents they bring to the work.

 In this discussion, situations were described where the company would make quick changes to make it possible to acquire talent, and other instances where they would delay making a decision since they could not find the right talent. In the case where delays happened, they did not lose the budget for the talent acquisition because they could not find that right person within some prescribed time, which sometimes happens in companies.  When the budget is threatened with cutting due to time and not finding the correct talent, we accept a level of talent that we perhaps should not.

 It is encouraging to see a company that truly appears to value getting the right talent into the company.  We should not begin to make our talent happy, as they start to leave the company – sorry we have mistreated or ignored them and wish for them to stay.  A relationship does not begin as somebody is walking out.  It starts even before being hired and works all throughout the employment with the company.  Talent is a big competitive advantage for the company. Those skills, motivation, creativity, and competencies the team members bring to the organization is make the difference.


Agile and Synchronized Work

Posted on: December 2nd, 2015 by admin No Comments

Simultaneous work and an Agile Approach

There are ways to divide the work up using an agile approach.  This can get complicated for distributed teams but for teams that are on the same site the challenge is greatly reduced.

We once worked on an embedded development project for an electronic control unit on a vehicle. Actually, we have done that on numerous occasions,  however, this was an instance we did things radically different. 

The Product

This project required specifications be written that described the specific system interactions of this electronic control unit and the others on the vehicle.  There are many embedded components on the vehicle all connected together through a number of serial data links.   The product was complex and configurable for many applications.  The specifications defined the expected systems interactions, failure modes (possible system failures and expected responses) as well as fall back modes if the product had an internal failure as well as parameter driven configuration settings. For example, in some vehicles the input data may originate from a sensor directly connected to the embedded component, in other types of vehicles the input may come from one of any of the data links.  There were more than 120 specifications that would need to be written.

Specification and Development Parallel

The tight schedule and available talent meant that it would not be possible to run the project using the company’s typical approach.  It is just not a workable solution to until the specifications were complete before starting to develop the product.  The company employed an iterative approach to the development, but the iterations previously were on a larger scale.  There was no time for that approach.

In this project, in the early 2000’s, and the company or the people working there had not heard of agile.  We decided to employ a just in time approach to the specification building and product development in general.  The list was prioritized by critical feature to be able to operate the vehicle, making complete vehicle integration and testing possible. 

 The Teams

There were two teams, a small group of system knowledgeable to create the specifications or the product based upon the prioritized list.  The first team produced specifications just in time for the development and testing of the product.  This is an example of pipelining iterations[1] of the work.  In this case, the specifications were written and reviewed using and agile like approach, and delivered just in front on the development work which also took on an agile flair.


Breaking the work into two Agile teams

Breaking the work into two Agile teams


Two-way information sharing

Each subsequent development and test loop produced questions regarding the specifications.  The graphic does not show this interaction though it was significant. After the first set of specifications, the developers and testers would have questions to gain a better understanding of the expected behavior.  Those questions were answered in real time by those that worked in the specifications.  There was plenty of informal communication between specification team and the development and test team as they were all collocated.  Those questions generated refinements in the specifications (subsequent iterations) developing the product and the specifications not exactly simultaneously but certainly in parallel.


There are many ways to meet the objectives of the project.  It all begins with the talent and motivation of the team, coupled with the willingness to adapt to the circumstances and balancing objectives – not capitulation and corner cutting.  My experience is corner cutting seems to solve the problem now, but creates many more issues at the future date.

[1] Larman, C. (2004). Agile and Iterative Development: A manager’s guide (p. 251). Boston, MA: Addison-Wesley.

Subscribe to our Newsletter

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