An Outsiders View of Agile Software Development - Part Two

 

Continuing the guest post article : An outsiders view of Agile Software Development – Part One, here is the second and final part of the series.

This is my view of the agile software development process from an outsider’s perspective. Here’s what I don’t like about Agile or what seem to be the most common issues:

1. You’re doing it wrong…

What I don’t like about agile, now this is just my experience, is that it seems very rigid in many ways. I think too many developers and project managers are way too strict on the process piece. It has to be by the book or it’s wrong and must be done over. Every place seems to do it differently and no one seems to do it the “right” way according to the developers or project managers. I’m not talking about a couple of instances, I’m referring to most places where I’ve worked that use agile. Am I wrong in thinking that agile was created to be adaptive to whatever environment where it’s used? I don’t think there is one right way of doing it, just some basic guidelines and see what works for you.

2. Wording the story

Too many team leaders are quick to throw something out because the story wasn’t written a certain way or the story is too long. Maybe this is a control issue, but it seems to irk some people when things aren’t worded a certain way. Usually when this happens, I have to rewrite the story or break it out. Ok, no problem, but let’s try to be “agile” about this and cut a stakeholder some slack. Developers don’t like the dreaded ‘R’ word (rework) and as a stakeholder, I don’t like having to rewrite things if you can understand what I’m requesting. The process isn’t going to break if the story isn’t worded a certain way.

3. Meetings, meetings and more meetings

The other issue for me is there are way too many meetings that have to take place. Take for example one company I worked at had 3 development teams, 10 developers per team, with one dev team per division. I was a stakeholder in all 3 teams which meant that I had to go to 3 stand-ups every morning, 3 estimation sessions, 3 sprint planning meetings every other week, 3 release meetings, and 3 post release meetings. If I didn’t go to these, then I wasn’t viewed as a team player or supporting the process. That’s a lot of meetings and time considering my job isn’t a project manager for each, but a stakeholder in all. Now I know this is just one company and does not represent all agile shops, but there are a lot of meetings either way. Keep in mind as a stakeholder; I also have reports to create, other meetings to attend and I still have to deal with other departments. Not to mention doing my own job. Let’s try to cut down on the meetings or get the stakeholders out fast especially if they only have 1 or 2 stories in the sprint.

My Conclusions about Agile

What I like about agile is the speed and flexibility to get things done. The process used in the development does matter and can mean the difference between success and failure or in my case job or no job. There seem to be common issues at every place I go. No one seems to do agile right, their words not mine. Writing an agile story varies in different shops, who does the QA is different and who accepts the stories is always completely different. It seems to be a process within a process and learning the nuances is important to get along with the team. Meetings are important, but seem to be overbearing in a lot of ways. Let’s streamline that process if we can and reduce the number of meetings. Overall, I still like agile and there is more sense of a team environment. I can say I owe a lot of my successes to the agile process and I can live with the quirks. From an outsider looking in, it’s not a perfect process, but I think it’s a must have to be innovative and successful in the fast paced internet marketing space.

Photo credit goes to: http://marcestes.com/wp-content/uploads/2011/02/Doing-right-thing.jpg