Archive for May, 2018

One Throw-Away Product – Or Refactoring

Posted on: May 14th, 2018 by admin No Comments

I have been speaking at many PMI chapter events in North Carolina this year. I enjoy doing these events, meeting new people, discussing different and new things, and sometimes, being introduced to cool old things.  One such event was the PMI Asheville Chapter where I met some really interesting people including Eric W.

Mythical Man Month

Mythical Man Month



Eric is a software person, he writes code and in our conversation at the meeting (the topic was risk and risk management) it became clear he is also one of those that have been around software development for years. Shortly after that meeting I received a package via amazon from Eric W, the book, The Mythical Man Month.  This book is interesting for several reasons, not the least of which is it was written by a North Carolinian, or at least a professor at North Carolina University.

This is an old book, from the 1970’s and I am sorry to say, many of the issues or difficulties or things that go wrong with the general approach to software development are, well, not much different from those olden days.

Besides the observation of the typical failures, there is an interesting section of the book that explores the idea of one throw-away product from which we learn[1].  Upon reading this, I quickly though of the Agile concept of failing fast and learning from that failure, along with the concept of refactoring.

What I found interesting, or maybe a bit sad, is that this idea of disposable product iteration took years to even take hold.  Additionally, it seems like Agile is a recycle of the book to some degree, what was once referred to as build one to throw away, becomes refactoring.  There are many other similarities to agile in the book, and we will bring them in periodically into the blog.

Thank you Eric W for sending me this book. I am a voracious reader, and I cannot believe how long I have heard of this book, but had not read.


[1] Brooks, F. P. (2013). The mythical man-month essays on software engineering. Boston, MA: 115

Missing Requirements

Posted on: May 11th, 2018 by admin No Comments

Missing Requirements

Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray.

Wearing Many Hats

I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company.  This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.

Product Development Input

The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains.  However, the marketing person was essentially a customer advocate and not really an engineer.  In this instance, there will be some depending implications due to this limitation.


We had the objective of designing and delivering an industrial application that would meet the requirements, which consisted of a number of pieces of hardware that performed discrete measurements and as long as the variation on that sample were within a certain tolerance, the system would operate accordingly.  However, when that variation went beyond the allowable in any one of the sampling components (more than 100) the system would send a control signal that would stop the machine and flag the operator that an error had occurred as well as direct them to the specific failure point.

Oops, Something is Missing

We proceeded to develop the system performing incremental tests at various stage. This included testing the system on a small-scale equipment believed to be identical to that of the customer.  The trials were very successful, and the final delivery date is established and our manufacturing line at the begins work on producing the system.  The first prototype system is packed up and put on the loading dock for shipping.  In a casual conversation with the marketing manager, the manager mentions the actual type of system the prototype system will be installed upon is not what it was designed and tested.  I scratch my head by this revelation that the system is significantly different from what we designed the product, and the testing was not on that type of system as well.  I inform the marketing manager that the product will not work on the system she disclosed, that the variation in speed is too significant and will likely cause errant false failures.  However, knowing that humans are fallible I go to the other engineer that was also working on the system for his perspective, and he agree.  The system will not work.

Clean Up and Conclusion

What happens next is just cleaning up of the mess created by missing requirements. The system is shipped.  The two engineers visit the customer’s facility for a week and takes along portable soldering irons and a variety of equipment and components to see how the system works and tailor fit the product performance to meet the system to which it is installed.  This consumed many hours and a small measure of dissatisfaction from the customer.

So what is the lesson?  Well, in this case, to design the product to meet quickly meet this need would have been quite easy. The original requirements, had these mentioned the machine type, would have gone a long way to understanding the actual application, perhaps additional questions or perhaps discussions with the proposed client.

Let’s Dump the Product Demonstration – Because we are Agile.

Posted on: May 9th, 2018 by admin No Comments

It is clear to me that some people think an agile approach means you can willy-nilly delete things in the process. This is also true for conventional project, but I do not think for the same reasons. For conventional projects, it seems time pressures cause elimination of certain functions or processes to keep the schedule. For agile, again no study but based on observed discussions, the elimination seems to be because there is no doctrine or perceived process that is required to be adhered.  This means things can be arbitrarily altered or changed, or even eliminated. That is certainly true, but you must consider the consequences of not performing the activity (for example product demonstration)?  From my perspective, there is a balance between adherence to a process (repeatable and baseline for learning  ) and adapting to the circumstances.

What does this product demonstration do, can I eliminate it, and what will likely be the consequences?

For the record, I am not in favor of the above approach of eliminating the product demonstration. I cannot think of a scenario in which that would or could be the best approach, and believe the merits of performing are too high.

  1. confirm delivering the sprint objectives
  2. engage the product owner by evoking feedback on the design instantiation
  3. refine requirements for future work
  4. learn (brainstorm) more about the product with the product owner
  5. provide energy and a sense of progress and accomplishment
  6. demonstrate success

There are many ways for us to do the work and it is best to respond to the conditions on the ground.  Understand the reasons for doing something, and if you do not know why some process is part of your project or product development process, think about what goal that process or step is designed to accomplish.  Perhaps ask other team members. If you do not know why, that does not necessarily mean it should be deleted.  To understand more about processes and associated costs, check out our book on reducing costs.

Subscribe to our Newsletter

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