Why Agile Fails
The five elements that reveal a bad execution of working agile
By Humphrey Fredriksz
After working 6 years with dozens of agile teams, I have seen many things going wrong when working agile. Many agree that the principles of being an agile development team should be effective for your business, but the reality is that a lot of teams are struggling. This is really unnecessary. I have seen team fails and succeed and I found these are the differences.
First of all, I don’t want to say that agile is bad. And I do know a lot of you out there probably have seen good performing teams but the truth is that many agile believers lose the reality and the origin of agile. If you go beyond the hype, I can assure you that agile working is NOT about delivering the same amount of work faster, it’s not about being able to change your mind constantly and definitely not about giving teams carte blanche.
My second point is the belief that working agile is the key to having a successful project or product delivery. Agile will fail if your team doesn’t have good developers which are motivated and care about quality. If teams are pushed or if shortcuts have to be taken, they will fail sooner or later. They will get demotivated and they are smart enough to understand what is going on.
“One of the biggest misconceptions about agile development is the idea that you can totally ignore the business and other stakeholders and that you as team can define your own plan, objectives and work.”
1. Estimations with story points
The backlog is filled with 50-150 user stories, epics are setup and the objectives for next quarter are clear. All user stories have a description like “as a user I want to be able to calculate my costs so that I know what product to buy”. Perfect. It’s customer centric and give context to the developers. Sound good right? Not. My developers would still ask what exactly is expected. To be honest, user stories aren’t requirements and if requirements aren’t split up into subtask (which can be tested), you are setting yourself up for failure.
Story points for estimation is fine for high level indications. It gives the product owner insights to make a decision to continue with the story or to adjust his wishes. To actually measure the work that a team can take, the progress of a sprint and to be able to pinpoint what causes delays in your sprint or roadmap, you will have to track hours on subtasks. Many scrum master will disagree, but I have seen the same teams be unable to deliver one sprint. And most important, it’s liked by the best developers I have worked with. It’s give much more context, preparation and insight in the team.
2. Who really understands agile
Either they don’t understand or they don’t care. Most developers just want to build cool and high quality stuff. They want to learn, get betting in what they do and maybe one day become a tech lead or this awesome job at an other company. All these scrum events can be experienced as time consuming driven by over excited scrum masters. The truth is that many never really had an agile training, maybe half did a online course or if they are lucky the management paid for a 2 days course.. a long time ago. How can you work agile if half the team doesn’t really understand what it really means? They will ask you (or not) WHY are we doing this circus?
3. Missing the bigger picture
While the team is focussing on making the sprint, completing tasks and fixing issues, you will notice that a lot of times issues will be accepted with the comment “it’s good for now”. Meaning, you know it’s an issue, but due to time constrains you decide to leave edge cases and issues for the future. This is ok, but if the teams in the next sprints needs to keep focussing on items with the highest value, those edge cases will never be touched again. Many teams think short term or only about their own team. Getting workable software done every sprint by any costs can result in bad decisions on the long term. You will notice that in 6-12 months developers will be complaining about the quality or complexity of the code.
4. Afraid to fail (often)
Yes, we are agree with fail often and we all have seen the quotes on instagram from innovation and start up bloggers but the reality is that most team members don’t want to fuck up shit. They don’t want to build something which is half the work or not working. Getting an agile mindset this way only works in a very limited number of organisations. The result of this fear is that team overdue and spend most of their valuable time in the last 20% of the work. I have been taught ‘don’t let perfect get in the way of good’, because you can spend easily 20-30% of your team capacity on feature or experience a very small percentage of your customers. And to be honest, your features will never be perfect.
5. Don’t worry, we got this!
One of the biggest misconceptions about agile development is the idea that you can totally ignore the business and other stakeholders and that you as team can define your own plan, objectives and work. Like if you are running your own business. I understand the ownership and fact that you want to be independent and accountable, but ignoring the business and other departments is killing trust, support and in the longer term funding. Agile teams must address company objectives, collaborate with the business and other teams and have a shared product vision with their key stakeholders. Otherwise, you’ll get silo teams, silo architecture and a culture which isn’t moving the whole IT company forward.
Is your team kicking ass or trying to get there? We build an agile team assessment to understand exactly where they lack and how they can improve. Great insights to improve impact, predictability and team spirit.
Accelerate Agile teams
What we analyse:
MyValueCoach is an online coach for agile teams. We analyse, coach and accelerate teams worldwide.
Change the world of education and help talents all around the globe to work together.