The Agile Buzz

Agile is one of those buzz words that IT managers, business execs, and everyone else love to use in conversation. However, I have yet to meet more than a handful of people who ever really knew what Agile really was; more importantly, how it could and/or should be used at their company. This is not going to be another "Here is the definition of Agile; go forth and use it wisely, as great knowledge of definitions comes terrible application of that term". Okay, just killed the quote, whatever. I am going to focus on the why your company should consider Agile, a hybrid, or just drop the darn buzz word and get work done instead.

If you want the definition of Agile, go to Wikipedia or search for Agile Manifesto. That should be a good start.

If you are a software development company, I will argue until I am dead that you should be using Agile. I have been in highly regulated environments and can argue agile's benefit in virtually all cases. I can also argue in almost all cases that the cost-benefit will be so shocking in the long run that you would be squandering a small fortune by not investing in Agile.

But I don't care about the software development companies...if they don't at least know what agile is and have made a conscious decision to use or not to use it, then they probably have far bigger problems they need to focus on...I can help you with that if you need. Who I really care about is every other company out there that has an IT department or technology team or designated "tech" people that need to write code in order for the business to function. For example, if you have a database system or data warehouse and need to write SQL to pull out data into spreadsheets....or write code to pull the data into a BI tool such as Cognos. I do want to note that Agile can be applied to business processes and just about anything, but there will be plenty of post for that later...I could probably write a book series on this.

Anyway, let's discuss how Agile can help you. If your company is broken into a bunch of silos, groups don't work well together, there is generally poor communication, and/or the culture is that people cling to their knowledge and refuse to share and play nice, then I highly recommend you not only throw out the idea of Agile, but don't even waste your breath with the word until you have fixed your other issues first. This is the short and easy one.

If your company still has any of the above issues, but they are minimal, or non-existent (yay), then you should consider Agile, or at least a hybrid. Since it would take too long to cover all uses for Agile, I am going to focus on something all companies need and use...reports. If you want examples for development related to operational systems, shoot me a message and I'll write up something for that.

One thing to understand is that a huge benefit of Agile is delivery of something that will provide immediate business value. Let's use a financial report for our example. Here we go: the business needs a financial report that will show a financial snapshot of how the company is doing in regards to operational costs, sales figures, profits and losses, and trending against competitors. Let's ignore the BI piece of this for now, since my BI people are going to scream dashboard.

The reporting need that I just wrote is very generalized and contains tons of top-level requirements that could technically equate to dozens of smaller reports, each of which could have dozens upon dozens of requirements. If we try to tackle this the old-fashioned way, then we would get a project manager, do a cost-benefit analysis, figure out resources, get an idea of complexity, and put together some insanely large Project outline that has about as much chance of being met as I do winning Powerball.

Let's break this up. Let's ask what the most important piece of data is. Maybe there are a few items...so let's rank them if need be. Either way, we want to start with one item. For simplicity, we are going to focus on sales figures for each of the company's products in each division. Again, for simplicity, we are going to assume that our data is in a structured source and we don't need to worry about where to get the data from. So, my first User Story is "I want total sales for all products company-wide for last year." This is something I can write some quick SQL for and get an immediate result and a manager can use that data to make business decisions. Wow that was fast and simple. I already have a deliverable and I haven't even broken a sweat. Now my next user story will be "I want to see total sales for each division for last year." Great, some more SQL and I have another deliverable. Now I can take both sets of data and plop them into a spreadsheet, or PowerPoint, or whatever and I now have the beginnings a of sales report. We can then get more detail from there and with each user story, or building blocks as I usually call them, we can keep building our report without affecting the currently useable product.

I have probably oversimplified this to no end, and you are probably saying that all of this is common sense. I would not be able to dispute that. However, I would then probably point at you and say how often does this actually happen at your company? And the common response would be "Well, it's more political than that and there is lots of red tape, blah blah, etc."

But here is the reality, if you have the culture to support Agile methodologies, then what I just described is really that easy for your company to implement. Of course you will need documentation, of course you will need detailed workflows to follow, and of course, like implementing anything that is different from the norm, you will have push-back.

One final touch-point I want to leave you with is that Agile may not be right for your company. Maybe it is the right thing to use, but it wouldn't be cost effective in enough time to allow for a proper budget to be assigned. Maybe the culture just won't support Agile without "changing the world". Or, maybe Agile is the perfect fit and it's time to go for it. Either way, you need to know what Agile really is and how it can be used as a tool to improve your company; otherwise, you are just tossing around buzz words and ultimately causing more headaches for everyone.