Planning for Change – A Strategy

We've Got You Covered

A major contributing factor in my early enjoyment of software development was that I was fortunate enough to build systems for a multitude of different businesses and sectors. I loved (and still do love) getting deeply involved with the details of a completely new industry, immerse myself in the client’s business processes and jargon, join them in their struggles, and of course, get excited with them in their successes.

Through all this, one of the greatest and hardest lessons I had to learn was how to adapt to both positive and negative changes within a project and/or business.

And then, I had to learn to not just manage it, but rather to relish it, and even predict it.

The past few years at Yellowtail Software have been noteworthy for the number of times we’ve had to put this skill into practice. As such, I thought it would be a good opportunity to share a few strategies that we’ve found very effective. While the focus is on Software Architecture, these strategies tend to sometimes drift into Analysis and Project Management too, but I do believe most of them will be valuable to anyone involved in the production of software for a business.

#1 - Make a Great Lexicon

This won’t surprise many readers, but communication is the core of the first key point. Looking specifically at dealing with a particularly “fluid” project, carefully managing the how of communication can bring much needed structure when the ground appears to be moving beneath one’s feet.

One Glossary, One Language…
Agree on terminology that is plain, unambiguous, and accurate. It must work for the entire team. That includes your colleagues and your clients (who may well be non-technical), and should last the entire duration of the project.
In distributed teams, be even stricter on this. At Yellowtail Software, the majority of our projects have dealt with at least 2 languages, often more (the team and stakeholders are often from 3 or more different countries and cultures, many of whom don’t have English as their first language. Furthermore, the product itself often needs to support multiple end user languages).

Abstract everything to generic terms, appropriate for your project.
Be especially wary when integrating to external tools or systems. Using their terminology inside your project, if it is not generic or appropriate, can cause massive confusion should that component need to be switched out for another, at a later date.

Change terminology to reflect changes.
Don’t be afraid of replacing or renaming terminology that is no longer perfectly accurate, due to project changes.
Badly chosen terminology is evident when terms are frequently confused with other, similar terms, leading to frustrated communication. Even more insidious is the terminology that “leads the mind” into incorrect thinking, or early assumptions. Do not underestimate the likelihood of this happening, and speak up at the first signs.

#2 - SOLID beats Fluidity

From a developer perspective, Modular and Decoupled design is quite probably the single most important strategy to employ. In particular, the ability to both build temporary test or “mock” modules in-place, and the ability to replace modules at will, and at any point, gives unparalleled agility in the development process. Rigorous adherence to SOLID principles, and careful forethought in these areas have given us countless wins here at Yellowtail Software, and saved us and our clients many sleepless nights.

Don’t Negotiate on Modular, Decoupled Design.
Architected properly, this allows for remarkably quick swapping of components that are chosen late, or replaced.
Furthermore, as anybody familiar with any of the Test Driven approaches will no doubt recognise, it creates the opportunity for “Mocking” up temporary modules (in place of the real functionality or 3rd party integration point) to allow development to continue, as well as proof-of-concepts, and partial testing.
From a design and front-end point of view, a great example here would be the value of carefully planned HTML layouts and CSS. (I’ve yet to work on a project where either of these remain static throughout the development phases, so well thought out, future-proof structures here are paramount.)

“Fail Early”, but also, “Evolve Early”
Aim for fast & frequent releases (“just testable”), to allow and prompt the changes (and failures) to happen as early as possible.
Remember: “failing early” applies as much to low level technical issues and bugs, as it does to major conceptual issues with the business or business concept.
You can demonstrate to your stakeholders early on your flexibility, easy adaptability, and deep insight. This removes fear, builds trust, and allows creativity.

#3 - Zen and the Art of Scope Maintenance

The core message here is that one should get as deeply familiar with the “true purpose” of the project and its environment, and the aims of the client, so that one can intelligently advise, and efficiently plan, to best be equipped for inevitable changes. At Yellowtail Software, we see one of our core strengths as being able to assist in refining and distilling requirements into achievable delivery plans, often through a phased approach. We normally start by identifying the Minimum Viable Product, in collaboration with the client. And then, we…..

Challenge the MVP
Apply “sixth sense” (or “experience”, whichever you have ) to the stated MVP items, to identify which ones really, really need to be the MVP items.
It is important to have a full, contextual, and nuanced understanding of the roadmap and the business goals, and then blend that into the technical possibilities and technical challenges.
Try identify which features seem a little less certain or bedded down, and pay extra attention to modularising these. The higher the likelihood of change, the better potential value from great decoupling.
For each feature, critically analyse and challenge its fundamental importance to the business, versus the urgency of its inclusion. (Tip: those two measurements can differ wildly)

