Agile should die

The "agile" methodology, practices, etc... have been twisted, mangled, and marketed to generate income for those who are good sales people to companies who rely on buzzwords to put them in the top of the Gartner Magic Quadrant. Agile as a "transformation" for a company needs to die.

Usually, I would go and soften the blow of that last statement here by saying, "Well, the concept if done properly is ok, but most places are doing it wrong". That is not the case. It is not the companies that are causing the problem, they don't know any better and they openly admit that, which is why they hire these so-called certified consultants to help them learn. The problem is most of these consultants are technology snake-oil salesman and if they remove one process that is dumb, they consider themselves geniuses and should be charging more because they saw that 10 meetings a day isn't productive. Really? That is your success story?

We need to stop trying to leverage multiple processes to implement common sense. We need to hire people that have the gift of common sense. I thought it was something we all had, but the more I attend meetups, conferences, and various organizational meetings, I  realize it is a gift.

Here are some "common sense" thing that I don't know why exist:

The things to stop doing

• Don't have meetings with 22 people present and only 3 are contributing.
• Don't spend more time on making a decision than it would be to implement the first one. (If it doesn't work after you implement, change it)
• Don't schedule a meeting when a summary email would be adequate.
• Don't jump to a solution when you don't even know what the problem is
• Don't settle on a tech stack before you know what the client actually wants to solve.

The things to continue doing

• Do listen to what the problem is and reiterate to make sure what you heard is what they said.
• Do include technology AND design early on to determine the best path for a solution (for products)
• Do consider your audience for emails, slack, and meetings
• Do have a contingency plan from the start
• Do plan for scale, debugging, testing, and continuous deployment (at least consider it, even for a prototype)
• Do get working code first, then actually refactor it to make it better.  (Motto: Make it work, then make it work right)
• Do eliminate all meetings initially and add meetings back very carefully.

Bonus:

If you really want to make an impact, calculate average hourly rate of everyone attending a meeting, and show how much that meeting is costing the company with everyone there.

 

I thought it was common sense. The people that need to feel important often include a lot of people in a meeting so they can be on hand if they potentially answer a question IF it comes up. How about you not include those people and take the time to interact with directly after the meeting and send a summary email of all the responses. This means, a single person is the project narrator. I love that title. That is really what it should be called. They are the main point of contact for the client, they tell the story of the project to the client and what the client wants to the internal team. They tell the story.

Stop having all of these ceremonies that no one cares about just to say you are adhering to "agile". Get work done, produce something, review it as a team, and then change it. That's it.

I'll write another post about open office spaces and now I'm hearing about free-open-space, so if you get there early, you get a good seat, and no seat is assigned. How's that working for morale?

Thanks for reading my post and I hope this gets you to think about time you are wasting when you could be creating something amazing.