Taking the development world by storm since its introduction and popularization in 2001, the Agile Software Development model aims to keep development goals and timelines short and sweet, with frequent testing to deliver functionality as soon as it is available and ready. The Agile method promotes adaptive planning and encourages flexibility and rapid adaptation to change.
Businesses need innovation in today’s marketplace. This is not always easy and, in many cases, a new approach is required to reinvigorate innovation. An agile delivery approach can provide substantial, quantifiable business value compared to traditional approaches, but you have to do more than decide that you’re going to implement agile. Many agile implementations start off with good intentions, but do not deliver on the promise of agile because of a lack of experience, plan and executive sponsorship. If you can address these challenges, your agile projects are more likely to succeed.
Key Pitfalls To Avoid During Agile Development
An agile delivery approach to software development can provide substantial, quantifiable business value while introducing innovation and improving time to market. Many companies are embarking on agile initiatives, thinking that perhaps investing in some books or a couple of days of agile training is all they need before beginning the implementation. Such agile implementations often start off with good intentions, but they can lead to short-term chaos, create a negative impression of the agile implementation and eventually erode support for agile practices. It is possible to overcome them, but it takes dedication, discipline, support and an innate understanding of your company and culture.
Lack of Trust In Agile Development
The agile effect comes from trust (through a team that’s empowered to make key decisions on its own), as well as close communication and relentless focus on the highest-priority goals. Surprise the team with new mandates, unstated top priorities, an uncertain budget, political cross-fire or just a simple lack of trust and it’s hard to imagine anything more damaging to both morale and productivity. Surprise your team and watch it melt.
Not Providing Guidance To The Team
An agile team needs the type of leadership that provides a vision to work toward and motivation for achieving that vision. A strong agile leader, often in the form of a product owner, knows how to motivate a team with a description of an extremely desirable product that is just beyond what the team may think it can do. Freed to pursue that goal and provided with ongoing guidance from a product owner, an agile team can become a highly performing team.
Not Appreciating The Positive Energy for Agile Within The Team
As a manager, you may want to start by undermining the evangelist on the team—the one who has read all the agile books and is taking the chance to promote agile. Brush off the rules he is asking you to follow. Interrupt the daily scrum with new directions. All this leads to demoralize the team and eventually break the whole process.
Ignore The Agile Practices
If you want to be sure that agile doesn’t take root, go straight to the agile team members themselves and let them know you think agile is a fad. Some of them will be skeptical to begin with, so it won’t take much to convince them to ignore the practices.
Missing Commitments & Timelines
Cavalier attitude toward missed commitments leads to failure. If the stakeholders think that it really doesn’t matter if something was finished on the last day of the iteration (as had been committed) or a few days into the next iteration. What’s a few days between friends? Remember, a few days here and there can add up to quite a lot. If an agile team continually misses its commitments, it makes it impossible for the product owner to make plans and external commitments.
Not Creating Cross-Functional Teams
Here is an example of a failure: Merrilynn was able to use this guideline to kill her company’s pilot agile project. Her organization was developing an application that would have separate Windows and Web-based clients. As a development director, Merrilynn had control over team composition and was able to create three separate teams: a Windows team, a Web team, and a test team. This team structure worked against the goals of agile. If Merrilynn had wanted to succeed, she would have instead created three teams that each included Windows, Web, and test skills. Because Merrilynn kept the teams separate, she made it impossible for any team to deliver the working software that an agile team is expected to deliver at the end of each iteration. Nicely done, Merrilynn
Lack of Coordination B/W Product Owner and Coach(Scrum Master)
The crucial role of product owner often is balanced by someone else who acts as the team’s ScrumMaster or coach. On many successful projects, a certain amount of naturally occurring tension exists between product owner and ScrumMaster. A product owner always desires more, more, more features. The coach, by contrast, is responsible for monitoring the health of the team. If the team is being pushed too hard and is beginning to get sloppy due to fatigue, the coach pushes back against the product owner’s desires for more.
One Person Sharing The Roles of Product Owner & Agile Coach
agile failure at the product owner level is easily achieved through miscommunication, general ignorance of the team’s progress, and lack of education. You can compound that, if necessary, by having one person act in roles that are designed to balance each other.
Functionality Loophole – Compromising On Security
Companies tend to miss important things following the Agile Software Development. You are pushing code out faster as time goes on, and the goal is to make this rapid fire of code work to your benefit rather than your detriment when it comes to security.
To make sure that no code goes out unassessed, planning, leveraging the right security controls, making time for security and leaning on automation should be key components of your security routine.
Make Agile the New Religion
Evangelize this “new” way of doing things at every chance and make sure to promise great things. Be passionate to the degree of pushing. The time comes when someone asks for all the promises and that alone is a great opportunity to lose personal credibility and faith in the process. In addition, this is a good way to make agile the scapegoat of a failed leadership or project.
Divide and be conquered. Classify people as either “agile believers” or “heretics.” Camps are always good when it comes to making a case against something, in this case agile development.
Conclusion
Agile development and practices can provide the core approach that companies need to reinvigorate innovation and provide quantifiable business value. However, companies must do more than decide they’re going to implement agile—especially for large projects and complex organizations. Seeking advice from organizations who are experienced with agile on a large scale, forming an enterprise agile plan, and obtaining executive sponsorship can prevent serious issues and organizational risk down the road. Consider engaging the help of a third party expert to provide an agile assessment or skills workshop to help your organization avoid the common pitfalls and develop your roadmap for a successful agile implementation.
A good agile team picks and chooses the management & technical practices that best work for them.When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls “fake agile.”
It is better not to fixate on any given methodology, because the needs/conditions of the company and project are likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to be successful. No single methodology is a silver bullet, so the trick is to determine which methods work for you and tune your methodology to suit your individual needs. This is what being “Agile” is fundamentally about.
Drop Us A Note
[gravityform id=”2″ name=”Drop us a Note” title=”false” description=”false” ajax=”true”]
