Why does Agile fail?
Agile is an iterative approach to software delivery. The goal is to build and deliver software incrementally based on feedback rather than trying to deliver the whole solution all at once. Old methods, such as standard software development life cycle (SDLC) or waterfall methodology, do not deliver solutions as quickly and efficiently. By the end of a waterfall project – which can take years to complete – it’s also likely that the solution delivered does not provide what the users need. This is a common problem across every IT department and software delivery company which is why the agile methodology is becoming the new norm for projects that require flexibility.
In the agile platform methodology, there are 4 major roles: the product owner, scrum master, developer, and end user or business team.
The product owner’s role is to drive the vision of the solution. They need to understand the process they have to build.
The scrum master’s role is to remove impediments from the development team and assist in any way possible.
The development team includes software engineers, quality assurance and any other person that is involved in building the solution.
The end users are those who work within the final Agile application.
5 Mistakes to Avoid
From my experience working with companies across healthcare, finance, education, government and many other verticals, I have noticed that every company has its own spin on agile. And while every company needs to customize processes to their own unique group, there are a few common mistakes that I repeatedly see. Here are the top five mistakes made with agile methodology implementation and my tips for ways to avoid them.
1. Your Team Miscommunicates and Lacks Trust
Lack of trust will kill any team project; it is toxic to the work environment. Since there are a lot of moving pieces and people involved along with the pressure to deliver new features every 1-2 weeks, miscommunication is bound to arise during the agile process. Hence, it’s important to be transparent. That means committing to reasonable deadlines and delivering. Everyone should feel that they are working together towards a common goal.
2. You Have a ScrumSlave Rather Than a ScrumMaster
The ScrumMaster needs to serve the team. This involves removing impediments that the development team might have, coaching the product owner and other stakeholders, and sheltering the development team from politics or other distractions.
In some projects, I’ve seen ScrumMasters who try to dictate what the team does, micro-managing all activities. This kind of leadership not only damages the team morale and shows a lack of trust – but it also prevents the team from achieving their goals.
I have also seen the opposite scenario, where the ScrumMaster is disengaged. In this situation, the person may only attend meetings, leaving the person clueless to or unaware of what the team is doing. The ScrumMaster should be approachable, aware of any issues and actively working to resolve them as soon as they arise. They should understand the technology being built and help out in any way they can.
3. Your Product Owner is More Like a Doormat
The product owner needs to be someone who has domain expertise, understands technology and the business need, and has a product vision. This person interacts with the end users and the development team, guiding everyone toward the needed business solution. Given this person’s role, you need someone who can be the gate keeper of user feedback, provide clear guidance and manage expectations.
On one of my first projects, my client needed to go into production within 2-3 weeks and needed help resolving bugs during the user acceptance phase. We were quickly resolving bugs as they arose, but noticed that a lot of the user feedback was actually feature requests (not bug fixes)! The users were submitting feature requests within 2-3 weeks of the production deadline and expecting everything to be delivered. The product owner was not working with the end users to manage their expectations or to clarify a feature versus a bug – they were merely passing information to the development team and expecting everything to be done. It’s not surprising to learn that the project’s deadline got delayed further and further.
It’s imperative for the product owner to drive the vision of the project and to understand the business goal. But they also need to be firm and clearly manage user expectations. Otherwise, the project or even phase 1 of the project will never be done. This is where scope creep comes into play.
4. Your Requirements Are Very Complex
The more complex a project, the longer it takes and the more issues arise. When dealing with complex requirements, it is important for the development team along with the ScrumMaster to plan and design the solution as best as possible. That means breaking up complex requirement into smaller stories and iterating over time.
If the team sees any impediments or if the ScrumMaster notices anything that will be a roadblock in the future – all those issues should be raised ahead of time and a plan should be put in place. While you cannot account for all issues, it is important to know that every change made to the app during iterations has a cost. Sometimes developers change really big features late within the project. And while the developers may understand the implications of this change, the end users expect that since it’s agile, things will just be okay and fix themselves. However, the only way for a project to succeed is to add other iterations and extend the deadline.