Is Agile Worth It?

Posted: July 30, 2012 in SQLServerPedia Syndication

Over the last few months I have been tossing this exact question around. I have been debating posting about it, and I have even talked with a couple people about it.  But today, I saw this blog post on UTest that got my brain churning.  The hesitation that I have had about posting this comes from a couple different thought points, but most of all I am not interested in creating some sort of development methodology war (you would not believe some of the flame wars I have seen just over naming conventions). I want to make sure that I expressed my paradigm, so my statements might be understood correctly.

·      I have only worked in an Agile methodology for a few years, and in one organization.

·      I am not a student of the Agile methodology so what I am seeing just might be a morphed version.

·      My opinions are based on my experience.  I would love to hear what you see with this methodology, and what your opinion is.

·      I am an administrator by practice, I have done development, but not in this methodology. 

·      I am not in the same chain of command as the developers, although we do have a common VP.

What is it?

I debated even including this section, but I felt it fair for everyone to understand how I am seeing the processed used. 

·     Every 2 weeks is a Sprint.

·     Each Sprint is preceded by a meeting where the group looks at the tasks, and determines how long a  task might take, and how high of a priority it is.  At that point they determine if the task is going to be included in that Sprint. People included in this are developers, management and a few other key players.  The visibility is very transparent.

·     Each day at the start of the day a stand up meeting is held.  This is so the resources can talk about what is getting in the way of completing tasks and to update everyone on how well the task progression is going.

·     If a task is going to take longer than 2 weeks, then it is broken up into pieces to fit in measurable smaller tasks.

·     I believe anyone can add items to the task list.  However, just because it is on a task list it does not mean that the task is going to get done.

My View of the Pros

I am really impressed by how fast the developers that work with this are. This group is an outstanding group of very talented developers.  The amount of work that they are able to accomplish and the quality of the work is impressive for organizations twice the size.  The process allows the developers to commit to an amount of time a task is going to complete, and I imagine that with the daily stand-up meetings, they don’t feel Micro-Managed. I have been in roles where each day managers want an accounting of how you spent each minute. For me, this is not a good way to be productive, so I see the daily stand-ups as a true positive. Developers have an input on the priority of tasks.  So if there is a bug in an application, and it is not impacting anyone, they can make sure that the correct priority is set to the fix. My overall impression is that this puts a lot of control in the developer’s hands and I think this is also a good thing.

My View of the Cons

As an administrator, much of my job is getting ready for the future; this could mean that I am looking at information for 2 weeks down the road, or 2 years down the road. Tasks such as forecasting storage requirements, planning for future upgrades, outages and many other tasks of the like.  The other aspect of DBA work is that I am a working on break fix issues, so normally I spend most of my time working issues today or down the road a bit. 

·      If there is a task which requires the assistance of a developer, and they are required to submit a task item for it, I have to wait until the next Sprint. This does not happen often, but it can happen.

·     When a developer might need me for a task item, the time frame is also applied.  This has never really become an issue, but it does go both ways.  If I am in the middle of a big project and it is different than a project they are working on then we might not always be able to commit the same amount of time.

·     One of my biggest concerns working in this methodology is the amount of time before new tasks are reviewed.  If I take a new database design into consideration, there could be a bit of time that needs to be spent on evaluating if I use one method or another. The review method I decided to follow is to take a step back, look at the future plans as I understand them, test potential solutions and then execute on the decisions. Maybe it is just me and my personality, but I look at things from a long term perspective.  It could just be the nature of my work in comparison to the nature of development work.

·     Priorities are set based on what is most important at the time of planning. From first look, why would you not do it any differently?  If you wait until everything is the top priority then isn’t that working in a re-active mode?  For example:

o    If you wait to quit smoking until the Doctor says you have COPD, then isn’t it a bit late?

o    I have a son.  He just finished his first year of college and is well on his way.  When he was younger, and he would have a paper due then we would try to do a little each day, however as other school work would appear, or a friend’s birthday party would come up it was easy to prioritize the paper under something else.  If it was not the pressing issue, it can be done a little later.

·     I am not sure if this is related to the Agile method, or would be just as much of a concern with any shop.  If, as a task submitter, I am not part of the planning meeting, then there is an impression that a “Sales” job needs to be done.  Is this a drastic way to look at it?  Sure – I guess, but end result is that with a number of people reviewing and prioritizing, then many people have to understand the importance of a  what could be a pretty technical discussion. 

Like I mentioned before, these are really just some thoughts,  I wonder if they are just related to the implementation I have seen, or if others see these as well. 

  1. way0utwest says:

    Take a look at this. It’s very interesting.

    I think that’s more of what I did years ago than Agile. We had one week sprints, and deployments, but we did have work that took 2, 3, 4 weeks. We made it a series of sprints, with essentially no deliverables, but a re-set of our time expectations for those items. However if possible, we carefully broke things into parts and fit it into one week.

    As an example, we might have a DB change with a code change for the app. There were times the coding took longer, and if we were confident of the db change, we’d slide that out this week, as a no impact/no feature change to the db, adding in the code change the next week so people could see the feature.

  2. Chris Yates says:

    Ironic that this post came across my phone the other day. Where was I at? Standing in one of our “stand up meetings” we just started about 2 weeks ago. I’ve been privy to the waterfall methodology and also the agile methodology – which do I prefer??? I believe from my standpoint in current time I would lean toward the agile methodology.

    One of the biggest reasons I lean toward agile is for the ease of adapting to change. It is designed to cope and adapt to new ideas from the outset, changes to systems and programs can be modified without the entire process being re-written.

    A few more reasons why I like Agile:

    1. What you call sprints I will call deploys – but at the end of the day they are related the same way. At the end of each deploy or sprint there is a percievable launchable product. Bugs have been caught and/or eliminated (we can hope) through a rigorous testing cycle; in my old shop that used the WaterFall methodology the product was tested only at the very end – what did this mean for us….a plethora of bug generations.

    2. Agile can have numerous releases whereas in my case the Waterfall had one at teh end. I’ve found that because of the multiple releases it keeps the customor base more satisfied.

    3. Agile makes more sense to me in having several little projects within the big project being completed at the same time by perhaps different programming groups. Also, if specs change it is more easily handled in my eyes in the Agile methodology.

    These merily what I have come across in my years of experience; both have pro’s and con’s. I do enjoy the Agile approach both from a developer standpoint and as an Database Administrator.

    • Chris Shaw says:

      Thanks for the notes Chris. I think those are all great points, and I have to admit that I do like the idea of small checkpoints along the lines of a project. There are some true benefits there. Maybe what I am missing is the relationships between the sprints.

      To be fair, I am not part of the development process in this shop that I am speaking of, so I may not be seeing all the true benefits that could come out of it.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s