The concept of Agile teams is a something that can be freeing. It’s an ever rejuvenating approach to creation and can be great to make large project manageable. You can apply the concepts to all kinds of planning.
For example, I use it for how I outline what I write. At certain stages, I reevaluate my outline, readjust, and rewrite. I update my method after each use, discarding what didn’t work and keeping what does. Maybe I’ll add in a new element that may work better.
If you have seen Brue Feiler’s TED talk on Agile Families, you can see how it can be used to teach your children how to evaluate a situation and plan for goals. If you start young I can guarantee your child, barring disability, will be using these methods to plan out their days, from class choices, to daily activities. I didn’t have a name for what I was doing with my daughter then, but yeah it works. She can make an informed decision about her time, back it up, and reason out pros and cons. She can also deal with consequences because of the process. She has a sense of choosing between two things she loves and realizing she can’t have everything. She’s 16 and she’s improved on this skill every year.
I have yet to work for any company that was able to apply Agile as whole. In fact, even though the company may claim to, most are not Agile at all. They just gather up the buzz words and then use Agile as an excuse to run teams into the ground with poorly planned, rushed projects. They don’t learn or regroup. Oh they pretend to, meeting after meeting. But no. Like as not, your team may not be Agile.
Here are the signs that your team, company, or whateves, is not Agile.
The first sign of any lumbering juggernaut of doom is management. Let me first define management. That is any group of individuals who pass information from the thinkers to the doers. They act as gatekeepers, keeping devs and creators apart, siloing their groups into little terrorist cells. The first sure sign that you do not have an Agile team is that you have more managers than anyone else.
Management is Nontechnical and Anti-Communication
People don’t like what they don’t understand. When you get a set of Management that does not understand what they are managing you get a formula for resentment and misunderstanding. In order to make up for their lack of understanding, they start trying to dictate who can do what when. Picture that for second. You are an angry individual with no sense of control. So you tighten your grip. You force people to come to you instead of each other. You are the gate keeper after all. You start assigning tasks. In my experience this is how you get the SQL guy on HTML duty, and the Java dev on Photoshop. Remember they don’t understand the tech, and they must be in control.
Meetings for Regrouping Lead to More Regrouping
Dev are often shut down for want to respond to change. Instead they are told that we’ll come back to that later, or that it’s for another time. That other time never comes. And if you’re the one who steps forward and pulls the stop whistle on a crashing train, they consider you to be the problem.
Clients are Allowed to Change Outside of Scope
One of the core principles of Agile is that requirements are on going. There is nothing wrong with that. However when clients, managers, or random bob who walks by, gives changes because they want to try random new things (green is the new blue, Larry!) or because they personally have a gripe with another college, things get bad. Changes still have to be kept in scope. They have to be kept on deadline. If not then the deadline must be agile as well, or changes pushed to the next iteration. Stick a gate keeper in the mix and suddenly you can add miscommunication in there as well.
Do It Again Becomes the Mantra
We all know the definition for crazy right. Doing the same thing over and over again and expecting a different result. If you find yourself doing the same project over and over again, with no change, not analyzing, no comparison, you need to stop. Fake Agile teams will fall right into this trap. Deadlines will come faster and faster, as the same content, code, and message are recycled again and again. As each failure mounts, they just pile on more projects, following the same formula. And what happens when you speak up? Say hey, why are we doing this again? You will be told that you just don’t understand. That maybe it’s too complex for you.
Just Do What You are Told
No questions. No Answers.
Daily Stand Ups Become Daily Orders
Instead of reminding, stating daily goals, and identifying roadblocks, team members are told only to listen and are given marching orders. Another meeting might be set up to deal with individual items but often, the wrong people are invited or there is no time in the day for another meeting.
Documentation is Used to Replace Dev
This is a big one. Heavy use of documentation given to just any person does not make a dev, but if the team believes it does well…
Difficult is used to Trash Necessary Changes
The teams always take easy over right and essential changes. A security fix that will keep the database intact maybe necessary but if it’s difficult the team will drop it, even if the risks are in the red.
Improvement is Discourage Because It May Have Risk
Refactoring is discouraged. Improvement on process and design is ignored. Change is not embraced.
Yes to the Client, No the Dev
The client is told yes. The dev is put in the no corner. Client says to start over on day 10. Yes. Dev point out security breach, they are told to keep on and we’ll get back to that. While there are always times this must happen, if this is norm, Agile is probably not the team’s priority.
Waterfalls are Illogical
A waterfall should be a path of build a straight line right into deployment and maintenance. They should follow a logical succession of steps. But if your waterfalls are a mess…code before assets, database specs after build. You’ll just be redoing all work at each step.
All these thing build on one another. Just because you are an Agile team you should be constantly under a deadline that you cannot make. You should be piled under work. Unfortunately mostly places use the words but don’t follow any of the principles. That’s what it all comes down to in the end. And maybe not all teams need to be Agile but I’ve found that pretend Agile teams lead to a toxic work environment. You become bombarded with impossible tasks and deadlines with no way to improve on the process.