The world of software development is said to be intangible but it’s also organic, frequently changing and adapting to the context: our clients’ demands. This concept tends to scare companies as they must readapt to these winds of change, whether it’s just an industry whim or a new solution to a problem.

When this happens the company’s ideal position would be to drive the change, to force the environment and competitors to adapt to the new found innovation. But the most common role is to go with the flow in a prepared and professional manner. Why the most common? Because the first rule is to understand that every company that works in the development of software products, will never be the king in every aspect of the game. Some other company may one day be the pioneer, and king will have to stop neglecting the change and sketch a plan for adaptation. There will be co-dependence between those who are ruling the market (kings) and those who must adapt to the ruler. Not even huge companies like Google or Facebook can maintain innovation, so they rely on their employees to grow accustomed to evolving rapidly and, even better, to change at a steady pace.

There are a number of common situations of adaptation gone wrong that are important:

The forever ongoing technology solution:

It doesn’t exist. To be fair, it’s possible to find entire sets of applications written in old programming languages like COBOL that don’t need to conform to the changes suffered by the environment, but these are outliers among the cloud of existent software products and must be treated like that. Most software products need modifications to guarantee their survival.

Recruitment for software jobs is a very difficult process. Sometimes it’s a pain to get the exact profile that matches both the position requirements and client expectations, but it’s a pain we must endure. There is a new trend in which technology decisions are made having this problem in consideration. To be even clearer, they tie the design of the applications to the forecast of the market so that finding candidates would be easier. There are so many levels where this is a wrong move, but the worst one is that organizations should expect employees to be as bold and adaptable as the product they work on. From another perspective, a software engineer stays on a job from 3 to 5 years and one of the reasons they switch jobs is the lack of challenges, so freezing the technology stack in behalf of recruitment is not an option.

The solution to a forever adaptable solution is to shape the product as many times as required to satisfy the clients’ needs. Being agile is also preferable.

Resistance is futile:

Working with agile is one of the ways to guarantee that an organization goes along with changes, adopting new team practices and learning different approaches to problems and solutions. It’s not a panacea but a more down to earth strategy towards software development and many other practices as well. But there is a big difference in being agile and just having daily meetings.

Yes, a team must be able to communicate regularly but there is more to it, the transformation should be cultural. As the Agile Manifesto states:

“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Individuals and interactions over processes and tools. Some teams depend way too much on tools, even spending effort in finding a proper digital tool that goes along with their needs when sometimes, a simple pen and paper suffices. Some other teams disregard tools and focus on interactions, on endless meetings that go off track, where you can hear details of problems that are not related to all the team members, task assignment, individuals with strong egos, etc.

Working software over comprehensive documentation. Waterfall methodologies for software development used to center on documentation while the “agile way” dictates short-cycle times with multiple deliveries and ongoing adaptable documentation. The benefit of this strategy is that it moves software more rapidly into production, which at the same time benefits from client interaction and feedback. Problem is that somehow the cycle has little loopholes when documentation is neglected, it’s a common error and it’s frequently associated with continuing re-engineering. While the software development process favors communication over documentation, sometimes it’s the same thing. Documented software can communicate ideas between the team members and also the stakeholders, thus creating value that endures in time as an organizational memory.

And there is the major contradiction, as software requirements evolve faster than document maintenance, which is the reason why it’s not a critical part of the process in IT organizations. The ideal would be to detect what parts of the model are not temporary, and start versioning those to add value to the process. Scott Ambler covers the topic in extent in his book Agile Modeling, and he suggests that a model should be considered as permanent when:

  • There is a clear and value reason to make it permanent.
  • There is audience for which the model provides value.
  • Your project stakeholders are willing to invest in having it made into documentation.

Customer collaboration over contract negotiation. It takes both customer and home-team to achieve Agile. While “becoming agile” is a commitment for all the stakeholders, working software is a painful process without a client with focus on positive collaboration. If the organization is change-friendly, but the client is not then perhaps picking a hybrid methodology is the best way to start in the direction of an agile path.

Responding to change over following a plan. This is the weakest link in the chain of an agile aspirant organization, responding to change. There is a psychological cause for this, because we are always inclined to adopt routines and organizing routes for success, thus changing a plan seems a declaration of failure. Excessive planning instead of constant feedback and adjustment is one of the most common errors. This paved road may seem the only way to achieve the goal for a team leader, but for the rest of the team members it’s a daily problem that, when ignored, can lead to crisis. So if the interaction with the client and inside the project is positive and the team has a strong mindset with focus on working software, the plan should be left aside in favor of an emergent opportunity.

The golden goose and the black sheep:

There is always a new software product in the market, adopting it may bring important strategic benefits such as flexibility and availability in technological, architectural and business related decisions. Trends change rapidly and going after what appears to be the next market leader may cause the organization to follow a lost cause. If the organization discovers the decided path was not the right one, but the culture is change-driven then the team can react in the short-term by easing the morale blow, and recovering without costing the business a great deal of resources.

Some companies may differ whether the cost of the venture is acceptable for the foreseen benefits. It’s a matter of analysis, but the objective should be evaluated carefully as its importance is what actually dictates if the risk is worth taking. There are a couple of considerations to keep in mind to reduce the risk of bad decisions and to discern a golden goose from a black sheep.

  • Unbiased assessment: Is the objective to engage in the new marketing hype or does it really add value to enable new business aptitudes?
  • Harmony: How different is the new technology from the one I’m using? Will the emergent software positively change the way I do things?
  • Integration: Does the product integrate in the community of software products I already have?
  • Matching objectives: If the emergent technology aims to solve a specific problem, does my problem fit in the solution the software offers? Is it beyond my needs?
  • Available resources vs affordable investment: Do I need training or new resources for using this technology? Is the product licensed?
  • Product support: How big/motivated is the community?

Reading this entry does not guarantee an improvement in performance or in decision making results. It serves as a reminder that to do so we will need introspection. Introspection towards our job as individuals and as a team. There is not an important lesson to learn, but something useful to remember on a daily basis: change is not the enemy, it’s just an option. The software industry is always in the midst of change, learning how to identify where it’s truly headed and avoiding the false clues from the press and large well known businesses directly affects the company’s profit. Technical leaders should be aware of the nature of these changes as they act as consultants on every specialized decision. We must embrace the freedom of choice, adapt and roll with it, evolve when possible, consistently aligned with the new technologies that embody the crucial direction of the industry.