Agile is kinda of a buzz word that everyone is throwing around and everyone wants to say they are either doing or want to do. But, let’s dissect it a bit so that it’s clear what it means.
relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
So, that’s what the web tells me Agile means. But, what does it mean to the world of software development? Really.
Something that seems to be missing within some organizations is what is the definition of success for everyone. For an engineer, for an engineering team, for a business analyst, for a business group. I’ve gotta be straight with you here. If you don’t know what that definition is, don’t waste your time trying to make things better by using agile or any other process. I’m serious. Don’t bother wasting your time. Just keep doing what you’re doing. Why? Well, it’s not going to make a freaking difference. It may entertain some folks for a bit, but that’s it.
Just Don’t Get It
Nothing is more painful than trying to tell a team or a company that they need to change something with their processes when they already believe that, well, their poo doesn’t stink. I say that kinda fallaciously, but, the reality is sometimes, the way a group or company has been conducting business, has worked. What I think happens is that something changes, something that tips things from the world of efficient to the world of inefficient. It’s no fault of the folks working at the company, it just happens and suddenly, stuff just isn’t getting done anymore. I mean everybody is working hard, but either they are working on the wrong things or they are floundering, bouncing from one task to a different wrong task.
How Does One Know
So, that brings me to my subject. What is agile? AND, how do you know you are agile? Well, back in the day, agile was following a process, ie… (Scrum, Crystal Clear or etc…). Those days are gone. If they’re not, they should be. All those existing agile processes that are so well defined, well they are just targets for everyone that doesn’t like agile. They regurgitate what the docs say and point out the wrongness of it. Agile isn’t that. Agile is the end result of what your company or group decided to do after starting with a book on scrum. It is that process that you are doing every freaking day that is making the business happy. You and your team are getting stuff done and getting it done in time. That is what agile is.
More formally, let’s just talk about what Agile can be if you want to be successful both internally and externally. Agile is a small group 1-10 of people working together to accomplish a goal. I specify small group because realistically if the group becomes large then the metrics become useless. They are only useful to small groups.
Agile, any agile process can be a beautiful thing, especially in a company that has been suffering from waterfall type process. It does so much. If information radiators are being used, then the management starts seeing things that they haven’t had visibility into historically.
Things such as:
- We need more developers
- Is this more important than X?
- This is going to take our developers how long?
- Why is this being done before this?
Really, this is what agile is all about. It’s about communication between the folks that do the work and the folks that well, ask for it or manage it. Agile isn’t ever a bad thing. I have seen it be bad for small groups. You know, that group that was hired that alway seems to be doing nothing… Agile really puts the bright lights on them. Is that a bad thing? It is almost ALWAYS true, that the ones pointing out the deficiencies with any agile process are the ones struggling to stay busy.
Agile lets a group pivot, pivot from business priority to business priority but in a way that prevents context switching. Oh crap, I haven’t mentioned context switching and I should. Context switching is probably the most detrimental thing that can happen to a developer. Why? Well, it’s not that easy to switch from one code base to another unless you authored both and usually that just isn’t the case.