As someone who has worked in Agile environments for the last 6 or so years, I’ve seen a lot of situations where this methodology is actually quite useful. However, it isn’t without fault. Even the creators admitted that the Agile methodology has failed.
There would need to be some changes but I firmly believe all is not lost for it!
I have identified 5 solutions to 5 common problems Agile faces:
1. Decide on a format
The main problem Agile has is its somewhat inconsistent format. Here are but a few ways in which I have seen it implemented in teams:
- with a business analyst
- without a business analyst
- sprints that lasted 1 week
- sprints that lasted 4 weeks
- sprints that last a vaguely defined amount of time between 1 and 4 weeks
At this point, as a developer, it’s really hard to understand what is expected of you. And no amount of adaptability will help you be productive in such inconsistent environments. It’s very easy to get distracted and lose both momentum and productivity.
The ideal format that I have found has the following traits:
- 2 week-long sprints, that start on Monday and end on Friday; only change this when holidays occur but never delay ending a sprint to the next week; end it earlier and plan accordingly
- with a business analyst if a project is large (e.g. an existing application that’s already in production); without a BA if the application is new or very young (a maximum of 6 months old)
- if a project requires a team larger than 5 members, there needs to be a dedicated Scrum Master to deal with administrative issues; I feel a Project Manager fits this bill perfectly
- changes in the backlog should be no bigger than 10 story points from the first estimations, meaning that in the end, you should have a maximum of 10 story points above or below the initial total number
- standard definitions of ready and done, with a task being considered complete once it has been analyzed, developed, reviewed, tested and of course approved by the client
- code reviews should take no longer than 15 minutes per task
2. Enforce a backlog freeze and stick to it
The sprint planning meeting is the meeting that decides what is to be done in the current sprint. The result of that meeting is a backlog of tasks. Once the 3rd day of the spring has ended, there are to be no changes allowed to the tasks. Any and all changes to the backlog need to be done before that. They also need to respect the whole 10 points criteria from above.
And I don’t want to hear the “but it’s a priority” excuse. This needs to be decided in the sprint planning meeting. And if something urgent actually shows up, the 3 days and 10 points rules still need to be respected.
3. Let go of “complexity measurement”
Measuring the complexity of something is impossible. Freddie Mercury considered himself to be a mediocre pianist. Yet your average listener will think Bohemian Rhapsody is a very complex piano piece.
In the end, it’s all about how much time you’ve worked on tasks. In short, the whole “story points determine complexity” should be replaced with “story points determine the necessary time I think it would take for a member of this team to finish the user story, and by finish I mean everything from development, to review and testing”.
4. Drastically reduce the time spent in meetings
Meetings are the main enemy of productivity. Especially when they are never-ending. Sprint planning should take no more than two hours. If no one can decide in a maximum of 10 minutes on what a story is about, drop it from the sprint.
Daily meetings should under no circumstance last more than 15 minutes. Impromptu meetings should be kept at a minimum number and duration. Think 1–2 such meetings per week that should last a maximum of 30 minutes.
5. A clear understanding of each person’s role
Another confusing aspect for developers and other people is with regards to their own team. Specifically, there needs to be a clear understanding of what role each person in that team serves. Everyone needs to know who the developers are, who the managers are and who the Product Owner is.
Also, everybody needs to know who they can ask for clarification regarding the task they are handling. In other words, there needs to be someone who has the final say regarding the output of the task. In my experience, it’s usually the Product Owner (or Owners).
Another thing I would add here is to not shy away from delegating. In other words, if the project would benefit from a dedicated person for a certain role, then, by all means, do it. Making someone be responsible for doing software development, being a team lead and a Scrum Master is going to end badly. And telling them to be a developer 80% of the time, a Scrum Master 10% of the time and a Team Lead the remaining 10% is even more confusing.
Conclusion
These are but a few things that may go wrong with Agile. I am not really against this methodology, as I do feel that it has its good parts. It’s just that the bad parts tend to go haywire pretty fast if you’re not careful.
When Agile is done properly, organizations can continually find ways to increase the value to their customers. It gives more meaning to those who are actively working on the project and creates a more positive experience for the customer, producing more generous results for the company.
