[Guest Post] An Outsiders View of Agile Software Development: Part 2

This is Part 2 on Joe Woods’ views on Agile Software Development. He shared with us his initial thoughts on the subject in Part of Agile Software Development – what he likes about Agile Software Development. In today’s post, he shares with us what he finds as problems with agile software development. He shares with us a few things he doesn’t like about Agile, sometimes compared to Lean for Software or Kanban Software Development.

Enjoy the post.

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.

About Joe Woods

Joe Woods is one of the top SEO and Internet Marketing Specialists in the Southeast US and has worked with Agile and Scrum since 2007. Joe currently works with Version One and many of the industry’s leading Agile coaches to help IT teams and practitioners evangelize the many different process from Agile, Scrum, XP and Kanban.