What’s all the hype around Agile?
Is agile development something real, or even worth learning? Is being an Agile Business Analyst a joke?
In this video, I tell you exactly why Agile is over-hyped, and where to focus your time and resources as a Business Analyst, rather than wasting it on learning the pure agile methodology.
Episode Transcript (Edited)
The Agile Business Analyst
So in the I.T. industry, there is a lot of marketing hype around agile.
Agile seems to be the buzzword of the day.
If you’re somebody who’s just getting into business analysis likely you’ve gone to Google you’ve tried to do some searching to try to figure out what skills you should learn and you’re going to be inundated with agile training agile products for Agile Methodology everything seems to be agile.
I’m going to tell you something in this video that you’re unlikely to hear almost anywhere else and that something is that, you should spend very little of your time trying to learn agile methodology.
The reason why I say that is that when you hit the ground and you start to find work and you start to get to know, and actually start doing work for your clients or for your employer, you’ll find that there are very few companies out there that actually use agile.
They may be agile in name but the majority of companies out there run either purely waterfall projects or they run projects that are an agile hybrid of a waterfall of the Waterfall methodology.
So if you listen to the industry hype you’re going to spend an inordinate amount of your time and your resources learning something that you’re not actually going to be using in reality.
My Advice – This Is What You Should Do..
What you should do is learn enough agile to be able to speak about it intelligently when you’re in an interview recognizing the fact that when you get into that company and you start working for them it’s very unlikely regardless of what the employer claims or what the industry hype says it’s very unlikely that you’re going to be in an Agile environment.
The one exception to that is if you know that you want to work for a software company. So if you want to work let’s say for a big software company like a Microsoft or a Google or even a lot of the smaller software companies the likelihood of you doing Agile there is very high.
Outside of that those type of employers that are just purely software companies the likelihood of you running into a pure agile environment is close to zero.
So learn only enough agile to be able to speak about it intelligently learn the skills that you’re actually going to need to use which is an either purely a waterfall or a hybrid waterfall some variant of hybrid waterfall.
And I’ll talk about that more if you know what I mean by hybrid or If you want to know what I mean when I say hybrid waterfall.
Alright, Let’s Get Into This Matter
Let’s get into the subject matter of this video which is:
- I want to talk to you about what Agile is, and what Agile isn’t to help you clarify a lot of the confusion that exists out there about what agile actually means because it doesn’t mean what you might think it means.
- Then I want to talk to you about the types of products where it makes sense for the agile methodology to be used.
- I want to talk about the cost of actually going agile because trying to switch from one methodology to another is not cheap. It’s certainly not free. It’s not something you can just do on a whim.
It takes a lot of effort a lot of political will and a lot of financial costs for companies to make the switch from a Waterfall methodology or whatever methodology they’re using now into going into one of the variants of agile.
1 – What Is & Isn’t Agile
So first point, what is agile? Well, let me talk about what Agile is not.
Many employers out there are sold on the idea that if they go agile they’re going to be able to deliver the exact same scope of a product much more quickly. That is the incorrect definition of agile. That’s not what Agile was designed for. That’s not what agile does, as a methodology.
What agile does is it gives you the ability, it gives your employer the ability to look up the entire scope of a project and then to divide it up in a way where it makes sense for them to release a certain portion of that entire scope much earlier in the process.
So what you’re doing basically instead of delivering the entire thing at the end you’re dividing things up in a way where you’re saying what is it that we can deliver what useful functionality can we deliver to our customers and or to the business, earlier than we would if we had it in a waterfall project.
And those two are very different things. But there’s a huge misunderstanding of what agile actually does. So agile does not let you do the same amount of work faster. It lets you get a smaller portion of that solution out quickly so that you can build the rest as your clients are using that smaller portion.
So in agile, you have the concept of an MVP for example of a minimum viable product.
The MVP is that first release that your project is going to do which is the bare minimum that they would need to actually have a useful product for them. And so the MVP changes from product to product.
I’ll talk about all that in a different video but what kind of products does it make sense to use agile on?
2 – Where It Makes Sense To Use Agile
First, the type of product that your employer should be using agile on are products that are number one, they are products where the MVP is actually possible. It’s not always possible just to have an MVP for a solution that you’re delivering. That’s the first condition.
The second condition is if you have a product that is going to be constantly evolving over time and that you don’t necessarily know exactly what the end product looks like.
So if you look at a company like Google, for example, Google has let’s say any of their products Gmail. Right. Didn’t release a product called Gmail when they released it a decade ago, they had no idea that it was going to be looking the way that it does because what they’ve had to do is they have to release their minimum viable product and then they have to constantly refine it given the competitive pressures that exist given what their customers are saying. And a lot of other factors that they’ve had to take into account.
Gmail has now evolved over the last decade to become what it is that you see today. Right. Most software companies are under that kind of competitive pressure and that’s why you see a lot more agile in software companies because software companies a lot of times don’t really know what the end product looks like.
They’ll say let’s get the bare minimum out there and then let’s just understand the market conditions that we’re under and let’s evolve our product to make it work.
Under those circumstances, you would not survive. They would not survive if they tried to use a Waterfall methodology. They would not have any chance of surviving in the competitive pressure.
Most companies that hire business analysts are not software companies. Most companies out there are either like insurance companies finance companies a whole host of any other company out there outside of software is that where you’re most likely to end up as a business analyst right. And those companies certainly do not use pure agile.
I can almost guarantee you that there is there are a very very minute number of companies out there that are not software companies but do pure agile.
OK. So don’t invest too much of your time and effort learning agile just learn to speak about it intelligently.
The type of products it does make sense for companies to do agile are internal products. So most companies you work for are going to be building products building software for their own internal use for their to do operation improvement internally. And for those types of projects what you want to do is ideally you have a good idea of what the final solution is going to look like. And so you can do it makes sense for the company to spend less overhead, agile has a lot of overhead. Spend less overhead on a waterfall project and deliver it. Right. Or to do somewhat of a hybrid not have a full agile team structure but try to release something to the customer and then try to refine it. But not investing in a full agile methodology it’s like a somewhat of a hybrid agile. That’s what most companies out there try to use.
3 – Overhead Costs Of Going Agile
The overhead is the third point I wanted to talk about agile projects take way more time and effort to deliver than waterfall projects to the overall scope of the solution would take way more time and effort to do in an agile project because of the complexity involved. And I talk about this in less than zero point three of the building blocks program about why that actually is. But there’s a lot more complexity a lot of moving parts in agile projects that just simply do not exist in Waterfall projects and managing all that complexity is not it’s not cheap. It is not it is not certainly not free.
And so all of the extra overhead that goes into running agile projects trying to figure out how to get your team trained well enough to be functioning as a well oiled agile machine. That stuff is that overhead is not worth taking on. If the competitive pressures aren’t there for the product that you’re building. Right.
So, remember AGILE, there’s a lot of buzz around it.
- You do not need to learn pure agile.
- Don’t invest too much of your time and your effort and your money into learning agile if you’re just getting into business analysis.
- Learn the basic principles and then try to learn what you need for the environment that you’ll actually end up in.
So I’ll end the video there but there’s a lot more than I can say about the subject.