BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Importance of Technical Practices in Agile

The Importance of Technical Practices in Agile

This item in japanese

Sometimes organizations that are adopting agile complain that they didn’t get the benefits that they expected to get out of it. One of the possible reasons could be that insufficient attention has been given to performing the technical practices that support the agile values and principles.

In the blog post the state of agile software development Matt Badgley described what in his opinion causes debates in agile communities on enterprise agile and scaling agile:

It is well known, that organizations need to address their Enterprise Agility — which means organizations can adapt rapidly and efficiently in response to business and or market changes. In fulfilling the need of Enterprise Agility — large organizations are working to adopt agile processes within software development and other departments. A number of frameworks and approaches have emerged to address the Enterprise Agile needs and as a part of this movement, a consultancy-economy has formed to help implement the frameworks. This makes agile software development purists uncomfortable. The fear is that the only thing the consultancies and frameworks are doing is providing middle management and PMOs what they always wanted — a heavy-weight, control-oriented, certified process that has the word “Agile” in it. This is exactly what the original anarchists who wrote the Agile Manifesto were trying to change.

By taking an innovation adaptation lifecycle view Matt explained that agile has crossed the chasm and may well be at a point of innovation discontinuity. Either agile could die and be replaced by something else, or it could be renewed based upon good results that have been gained from applying the values and principles from the agile manifesto:

We need to renew the emphasis on agile engineering good practices and embrace the ideas of craftsmanship — without this, agility does not happen. We must practice relentless transparency — trust does not exist without it. We must get our executive and management ranks engaged — education is not enough. We must always put people first in that people are how things get done, not the processes. And finally, as Dave Thomas’ blog points out, we have to get back to the core of Agility — assess where you are, take a small step toward your goal, adjust based on learning, and repeat — all the while, making change easy with all decisions made.

Calen Legaspi is blogging about agile myths. In his blog agile myth #1: "agile is a methodology" he clarified that agile is not a process; agile is about the “values and principles that allow software development processes to be successful”. Technical excellence based upon using practices is one of them:    

Of the 17 authors of the Agile Manifesto, many of them are thought leaders in the engineering side of software development - Kent Beck is the creator of JUnit and Test-Driven Development, Martin Fowler has written several books on Design Patterns and Refactoring, Robert Martin has written several books on Object-Oriented Design and code quality... A lot of people think Agile is mainly about project management, but the creators of Agile put equal if not greater emphasis on engineering as well.

Robert Martin wrote the blog post the true corruption of agile in which he talks about agile culture, values and practices. According to Robert “a culture is an expression of values” and “the practices you follow identify your culture”:

if you find yourself in a team who practice continuous integration, short iterations, pair programming, and test driven development, it is a powerful indication you are in a team who shares the values of the agile manifesto. If they did not share those values, they would not follow those practices.

Ritualism can cause teams to follow practices without understanding the values:

it's possible for a team to be so entrenched in practice that, over time, they forget the values expressed by those practices. This is a common failing of bureaucracies and religions. They become so strongly defined by their practices, that the practices become rituals, the original values are forgotten, and the rituals become the values.

According to Robert agile can be corrupted due to a loss of technical practices:

The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don't recognize as Agile any more. It has been a shift away from excellence towards mediocrity, away from hard realities, towards feel-good platitudes.

The loss of practices causes developers to abandon the agile movement while at same time managers are adopting agile as a process only solution. As a result the distance between developers and managers increases.

The software craftsmanship movement preserves the coupling between practices and culture by emphasizing that technical practices are important for agile to be successful:

Are the original 13 practices of XP the holy writ? Are you an apostate if you don't practice TDD? Of course not. But if you don't use those particular practices, you'd better use some that are as good or better. And the practices you use will define your culture and be an expression of your values.

If your values are those of the Agile Manifesto, then your practices will likely look a lot like those original 13; because to a large degree it was those 13 practices that drove us to write that manifesto.

Earlier this year InfoQ interviewed Tim Ottinger and Ruud Wijnands about their views on the problems that organizations are facing with agile adoption. In the Q&A on taking back agile Tim and Ruud explained why they think technical practices are important in agile:

Tim: Technical practices keep our code workable so we can release very frequently. We see companies using no technical practices at all. Their code gets messy from trying to release frequently without managing the code base, but they're complying and conforming to the new process. It's not okay with the programmers and testers, and nobody is happy to see the velocity drop, but managers won't give permission to adopt technical practices. They fear that pair programming or testing might not be efficient. They guess they may not be able to adopt technical practices because of micromanagement.

Ruud: (…) the companies that I have seen that were successful in their agile adoption all valued and implemented technical practices. The companies less successful did not.

In the blog post behavioral traceability: values to principles to practices Geof Lory provides a solution to visualize the relationship between values, principles and practices. This solution can help to assure that all values are covered by practices and that people applying the practices will understand the underlying principles and values:

If you were to blindly follow any practice and not apply that practice in a way that brings out the underlying principle, any benefit would be fleeting and unsustainable. The problem is, applying the practice itself in no way assures the benefit of its underlying principle. It's not the practice that is effective, it is the principle behind the practice that really matters.

Geof suggest to apply traceability in a way similar to requirements traceability, using what he call intents:

Intent is the thread that strings practices to principles and principles to values. Understanding our intent keeps us from deceiving ourselves as to whether we are living by our stated principles and values or not. The Team Operating Agreement is the mechanism for being explicit about our intent and alignment.

Teams need to establish a team operating agreement at the start of a project according to Geof:

A good Team Operating Agreement outlines the Values, Principles, and Practices the team members explicitly agree to and intend to hold themselves and each other accountable to. This living document eventually captures what I define as team culture: what most of the people are doing (or at least have agreed to be doing) most of the time.

When adopting agile the practices can vary depending on the team needs. However they will have to match with the principles and values that are underlying the agile transformation in the organization to make the change to agile sustainable:

For any behavior change, people learn first by practicing, and then learn to relate their practices back to principles and values. Without this relationship, the behaviors will never be self-sustaining. Without internal alignment, practices will have to be monitored by an outside party to ensure compliance. Since these external governance processes are designed to maintain the status quo, the practices will lag behind as situations and environments change. Traditional process-heavy methodologies exemplify this situation.

However, you can't just mindlessly emulate a few practices that are working for others. Every team, every organization, is different. Unless you understand the values and principles of Agile, you will struggle to adapt practices to suit your team's unique circumstances. Most of the benefit of Agile comes from its ability to help teams work effectively and efficiently regardless of all the differences. Agile is adaptable.

Rate this Article

Adoption
Style

BT