Don’t Just Plan Ahead, also Work Ahead
Be proactive! Identify which “future” items could be built now for almost no effort, and then argue for inclusion (or preparation). This can be worthwhile if it brings nett value in subsequent phases or releases. (You can always disable or hide features in first release if appropriate)
This strategy applies very well to both front-end design, and to back end coding and architecture. Always be thinking “how will this need to change when feature XYZ comes in to play?”. Consider proactively scaffolding your models to be able to adequately deal with known future extensions.
Those readers familiar with the YAGNI principle might gasp at these seemingly contradictory suggestions…However, there is a healthy and creative tension created by the two different approaches. If one really digs deep into the philosophies, one quickly finds that they complement each other in addressing the same topic.

Read Between the Lines
Take note of uncertainty, and look for any hints or clues to the same. Often, you can discover areas (say, in 3rd party choices/agreements) that are still debateable, and these can benefit from extra care or even slight delay in implementation, at least until more certainty is reached.
Understand the clients true “absolutes”: many clients have made many choices on technology, patterns/standards, 3rd party agreements etc, but not all of these are set in stone. It is important to find this out, as YOU often have 3 key advantages that your client might not:
Expertise - as the expert on the topic, you have a mind-set based on a different experience, and have the best insight into the impacts and risks associated with particular choices. Remember, what seems easy to your client might be really tricky for you… and vice versa.
A fresh pair of eyes – simply being an “outsider”, you might be able to provide better alternatives (more appropriate, cheaper, easier/quicker to implement, etc)
Blinkers - Its unpleasant to even bring up, but the reality is that tech and scope choices seldom exist in a vacuum, devoid of emotional, historical, and political pressures within the client organisation. At all times, remain sensitive to the possibility that these exist, but never forget that your primary responsibility is to advise in the most honest and clear way possible. Who knows? An outsider’s opinion (seemingly without bias or agenda or conflict of interest) might be all that is required to allow a new perspective to even be entertained, and perhaps avert a mini disaster. If it sounds dramatic, it is. But it’s also not unheard of.

#4 – Recycling the Waste

Up till now we’ve discussed several tangible techniques that assist both the technical and the management side of running a successful software project in a highly fluid environment. But how do we manage to keep calm and objective in the midst of all this change? How do we feel with the ever present risk of a feeling of “Wasted Effort” when things change? How do we turn “waste” into something positive?

Keep a Light Grip
To the “Deciders”: be sensitive to the mental and emotional energy that has gone into delivering a section of a project. Don’t underestimate the attachment and accomplishment that may have gone into it. Dashing this feeling too many times can easily lead to a degradation over time to one’s sense of ownership, which is deadly to a project. Also, warn about these possibilities ahead of time, if at all possible. Be realistic in your expectations when delivering the news, and requesting feedback on the impact.
To the “Creators”: there is a certain art to taking ownership of something, but holding on to it lightly. Focus on the process and experience and journey, rather than the individual, iterative outputs. Look for the positives in the experience, be clear and honest about the impact this will have on the project, and be positive and proactive in looking for the best way to move forward. The “deciders” are probably equally upset or surprised, but have the added stress of figuring out how to recover from wasted investment. Be open minded, and creative with solutions to minimise the impact. Help them.

Recycling?
As a professional investigating 3rd parties (whether for tooling, suppliers, vendors, etc), treat every interaction as longer-term than the immediate project. Every investigation into a product is a success, even if not chosen.
In a recent project, I had to do legwork on a massive number of providers and vendors, in a multitude of different spaces (a conservative estimate of 30 independent options involving rigorous investigation, beyond the initial screening number). There were several I chose with great confidence, that were rejected by our client (for reasons I sometimes understood, and sometimes didn’t). In some cases, we developed and built for weeks or months against a chosen product, only for it to be removed with little to no warning. In all of these, however, I had to remember to always learn as much as I could about their offering and their competitors.
New clients of Yellowtail Software have since benefited directly from the time we spent doing research, making new contacts, prototyping, and experimenting. What might have been seen as “waste” by many, has effectively been recycled into something valuable.

In Summary

By consciously utilising these strategies, we have enjoyed many benefits to our productivity, and positivity of outlook. Our clients have therefore benefitted equally (if not more so) in being able to adapt quickly to internal and external forces, as we have greatly lessened the impact to their IT project. While the results might not always be externally noticeable, you can be assured there will always be positive effects.

And, in some cases, our clients have even enjoyed surprising benefits beyond their initial hopes, arising out of urgent circumstances requiring “unforeseen” changes to the project. It is highly rewarding and encouraging to be able to bring reassurance to a concerned client (and team) in these situations, and simply say “Don’t worry, we’ve got you covered.”

(first published: http://www.yellowtailsoftware.co.za/2018/05/15/planning-for-change-strategy/)