When Agile Development Becomes Too Agile

The Agile development methodology has a self fulfilling pitfall - the addiction to change. Everyone knows that attaining process perfection is an illusion. Especially in the ever-changing environment of software development.  Here, where policy is better thought of as a set of guidelines rather than rules, correcting how you do things to keep up with change is essential even if perfection is out of reach.

Projects rarely conform to the best thought out workflow. Clients even less so. As a result, each iteration brings with it more information. Each retrospective meeting creates more data and with it the urge to amend the process which reflects the knowledge gained. Once an organization embraces the Agile methodology the temptation for continual process improvement can become all consuming.

And just as a rigid development environment can often stifle creativity, being too fluid can be just as disruptive to productivity.

My time as a quality assurance/business analyst in a series of development teams has shown me several things:

• Nearly every developer I know does not like electronic paperwork.
• The same is true for meetings. Both are viewed as a necessary evil.
• Each had a different time of day they were able to go deep to write code and had a preferred method of working.
• Even if people got along socially, their work personalities might not gel with each other within the same development team.
• In two week sprint iterations, development teams worked best when there was a predictable routine and rhythm.

It is here where an organization devoted to continual process improvement should be careful.

Disruption to a team on a weekly, sprint, or even within a release basis, should be taken seriously. If developers continually have to relearn guidelines due to process improvement or adjust to re-assigned team members their productivity can suffer. So can their attitude.

The following are several areas that, if changed too often, can have an adverse affect on your teams:

Continually changing your electronic paperwork.

Remember, this is thought of as a necessary evil.  Most developers want to spend as little time on this as possible. If your paperwork workflow changes too often for your teams to keep up, it will never be completed consistently. This eventually will become a headache for both the management team and the development teams that rely on the paperwork being correct.

Changing or shifting goals.

Developers prefer clear cut objectives and a route to achieving them. The best case scenario is to have a road map for the entire release which will never change. This is very nearly impossible. The next best scenario is where the shifts are based on a change of need and that need has been compared to the original road map. If the change in goals seem reactionary, it will be difficult for the developers to mentally commit to the project in front of them.

Swapping teammates mid-sprint.  

This will disrupt the flow of your teams and their sprints. Unless each individual developer knows and understands each piece of functionality, the time lost to orient themselves in productivity is lost. Teams that have been together for a period of time also tend to find a rhythm in how they work. Constantly changing teams never allows them to find their cadence.

Any or all of these things in excess can cause your teams to disengage from the process altogether. Agile fatigue is a known phenomenon. My experience with this on a team level is the attitude of ‘why bother, it will just change again anyways.’ When this occurs, the possible effectiveness of your improvements may be lost.

The Sweet Spot

I do believe there is a sweet spot. The organization I worked for adopted the Agile methodology so we could build in structural flexibility to handle change within the development teams. Despite their affinity towards a clear cut set of goals and repeatable rhythm, development teams know change, sometimes on the fly, will happen. There are times where an internal or external customer emergency needs to be met and the framework of Agile is the best way to meet that emergency.

But to keep the sweet spot between continuity and the need for change, keep these things in mind:

• The change needs to serve a larger goal. Whether it is to remove a development roadblock, clear a choke-point or allow a more structural change that serves the management team, the change must have a defined purpose.
• Some of the changes should reflect what has been expressed in the retrospective meetings. If the development team sees that their concerns are being addressed, they will more likely accept other changes in process as necessary, too.
• Be willing to accept an imperfect process that best facilitates software development to occur. Agile is to provide the most productive environment to achieve an organization’s goals while those goals evolve, not to produce the most efficient processes in and of themselves.

The Agile methodology will help any organization adapt to ever changing development needs, but looking for tell tale signs of Agile fatigue within your teams will help you manage the impulse to change when it may not be needed to achieve your desired goals.