I recently gave a short seminar discussing Agile implementation. In several previous webinars as well as blogs, we’ve discussed Agile implementation success stories, so I was actually happy to present another viewpoint that not everyone is excited and satisfied with Agile, as Agile does not fit everyone. One of my slides, titled Agile Reality, was on Agile not being so easy and not all it’s cracked up to be. Here are some of the points in my lecture below:
- When Agile is scaled with multiple scrum teams, it is easy for each of the scrum teams to lose sight of the big picture. They don’t have an overall view of the project, nor do they know what the other teams are doing. Because of this, for large software projects where many modules and functions must be integrated together, the integration at the end of the sprint usually runs into problems. Substitute data, stubs and containers just don’t work all the time.
- Velocity (in scrum) is used as the main metric to measure progress, which is not indicative of how well the process is going, and doesn’t tell anything about the quality of the product.
- Estimating effort is a hard task. Even after a year we can’t get it right. People pad estimates or they overestimate their capabilities. “This is no big deal” turns into several days of work.
- Meetings take so much time – planning, grooming, stand ups, etc. For any newly added stories in the middle of a sprint, we need to have additional planning and grooming meetings for estimating and to see what else can come out. We don’t have solid blocks of time to do any coding or real work. Meetings break up our work and train of thought. Starting and stopping is not good when you are a programmer.
- There are less documents, true, but the time spent in meetings makes up for any time we would have spent doing documentation.
- Agile is good for managers who want to know the status of things, but not good for engineers who need to get the real work done. There is no more black hole where management doesn’t know what is going on until the end (as in Waterfall), but on the other hand, breaking all the work up into these small pieces does require more overhead.
- Trust? There is actually less trust in Agile. It feels like the constant attention to progress is for the sake of knowing exactly what you are doing.
- Daily scrum meetings are not useful because mostly they are perfunctory for status, but problems get solved in the hallway anyway.
- Everybody’s different. We know that. What this means is that some team members are slower or faster, and each team member has specialized knowledge that often can not be substituted (another team member may be knowledgeable but not that deep). So in the first case, you’ve got slower and faster team members. First, the faster guys may get tired of always helping out the slower guys at the end of the sprint, or they may pace their work so they are done with their work just in time. They really can’t storm ahead on their own. This is good and bad. In the second case, if you have a person that goes on vacation, even though everyone is supposed to be agile and jump in to make it work out, it often just doesn’t work. Other team members who do have time (some may be very busy doing their own tasks) may not have the skills of the guy who is sick or on vacation.
Indeed, this Agile Reality is true in many instances we’ve found. Especially when converting from Waterfall to Agile the wrong way, it then becomes FRAgile rather than agile. There are solutions to these issues, but mostly they are not method or technically related. Rather, they are cultural- or mindset-related, and changing those two traits doesn’t come without a great deal of difficulty.