Spaghetti Agile

In my recent article, Agile is Stupid, I mentioned a situation where the Product Owners were completely “pulling the rug” out from under the development team after each iteration and would completely change directions making the previous Sprint’s work obsolete. That, along with some recent conversations, has prompted me to think about some common practices that I would refer to as “Spaghetti Agile”. The connotation being that, similar to throwing spaghetti against the wall to see if it is done (if it sticks), these companies are just throwing practices at their developments teams and seeing if they work, and if they do they call it Agile.

Here are a few examples:

Two Week Sprints – Yes, this is a common Agile practice. However, this practice doesn’t make you Agile. Anyone can timebox work into two week increments. You might even be able to predict or estimate how much work you will be able to get done in that time. But if the company doesn’t value consistent estimations over time to help the product team to forecast the value they will get in a Sprint so that they can plan a product roadmap and prioritize the backlog accordingly, then they are missing an opportunity. Or if the product team completely changes direction every two weeks the delivered work will have little to no long-term value and the development team will experience a lot of frustration and wasted time both in throw-away code and context switching. Also, if there are consistent interruptions to the Sprint then it loses its value. Yes, emergencies sometimes happen, but Sprint interruptions should never be common-place.

Daily Stand-ups – We all know the quarterly company “state of the union” type meetings that developers just love to sit through. Imagine having a miniature version of this every morning for 15 minutes. This is just one of the mis-uses of the daily stand-up that I’ve seen. Another would be having an entire development team, say 30 people working across 5-6 different products, give an update every morning of what they did the day before and what they plan on doing today. How effective would that be? I can tell you…not very. The purpose of the Daily Stand-up is to encourage collaboration and communication. And there is a reason it is called a Stand-up. Please don’t fall into the trap of sitting around a conference table to have this meeting. I’ve worked in situations where that was encouraged and people tend to tune-out more and the meeting drags on. Keep it lively and up-beat and to-the-point. You might even be able to finish with plenty of time to go and give valuable time back to the development team.

 Retrospectives – These meetings are meant to be a time for the team to reflect on what went well in the last sprint, what could have gone better and what they want to start or stop doing. The purpose is process improvement. Just last night I heard about a team where they were instructed that they are not allowed to call out anyone individually in a retrospective. While I understand that direct feedback can be uncomfortable, if a person’s behavior is harming the team (or helping it) how can the process be improved unless the team can be transparent? Respect and trust are key for this to be possible. But vagueness and generalities will kill the effectiveness of a retrospective faster than just about anything else. I will quickly mention a few other examples…if only the Scrum Master speaks during the retrospective, if the focus is on metrics and not process, or if the focus is only on the things that went wrong and not on what is working (and why).

Agile is a mindset, not a set of rules, processes or practices. If a company thinks they will be able to drop a few new items on a checklist of things the development team must do and quickly get the same results as a company that is fully committed from the top down to practice Agility, they will quickly see that they are bound to fail. There must be a corporate culture that encourages, supports and understands Agile for success. Unfortunately, this still seems to be one of the greatest challenges we face in the Agile community.

I’m sure many of you have experienced “Spaghetti Agile” in your workplaces. I’d be interested in hearing some of your stories, and if there is a happy ending of how things got turned around I’d love to hear that too!