Many organizations adopt Agile development methodologies, or just Agile, for the right reasons. They want a software development methodology that welcomes change. They want something to give management better visibility on team progress and teams better visibility into the longer-term product plans. They want something to give motivated, competent individuals the opportunity to take more ownership and build value.
However, many organizations adopt agile for the wrong reasons. The bandwagon effect and general hype have made Agile a panacea. Unfortunately, Agile exacerbates many problems instead of fixing them.
The biggest problem Agile exacerbates is lack of trust and respect. Management needs to trust software developers to estimate accurately, cooperate with other team members and ensure non-functional requirements are met, such as automated testing and performance/scalability. Team members need to trust management to not use Agile to push more work onto the team, not to blame the team for poor or late management decisions, not to use the increased visibility for performance management and to promptly address hurdles the team encounters.
Agile only works if people are willing to change. For example, if software developers are unwilling to “waste” time on daily stand-ups, estimations, automated testing or code reviews then they are missing the point. While Agile, specifically Lean, allows decision making to be delayed to the last reasonable moment, decisions still must be made, communicated and supported.
Poor communication makes Agile harder. Technical team members often have difficulty translating technical details into something the business can understand. Product owners, usually senior decision makers, often have many demands on their time and a team of software developers can be culturally easy to deprioritize.
Remote team members, particularly in different time zones, make face-to-face communication harder. Technology can partially compensate, such as teleconferencing and Internet chat applications, but communication occurs as much in incidental conversations as it does in meetings.
Agile requires customer involvement. Scrum, for example, has the product owner role where a customer is actively involved in the process by identifying and prioritizing work and being available and accountable. Agile emphasizes regular delivery of working software to customers.
However, this works against the contractual nature of most outsourced software development. Some products, such as enterprise software, have six month or longer sales cycles and delivering software more frequently just burdens support. Some customers lack the expertise or desire to be actively involved. Successful agile requires an agile-capable customer.
Successful agile also requires an agile-capable team. Not all team members are proactive, Kaizen-embracing go-getters. Some people are happy to be led. Frequent iterations and regular delivery require deep and broad technical skills that some individuals or teams may lack. Team members need to be focused on value, not solving technical problems.
Without addressing these problems beforehand, Agile adoption causes a lot of pain and suffering. While the agile manifesto is easily read and understood, the underlying wisdom is less so. Agile is a tool that allows an organization hamstrung by poor process to excel. Otherwise, Agile is often blamed when the real cause is the underlying culture or structure.
That said, Agile can be an effective organizational diagnostic tool. It shows problems that people often did not see or did not want to see. Therefore, it is important to clarify intentions and understanding before adopting Agile, as Inigo Montoya recommended.
Blog post image is a modified version of the image by Froztbyte – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1121735.
Thanks to Adam LG Ring (@adamlgring) for the title.
