Fact 1: Agility is based on technical excellence

Agility, that miracle that everyone wants but few can achieve. Some achieve it, but are not willing to pay the price. In the end most settle for using Jira and scaling regardless of the results.

We are going to start a series of blogs on why agility fails or in general why you see so few results in organizations. The factors are various, from technical excellence, to certifications, to leadership. Let’s go through the factors that experience tells us are the most relevant and have the greatest impact on the agility of organizations and the mediocre results that are obtained.

Let’s look at the following scenario and explore the first factor that affects agility in organizations: Technical excellence.

Agility: technical excellence in organizations

It’s 8 a.m. on any given day in a typical organization. The day before, a major change was completed that the business was looking forward to. The team gets ready to do their activities and plan the next Sprint. At 8:10 a.m. a case report comes in from a customer who is unable to complete a transaction.

The standard levels of support begin the review. At 9:00 a.m. the team has already started their Sprint Planning and are discussing the Product Backlog stories they are going to take for the next Sprint. At 9:05 the Product Owner and several team members receive notifications of several cases in production that prevent customers from completing a transaction.

The Product Owner receives a call from his boss and tells him that they must urgently review the case, since there are many calls and reports. Likewise, operations and production personnel have decided to use the alternate site, without the changeover, to avoid a major impact. After the altercation and a preliminary review of the equipment, they find the problem in the previous day’s changeover.

A use case that they had not considered or thought was unrelated. The Sprint Planning becomes an insight session and the entire next Sprint is rethought to understand the problem and develop the solution.

Agility scenario

This is a hypothetical scenario of what happens every day in different organizations that work with teams and “agility”. On many occasions Sprints are re-scheduled or cancelled, due to emergent and urgent work that is constantly appearing. Sometimes, if the problem becomes recurrent, a specific team is created to take care of this support and try to allow the other teams to continue developing and creating value.

But deep down, why does this situation happen, why does it continue to happen even though we are working with agility? The short answer is: lack of technical excellence.

So what is technical excellence? The concept as such is quite wide, but let’s review some aspects that we should consider.

Technical Skills

People must have sufficient technical knowledge to carry out their work. It is clear to everyone how fast technology is advancing and how it has become a driver of innovation for organizations.

Then we must imagine that the people who are in the organization to implement or adopt these technologies will also need to keep up with the technologies to deliver value to the customer. For example, Java has a new version of its JDK every two years. If we talk about microservices architectures we see that applications like Docker came out in 2013 and Kubernetes in 2014, which is less than ten years ago.

CSS4 has module specifications that were finished in 2018 and some were barely finished last year. And so we could go on and on seeing examples of technologies that continue to evolve. The question is: How does your organization ensure that people are kept up to date and current with these technologies and their proper use?

Much of being agile is about people, their ability to learn and evolve quickly. It is not easy to keep up with the speed of evolution of many of the technologies currently in use, but failure to do so would mean that the organization would soon have problems delivering the value required. There would be a knock-on effect where time-to-market and technical debt would increase and in the long term each change would be more costly and take so long that applications would become obsolete. Maintaining these applications means that agility would not be possible, no matter what practices, frameworks or certifications people have.

To foster technical skills you can consider these recommendations:

• Permanent training plan for technical staff (developers): training must be given just in time, if it is received before understanding the needs of the organization, it is lost and if it is given too late, there is a risk of generating a significant increase in the technical debt
• Collaborative development techniques: this point is discussed further below
• Promote continuous learning in people
• Encourage people to act with professionalism and technical excellence

Hyper-specialization

People love to dedicate themselves to only one thing or subject. Hyper-specialization is the idea that promotes that each person only knows and does one thing, therefore assuming that specialization will mean higher productivity. In general, there is nothing wrong with specialization.

However, a person’s specialization can be seen as a local optimization, while agility seeks an optimization that crosses organizational boundaries. Hence the importance that, in addition to their specialization, people are willing to learn one or two additional skills.

Not necessarily in a deep or specialized way, but enough to give the team as much flexibility as possible. When we have highly specialized people on teams who are unwilling or unable to do anything else, we tend to look for work for them to do, regardless of whether that work adds value or is aligned with the team’s objectives. In other words, technical excellence means that as individuals we have the ability to contribute in different fields at different levels of expertise.

