Agile Gone Bad - 3 Signs You Are Doing Agile Wrong

Are you “doing" Agile or is your organization “Agile” or somewhere in between? This article points out three scandalous behavioral signs of Agile Gone Bad. Essential being Agile is still challenging, since it involves cultural change from the top down and bottom up. If it was easy, you would have already implemented an improved delivery model right at its inception and all your releases would be on time and the software would work well.

" Culture eats strategy for breakfast. "

- Peter Drucker

Essential being Agile still requires the training of your leaders at the enterprise level for all key stakeholders (including the CIO, the CTO and senior executives), as well as everyone else at your company. Most companies do not train well they just assume that everyone gets Agile these days and you end up with a hybrid mix of Agile, Kanban or “AgileBut.” Which means yes, we do Agile but…. we do this too and dropped that and do it the way our Devop team wants it done. When you try to implement Agile this way you are almost guaranteed to fail and go back to Waterfall.

 Worst yet, you have a VP of Engineering totally into Agile and one who gets it, promotes it, and the teams are Agile.  Then he or she leaves the company and a new VP is hired who operates based on Waterfall and your Agile concepts at your company vanish overnight. Your teams get frustrated and people start polishing up their LinkedIn profiles and taking a lot of “work from home” days. Epic fail. There is no shortcut for training and getting a full delivery commitment, but at least there is a "quick start" approach to recognizing a few of the signs of Agile gone wrong. 

Here are three signs that you might be doing Agile incorrectly - Agile Gone Bad:

Best Practices (One Size Does Not Fit All) - The Snowflake Effect

One size does not fit all. I like to think of my team members as Snowflakes (Note this is truly comparing folks to snow and the crystal snowflakes that are all unique.) There is no snowflake ever created the same. They are all different, unique yet each one an individual that combined with thousands and millions of other other individuals to blanket our the ground with fresh and fluffy white snow. There are no such things as universal “best” practices. What works well for one team may not work well for another, even at the same company, even on the same project. Everything we build is a unique snowflake of design and circumstances; every team a unique combination of personalities, skills, and environment. Read about practices that have been effective for others, give them a trial run if they seem applicable, but don’t automatically adopt them because some authority says they’re “best.” Someone else’s “best” practices may be your team’s straitjacket. Employee engagement and job satisfaction could go right down the toilet.  Recognize the beautiful and unique Snowflakes and don’t force "Best Practices" on everyone by saying, “This is how we did at Company G or Company F so it must be the best practice and only way to do it.” We are innovators, disruptors and movers and shakers in Silicon Valley thus, we should use our collective brainpower think outside the box to solve the world’s greatest problems and release code and software that works.  

Never-ending Early Stand-ups - KISS

Keep It Simple Silly (KISS) is the best piece of advice I have for daily stand-ups. No-one likes extended and early meetings. It is easy for stand-ups which are designed to be brief to become long and drawn out meetings.  Be brief, be prepared and most of all don’t blow these off, you need to attend whether you are in person or using Skype to attend the daily stand-up. Most teams don’t like 8:30 AM daily stand-ups either so I recommend doing them late morning or before lunch for maximum attendance and the least path of resistance. 

Use simple statements about things the entire team should know -- what you did yesterday, what you’re doing today, and any blockers or help needed. In addition, a sentence or two on what you’ve learned can be helpful. That is it. Simple.  You may do this round-robin, you may do this by “walking the story wall” or however your team prefers. Some teams like to do it standing and near their story wall so they can visualize the sprint and see work in progress.

Stand-ups are not created for technical discussions, making decisions, proposing designs, swapping war stories, reorganizing a sprint, or doing anything other than communicating what’s necessary for group coordination. Take those conversations offline.  Come prepared, so you can listen to what others have done and are doing and decide if it’s relevant to you, instead of thinking about what you’re going to say. Anything that comes up outside of the mutual status update should be deferred to a huddle or email. A stand-up should take no more than 15 to 30 seconds per team member. Quick, easy, painless and a good way for the team to come together and stay engaged with the sprint. Daily stand-ups identify blockers that might be slowing your team velocity down. Thus, you can take action and have an offline conversation to remove any impediments that are discovered during the daily stand-up.

Comparing Velocities Of Teams Or Individuals

Most programmers are obsessed with metrics and data.  But if your team considers velocity, the (average) measure of story points per iteration at the team level used in sprint planning, as a point of comparison, you’re doing it wrong.

Again, velocity is a neutral metric intended only for estimation. Comparing team velocities is meaningless because the basic unit (a story point) is “defined” differently for each team. It is an arbitrary number that is done this way on purpose so teams can estimate time based on story points and not time so their feet are not held to the fire from management who might use it as a dreaded “TPS report” from the movie Office Space or time tracker. Because teams are unique, comparison of velocities has no value, and doing so can encourage negative behaviors and inner team competition instead of cooperation.

The same goes for individuals that make up a team. The individual’s contribution to the story point effort is fractional. And, as above, story points themselves are not metrics. Comparing velocities of individuals, even on the same team, is meaningless. The only metric that matters is a subjective metric: value delivered via working software.

The easiest fix for this: Stop. It is a waste of time and counterproductive. The exact opposite of the true goals of Agile and the Definitive Guide to Scrum.

Now that you are aware of a few of the pitfalls of implementing Agile at your organization and how it may be going wrong you can work towards fixing these challenges.  When implemented correctly Agile works very well.   Please feel free to comment below and give any other examples of Agile Gone Bad at your company. Inquiring minds want to know about outlandish behavior and experiences with Agile at your company. Do tell...