5 problems with Agile…and how to solve them

The following sentence will come as a shock to you…I don’t like Agile. Now I don’t know where someone would get that impression, I mean I did write some other articles about it, right?

However, I am not a fan of the saying “you can’t polish a turd”. Agile can be improved tremendously, but there are some issues which need to be addressed. And I am here to talk about 5 of them and to provide some solutions that no one will listen to, because I am not some rich ass celebrity, therefore I don’t know how things work, right? Wrong…

1. Decide on a format

There are way too many ways in which I’ve seen Agile being implemented in tech companies. Two week sprints. Three week sprints. With a business analyst. Without a business analyst. What’s a developer like myself to understand from all of this? And I don’t wanna hear “ugh, but you have to adapt, it comes with the trade”. Yeah, I have to adapt to different changing techologies. If you force me to adapt to a million different ways to work, then my productivity will go down almost as fast as my will to live.

It’s very easy to get distracted and lose touch with working correctly when everyone does things by ear.

The ideal format that I have found has the following traits:

  • 2 week long sprint, start Monday, end 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 BA 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; the bes way to do this is to have a Project Manager (I don’t remember if pure Agile required one, but having worked in projects without a Project Manager, he/she is very much welcome)
  • 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 analysed, 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

When clients here about Agile and how it’s all about adaptability, they interpret this as “ha, let’s fiddle around with the task and change priority mid-sprint, these suckers should adapt to our every need and desire”. And tech companies lay there and take it because they’re pussies.

However, there needs to be a time limit for these changes. Once it’s passed, the backlog DOES NOT CHANGE. As a limit, I think the 3rd day of the sprint, at the end of the working day of course, is a reasonable time limit, because people have about two and a half working days to figure out if they’re capable of finishing their work and the client should have enough time to figure out if something needs to be removed or added, based on priority. Also, when everything is a priority, nothing is. Some stories have to have precedence over the others.

3. Drop the whole “complexity measurement”

You ever hear people arguing about how one character in the movie is more complex than another and if you ask them why they give you an arbitrary set of reasons? The same goes for measuring the complexity of a user story. It can’t be done. And in the end, it’s all about how much time you’ve worked on it. 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

These meetings eat up so much of your time it’s embarassing. Sprint planning should take no more than two hours. If the client doesn’t know what he wants, it’s his problem, not mine, and I shouldn’t have to waste time on it. 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.

5. Separate people for key roles

I’ve mentioned this before. If a team has more than 5 members, there needs to be a separation in key roles. You can’t have a Team Lead that is both a Scrum Master and a developer/tester, because he will do both these jobs bad.

In even funkier tech companies, you have Team Leads who are at the same time Scrum Master and Line Manager for people in the project. A senior person should ad the worst be Lead and Line Manager or Scrum Master and Line Manager, since Line Management is not a heavy burden on time.

Conclusion

And there you are, 5 solutions to 5 common problems I’ve seen in Agile projects. Of course, the list would go on endlessly but for the time being, this is all I’ve got.

Needless to say should I bring this up with people in tech companies no one would listen because why would they? The high ranks in these organizations are so far up their own backdoor it would take a miracle for them to admit they were wrong.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s