Just another hack?

MacGyver was a TV character placed in daunting situations with only his wits and a few simple items to save the day. According to a recent survey* the number one issue in product delivery today is unrealistic expectations – what is more unrealistic than MacGyver creating a defibrillator out of candlesticks, microphone cord, and rubber mat?

Near heroic efforts can often be required to develop and deploy products on time and budget.

The fact that we’re comparing product and software development teams to heroes does not mean that this is a positive situation. No organization should be happy with its product and development team using a heroic approach to succeed.

Sammy Larbi wrote an article “Rewarding Heroic Development Promotes Bad Behavior” in which he says:

“When developers have to stay up all night and code like zombies on a project that may very well be on a death march, you’ve got a problem, and it’s not solely that your project might fail. Even when that superheroic effort saves the project, you’ve still got at least three issues to consider:

– Was the business side too eager to get the project out the door?

– Are the developers so poor at estimating that it led to near-failure?

– Is there a failure of communication between the two sides?”

Are such heroic efforts sustainable?

I would rather not have my defibrillator made from candlesticks, microphone cord, and rubber mat. The issue with these heroic approaches to product and software development is that they are not sustainable over time. Eventually, the team will lack the motivation or key steps will get skipped to make the deadline. I’m pretty sure the FDA would not approve the MacGyver solution.

The more your industry is subject to controls and regulation the less likely a development process based upon heroism, “seat of the pants”, or “unnamed agile” will be a recipe for success. And by “unnamed agile” I do not mean those of you who are diligently following one of the flavors of agile – Scrum, Kanban, SAFe, etc. – but those who have told me they practice agile when, in fact, they have a minimal process yet have to put a name on whatever the heck they are doing.

As you can imagine I am in favor of enough process to meet your organization’s needs. Some organizations need more rigor and control due to the products they create – medical devices, automotive, and regulated IT like banking – while others may perform well with little formality.

One-piece at a time

What frightens me are organizations using process and tools right out of the Johnny Cash song “One Piece at a Time”. The song tells the story of a poor auto worker who over the years pilfered Cadillac parts and built a hodge-podge auto of his own. While the song and car are old, the concept is still being applied.

This car is far from safe or reliable, yet I see organizations piecing together both their product and software development approach as well as their toolchain – like the Cadillac pictured above.

Open Source has been an extremely valuable solution for product and software development for some time. It can, however, complicate the tool/process integration and negatively impact traceability, variant management, etc., if not appropriately planned.

Basic integration is launching one application from inside of another, or just passing simple messages between them. Though this level of integration is better than nothing, real integration benefits require leveraging a common infrastructure or common messaging framework, like OLSC for example.

Most development organizations have many tools from different places. This can create islands of information if not appropriately planned. Team unification can become difficult because building or maintaining interfaces can be time-consuming. New versions of the various tools require maintaining these integrations – a potential source of overhead and vulnerability. Individual point solutions, each with its information repository language and methodology, can make for a less than ideal solution.

Yet, tools are meant to help organizations simplify their software and product development by providing comprehensive communication among team members. Lack of integration and communication is a reason many software and product development efforts fail since the associated costs are typically higher than expected.

A fool with a tool is still a fool

My three-legged stool consists of education/training, process, and tools. Addressing less than three of these legs makes for an unstable base. As you go about developing, buying, implementing, or simply tweaking a leg of your stool, make sure you have all the legs considered.

The most successful development organizations I have seen combine what I call the three legs of the stool-based upon the needs of their business and organization. I’ve actively told prospective clients to not implement a tool until they figure out their product development approach – aka process – along with a plan for training and education for the associated tools and processes.

Don’t allow the tail to wag the dog

Combining the “heroism” development process with the “one piece at a time” toolchain and a lack of training is a recipe for missed commitments, rework, and cost overruns.

I am not suggesting that you implement everything from a single source or eschew open source solutions. I am suggesting that you look beyond individual tool features, or a solution solely based upon what is simple and easy to use. Understand what is necessary for your organization and industry. I’ve seen far too many “one piece at a time” solutions that require constant course correction or heroism to keep it on the pavement. Some of these process/tool abominations are organic, selected at different times by different groups in different organizations, and finally lumped together into something that approximates a development environment.

Plan an iterative implementation that addresses your biggest challenges first. Keep the good stuff that fits your plan and meets your needs. Selectively prune or add processes, tools, and training that improve your future outlook.

Don’t allow the tail to wag the dog and simply implement what is simple and easy, implement what is right and necessary for your organization – even in the face of headwinds.

* STATE OF SOFTWARE DEVELOPMENT IN 2019 – Coding Sans