5 things wrong with Agile
There is way more than 5 things wrong about what people call agile, but if agile told us anything is that we need to be building things by small increments.
Agile as practiced by many organization:
- Keeps or adds overhead
- Waste time
- Decrease informal and personal communication
- Devalues the roles of Product/Project Manager and the development team
- Focus on a mythical concept of quality
That’s not to say that it is all bad or that it is not to be preferred over a waterfall approach, merely that there needs to be thought of when, where and how to apply it/
Scaled Agile, Spotify Agile
So corporate answer to them noticing that agile doesn’t work, is simple let’s add more layer of management on top of Agile. Because something that was originally meant to empower people is necessarily a bad thing. Let’s add chapters, tribes, guilds, programs, portfolios and what not. These things tends to by themselves suck additional time in meetings, approval processes etc… More often than not they represent a way for old school upper management to go back to a locus of control they are comfortable with rather than fully empowering a bottom up approach.
Agile, at least corporate agile focuses on process and ceremonies. Attend stand-ups, refinement, planning, poker session, retrospective, demo … All of which sucks time out of your day to which you would have to add the normal team, department, 1:1 and other meetings you might have.
Because of Agile ceremonies some of your employees are now close to half as effective . This is often the case for those that needs to be part of two teams, or those working part time 4 days a week and tend to have already a decent amount of meetings. These people don’t tend to be developers, but more the business analysts, data analyst/scientists, UX researchers, Architects …., roles often not dedicated to one single team, and having a decent meeting load already without agile.
Arguments put forward by scrum master and agile coach is that they only represent maybe 10–15% of your working time, but that’s always not factoring being part of multiple teams, working part time, other meetings, the fact that a 15m time-slot left in your agenda doesn’t allow for proper work to be done. For these type of roles, the truth is that these ceremonies can easily take between 35–50% of their non-meeting time.
Agile and scrum are pushing for forms of formal communications, communication happens in meetings, stand-ups etc.. what would have been a direct informal communication with a small question “how are your tasks going” is being replaced by “yesterday I have done this, today i’ll be doing that” a series of broadcast supposed to inform the team on your progress what would have been personal engaging communication becomes impersonal. To a certain extent Agile assumes that developers are some form of autistic kids that cannot communicate between each other unless told to.
Scum Master and PO roles
Frankly the Scrum Master and PO roles are an aberration, they under values the role of a Product Manager or Project Manager role. Scrum Master are organizing ceremonies and enforcing agile practice, they see themselves as “servant leader” but they are little more than a mix of an assistant and an enforcer of agile practice while supposed to act as a balance to the product owner’s demand.
Same is true for the role of Product Owner, they need to “take care of the backlog” make sure that there is clear user stories that everything is defined and populated correctly and they need to “manage stakeholders”, do QA to validate that the product has been delivered properly, this role again they take another role of assistant but this time they are meant to be a shield for the development team from external forces.
Compared this to the role of a Product Manager, that is meant to set the roadmap, define the metrics for success, provide business cases, better understand the customers, communicate the vision of where the product should be going. The product manager is responsible for the success of the product.
The role of product manager doesn’t assume that developers need to be assisted or policed in delivering value. It makes sure everybody is on the same page as for the general direction and let software engineers own their destiny.
Focus on Quality
Agile focus on this mythical concept of quality. Process must ensure quality, but nothing really defines what should be quality. There is some mention of acceptance criteria supposedly meant to ensure that what is delivered is out of acceptable standard. This however makes a few assumptions
- That everything that can be construed as defining the quality of what is being delivered can be known in advance
- That what is there is no uncertainty as to what is going to be delivered
Focusing of quality, is generally fine when it can be clearly defined and expressed, when there are parameters that are not fully known in advance or that would need to be defined as we go along the development process
Agile with its focus on quality, is ill adapted to take into account the concept of uncertain delivery. Take for instance the task of deploying a machine learning model/system into production, how do you define what should be quality? is it the ability to make better prediction? Is it providing code that is exhaustive and tried to treat all the right cases?
What if your model failed to make better decision than the previous model? can that be considered still a success? Is a decision to stop investigating further an area to be modeled be considered quality?
Most of the issues are due to a bastardization of agile by corporate entities trying to sell agile as a process to fix all that is wrong with software development. It is generally sold as the messiah that will save us from waterfall development. Agile is further sold as the way to digitize your company, needing for all of it to become agile and scrum is more and more embedding itself into what people call Agile.
Agile can work in certain situations but is a concept that has been over extended and abused beyond reason. From something that was meant for web developers working in agency to handle their client demands. There is however valuable concept within its manifesto, for instance the focus on small increment, the focus on people over process.