In a Nutshell, why do a lot of developers dislike Agile?
There are lot of answers to this question and I have only posted based on my experiences.
I am hoping for people to share any from there own experience any which I have missed out of my list. This allows for me to learn from your experiences also. So without hesitation lets begin.
Why do a lot of developers dislike agile?
Firstly agile is a super broad term and often people have issues with some parts of the methodology more than others
For example:
- Most developers agree on continuous integration and automated testing being of value
- Less developers see merit in pair programming
A big concern I have seen is the time spent in meetings.
- It's a fair concern, the ideal team size is somewhere around 8. That would mean in a 2 week sprint:
- Daily stand up = 8*15 mins * 5 = 600 minutes
- Sprint planning = 8*45 = 360 minutes
- Backlog grooming 8*120 = 960 minutes
- Sprint Demo = 8*45 mins = 360 minutes
- Sprint retrospective = 8*45 mins = 360 minutes
- This would total: 2640 minutes or 44 man hours of time spent on meetings in 2 weeks with conservative estimates on time.
- I think we can all agree this is quite a significant amount.
I have experienced many concerns against the stakeholders prioritization choices
- Timescales are squeezed
- By design agile methodologies squeeze timescales to reduce ineffeciencies and improve responsiveness of the business.
- Stress levels rise
- Due to always needing to release and demonstrate
- Sometimes MVP’s are not up to scratch but are still released and shown to many people.
- This can cause anxiety over peoples opinion on the poor quality of the work delivered.
Project managers are often replaced with scrum masters.
- These two skillsets are not replaceable one for one, they have subtle but significant differences.
Lack of need to communicate outside the local team meaning isolation and internal group think
- This can also lead to conflict within the organisation as a culture of us vs them can emerge
Feeling like a cog in a machine
- Plan, Do, Check & Act
- Plan, Do, Check & Act
- Plan, Do, Check & Act
- Plan, Do, Check & Act
- Repeating this sequence ad-infinitum can make developers feel like they are in a rut or just using up time like on a hamster wheel.
Technical leads having limited influence
- Often product owners and stake holders are given more weight when making decisions and what they decide is generally final and overruling of the technical lead.
Product owners have limited control and bow to stakeholders
- This can lead to short term thinking in the perceived hope of obtaining customer satisfaction
MVP and lean delivery seen as not high enough quality product
- This can make developers not feel proud of the work they are producing
Developers lose commitment as they don't feel identified with the work or business
- This can propagate into a lack of vision or warm feelings for the long term
These lead to concerns over job security
- Cross functional teams also reduce job security
The development team can often feel inadequate for not meeting the perceived potential.
- The team is often under budget or resource constraints but are consistently reminded of what there capped velocity is via information radiators
- The constant search for looking for defects, waste or errors can aid developers in forgetting about the positives
Developers can also dislike the complexity of the process
- Agile is quite involved, collaborative and requires communication. Developers in the past have tended to be introverted in nature.
- Some compare the current agile methodology to waterfall and would just prefer to receive a specification and task list and be left to do the work.
It is often difficult to trust the product owner when they dont have direct access to the end customers.
- I have seen in big business to business sales organisations the product owner has limited access to the customer base and likely never even speaks with someone who uses the software.
- This undermines there credibility and the effectiveness of the agile model.
I am sure there are plenty more and if you feel I have missed some please leave it in the comments so I can learn also :)
These would be the most common I have experienced.
Hopefully it helps
Good Luck
www.oliverdolan.com
Ex-Roblox | Software Craftsman, Agile enthusiasts I solve problems
11 个月The math looks very off… Does times 8 mean it is one demo/retro/grooming/planning per person?
Engineering Management of scale up companies | Builds top efficient organisations by setting people up for success
5 年Interesting thoughts for sure, all reasonable to discuss if that is how someone on the team feels about things. Maybe we can change our ways together, or offer a different perspective which clears things up? Maybe the real problem is somewhere else, lets solve that! The things I see in particular troubeling is when we are affected negatively by things outside our teams if our culture or how we are structured won’t allow a permanent resolution for it. The fundamental question I would ask, is agile the rootcause of that problem or are these just symptoms of other rootcauses in how we practice the agile framework? Could we instead think about the purposes with those meetings, and maybe we could form them in a way we believe in? Meetings for example, could we instead see and change those meetings into mobbing sessions, team celebrations etc. Our work is way more then just coding, if we’re stressed, could we cur estimates and optimize for flow instead? For technical debts, could we make it clear that are fought on every single ticket we take, on the go? Could we have fridays off from stakeholders decisions, and work on the things the team feel is important? Bottom line, agile should not be stressful, or we’re doing it wrong
Software Development Engineer at Amazon
7 年While agile is right in many cases, I think one of the biggest pitfalls of agile is the need for all sprints to have a customer oriented demo. If you are doing sprint work to improve data structures, algorithms, or systems architecture, there is nothing really visible at a customer level to demo. Because of this, scalability and reliability concerns often go to the bottom of the priority list unless your stakeholders happen to be veteran engineers. When this happens, companies become reactive instead of proactive with their IT and software development strategies. i.e the big problems don't get addressed until they are an impending crisis.