Once upon a time there were some companies trying to build the perfect software. They called it the killer app. Unfortunately, they struggled producing any value and got killed themselves. Their CEOs and boards of directors asked WHY. After a lot of analysis and meditations some clairvoyants got the answers; These companies were not agile enough. They did not adapt to market changes and technological development. Their costs went up in the roof while top management lacked insight in what is going on. Of course you do not wish your company to be one of those we are describing above, do you?

If you look carefully on the statements above you may realize that I am stating that these companies should have looked for:

1. Reduced time to market: We need to be there before our competitors or at least before the market is completely taken. We can earn money faster.
2. Increased value to market: We should provide value to keep ourselves relevant. We need to chose the strategies that cause our decisions to create more value.
3. Increased flexibility: We need to adapt to market and environmental changes.
4. Increased visibility: We need to gain better understanding for where we are at all the time so we understand the risks and expectations too.
5. Reduced costs: We need to be cost efficient so we do not price ourselves out from the market.

Wow! That was an impressive list of what we needed to do. I guess, there are nobody who really disagrees to it. BUT, how can we apply this learning to software development?

Some years ago, I was hired to help a software development company that have struggled moving forward. They gained a big market share, had a good reputation in the market, but did not manage to scale neither their development nor their support. They were stuck in a corner struggling getting outside. Over time I managed together with the whole team, including product experts and management of the company to transform the company into an agile organization that reacts quickly to changes, is able to cope with market challenges and create solutions for tomorrow too. In the following sections, I will describe which agile practices I have used to help that company to reach all of the goals mentioned above. The table below shows the essence in everything I have done:

We can discuss each of these points in its own article. To make this one less boring I will just explain how these practices help us:

Requirements review: Business needs to review requirements several times to ensure they are matching the market and are still valid throughout the implementation process. Some requirements can for sure be ignored while others are a must. Using a good process for requirements gathering is a must to be successful. There are a lot of ways to do this. One of the best tools I have used is Discover to Deliver. doing that helps us reduce both costs and time to market.

Simple design: By simplifying our software architecture and design we enable incremental releases, embrace change, rapid feedback, deliver value faster and continuously. We travel light from a stage to the next one. This might be the most important practice I have applied during my whole career and at all places I have been delivering value. Although, when talking about architectural design, I believe it is necessary to create a domain model, a use case diagram and some sequence and interaction diagrams before we start coding. Some people will say; UML is out today! I would answer that these diagrams do not need to be written in UML or any other tool, but in a language that everybody understands. I use the whiteboards a lot to carry out such design activities. This kind of work allows us to have a real thought about how our architecture is going to respond to both changes and integrations.

Testing: Software quality assurance is unfortunately underestimated by too many companies. Many looks at this work as an extra cost instead of an investment. If your company does not run professional quality assurance, I guarantee you are taking too high risk. Quality assurance is not only about finding software defects, but also about ensuring that the value we are promising to deliver is delivered in the right portion. It assures us that we are able to cope with todays and tomorrows demands from the market, the technical challenges and not at least the environments our software might be running in. Software testing can be done in many ways, but should always include:

• Automated testing: Also including API and integration tests
• Performance testing: Covering Load, Stress and Stability of the system
• Compatibility testing: Including different configurations, hopefully using container technologies, different browsers and operating systems and integration with 3rd party software.
• Security testing: Identifying where the weaknesses are and ensuring that our systems do not increase the vulnerabilities of our customers.
• Manual testing: Covering both exploratory and destructive testing

Refactoring & Unit testing: These two techniques can also be considered as essential part of the quality assurance efforts during software development. We gain new knowledge as are progressing in a project. This learning must be merged in the product we are developing. Restructuring the system to make it possible to benefit from this learning is a must so we deliver systems that cover all knowledge gained. Unit tests play a central role while refactoring so we can do the restructuring work while we are certain that other parts of the system are still intact and still valid.

Collective code ownership: The most effective way for a company to produce a unit of work is to ask the most skilled person in that type of work to do it. Many software development companies use this strategy as it makes them «more productive». Unfortunately, they forget that following this strategy will cause them to:

• Build bottle necks: Other employees will not be able to deal with the same code blocks.
• Increase business risk: What if, and it happens, the employee decides to leave the company ?
• decrease the scalability of the organization: often these specialized code blocks become applications written in a given language and known by only few people. These cannot help other employees when the need is in a different application

Collective code ownership can automatically increase the quality of the systems since more people look at the same code and improve it together.

To summarize: If the companies we were referring to at the top of this article were applying the learning we have gone through till now, they could have gained a lot by:

1. Improved efficiency
2. Improved manageability
3. Improved quality, maintainability
4. Improved ability to handle changes
5. Improved communication