It doesn’t mean that everyone on the team should be able to do everything, but it also doesn’t mean that they can only do one thing. In the middle of these two extremes is the state we seek for the team.

Getting people to learn from other fields outside their specialty is something that the team itself can accomplish. One of the most effective ways to do this is through some development practices such as pair-programming or mobbing.

To prevent hyper-specialization from becoming a problem, take into account these recommendations:

• Promote the T-shaped figure to all staff. Give incentives to those who learn a new skill within the team
• Promote lifelong learning and those who are willing to teach in their specialty
• Introduce collaborative development practices

Collaborative Development Practices

One of the most effective ways to promote technical excellence in teams is to adopt collaborative development practices. Not only do they improve product quality, but they also promote continuous learning.

Two of the collaborative development techniques that tend to yield the best results are Pair-Programming and Mobbing.

Pair-programming is not new. Basically, it involves developing a solution between two people at the same time on a computer, for example, one person types code while the other just watches, one person dictates the code and the other types it, and so on. People constantly change roles. In general, this technique allows knowledge sharing, improves quality and generally decreases delivery time, even if it means more person-hours.

The mob-programming or mobbing is similar only that in this technique not only two people participate, but the whole team does it. That is, the whole team, at the same time, with the same code and the same computer. They are constantly changing roles and can not only do programming, but also any other work that the team needs to do, such as documentation, testing, deployment, etc.

For many organizations these techniques are not suitable. They still have the traditional thinking of optimizing person-hours and not value delivery. They prefer to take one or two “stabilization” sprints, rather than try any of these techniques and improve quality.

The main recommendation here is to open the window of opportunity for the team to experiment with these techniques in a safe environment. Where they can adapt and fail while stabilizing and learning the new way of working.

Without these techniques it is difficult for teams and organizations to achieve the benefits of agility.

Development Strategies

It is surprising that many organizations that claim to be agile do not use development techniques such as test-driven development (TDD). TDD basically consists of:

• Write the code for a test first
• Run the test and it fails. We have not yet implemented the code with the solution
• Then write the code with the solution
• Rerun the test and correct the solution code if it fails
• Refactor the code to make it more efficient, standard, simple, etc.
• Repeat the previous steps

It is easy to understand that for many developers creating pre-solution tests is difficult. About 40% say that it is difficult to learn and practice. In addition, most of the management of organizations do not understand the benefit and if we add to this that applying TDD represents an investment, the fruits of which take about two years to be seen, we can understand the reasons why this technique is discarded.

However, the same study found a 40% to 90% decrease in errors before releases when using TDD. Another benefit of using TDD is that the overall design of the solutions becomes simpler and more effective.

So, in summary, we can say that the lack of vision of the organizations’ administrations, the initial difficulty of adoption and the time needed to see results make that most organizations do not use a technique such as TDD.

This hinders test automation, the culture of quality and refactoring and ultimately the time-to-market and agility as a whole.

The recommendation is simple, the organization should adopt and practice TDD until it no longer hurts to do so.

Automation

Today, automation has advanced by leaps and bounds. Many of the mechanical or repetitive tasks can now be easily automated by teams. This allows them to have more time and focus on delivering value and at the same time they can apply the techniques described above.

To expect an organization to achieve business agility without automation is like driving a car without gas. The famous promise of twice the work in half the time cannot be achieved without implementing concepts such as DevSecOps. Constant refactoring of code also requires constant testing. The delivery of value from the teams must be as close to the user as possible, and without automated systems that bring changes into the hands of these users, we will be far from achieving agility.

Technical excellence means that these capabilities are established and constantly being improved. The fewer manual processes there are, the less chance of human error, the higher the quality and the better the time-to-market.

We can mention or identify other practices that support technical excellence, but in general you already have an idea of what is sought and required to achieve it. It is also important to emphasize, once again, that without technical excellence agility will not be possible and therefore must be an imperative in the pursuit of business agility.

Remember, agile is an attitude, not being faster than competitors Doy you want to know more? Achieve an agile business with people-centred strategies focused on leading change and adapting quickly to market changes. Contact us.