By Derek Neighbors, Published on October 15, 2018
Throw out the agile stand up! Some people love Agile. Some people hate Agile. Few people have actually experienced Agile. There is plenty of Cargo Culting of Agile out there. At the end of the day it boils down to having the ability to “inspect and adapt” for survival. Survival requires improvement. Deliberate practice is the most tested way to improve. Deliberate practice requires metrics and measurement of performance of some kind.
I find most people don’t really want to be excellent. They just want to be left alone because they think they are already great or don’t want to put in the effort involved to improve. Those that perform at the top of their game tend to exhibit the following two behaviors.
- They believe they could perform even better if they worked harder and more deliberately to remove weaknesses or improve strengths. They have a growth mindset.
- They know they need outside help to improve. They often are surrounded by coaches/mentors that drive their performance. Want to get great at something? Get a coach.
7 Arguments Against Agile Ceremonies (Like Stand Up)
Recently I read “You dont need stand up”, which is a well put together case against why Agile “ceremonies” just aren’t necessary. I believe it is well intentioned and echoes many of the arguments I have heard over the years. I used to call this type of philosophy “Sofa King Agile”. The belief being we are so fucking agile already that any process just slows down our agility. It helped that it also spells “So Faking Agile”. I now call it “Chaos Driven Development”. This variation isn’t driven by the superiority complex, but instead by the inability to see any value in process. Fostering organic development amongst trusted adults gets results. Why add anything else? The problem is that these anecdotal experiences don’t jive with all the science on productivity and growth.
So should you throw out Stand Ups, Retrospectives and other Agile Ceremonies? Let’s dive into the arguments expressed in the article.
1. We did this [stopped having ceremonies] and were successful. “We were an extremely productive team that responded to change and nailed every goal we set out to.”
What was the baseline of productivity? Did this approach improve the baseline? Has there been improved performance over time? Success by our own definition feels great, but it may be a complete lie. Imagine being a runner and running a 6 minute mile. That would feel pretty amazing for most people. You would better at running a mile than most people you know, but you aren’t even close to the same league as the best runners in the world (~4 minute miles). I set a goal for having a sub 8 minute mile, when I first started running. I hit it and I was ecstatic. My goal was achieved. I am a fool if I believe that makes a great runner.
2. Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
Physical boards largely remove the sync problem. If you aren’t using data during your stand up, you have room to improve. Information should be updated in real time during the stand up. If you are using all digital tools, maybe switch to a digital stand up? It is easy to evade pathways that increase accountability in the name of freedom. Don’t underestimate the importance in transparency of work outside the team.
3. Stand up ENCOURAGES plans to change daily. Lack of consistency is a great way to ruin developer flow.
The world changes pretty frequently. Daily doesn’t seem too invasive. Good days and bad days exist. Being able to interrupt and course correct is crucial. Imagine trying to lose weight without measuring food meal by meal, day by day and only relying on stepping on a scale every quarter to be successful. It may be possible, but not very likely. The same goes for software development.
4. Stand up forces every team member to be productive at a set place and a set time
If you want to go fast, go alone. If you want to go far, go together. I don’t think stand up require physical togetherness, but it does help. Set place is an self-imposed artificial constraint. Set time is also not mandatory, but doing them asynchronously has diminishing value. In order to collaborate effectively there is required time together. If a group can’t find 15 minutes of overlap in a day to coordinate work there is a bigger problem at play.
5. Extroverts thrive at stand up, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
I can’t even unpack this argument. It is feels more like a rant than anything else. Which is a shame because the other arguments seemed to be well thought out. Extroverts may thrive at certain ceremonies but that doesn’t mean introverts don’t add or get value at them. Implying that an introvert can’t work with others effectively seems dangerous at best. In coaching hundreds of teams and thousands of developers I have yet to find an introvert that wasn’t able to engage effectively in Agile ceremonies. Done properly, planning helps protect, not hinder sustainable pace.
Developers should have to push against technical debt creation. Value creation is always a trade off. Sometimes taking technical debt on makes sense. Sometimes it doesn’t. That’s a conversation that has to be had continually by all parties. Is technical debt bad. Yes. Do most companies wrongfully ignore it. Yes. Does that mean taking care of technical debt overrides all else? No. Are developers alone good at choosing how/when/what debt to remove in a vacuum? Rarely.
6. Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
If you are only discussing issues one time a week. You are doing it wrong. Retrospectives give a facilitated mechanism to dive deeply into tough problems and team dynamics that aren’t getting worked out in the day to day. They are not meant as a container to sweep all problems into. Retrospectives are one of the things most teams do horrifically bad. The biggest room for improvements come in changing the system and human dynamics within the system. People regularly ignore this to their own detriment.
7. Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?
Bad product management may prioritize features over technical debt, but sprints have nothing to do with it. You should have to advocate for what you believe is important. So should product. It sounds like organizational issues, not sprints are to blame here.
Let’s look at the additional break down of the arguments
Stop Doing Stand Up
Again this seems mostly like a rant surrounding technical debt. Does standup interrupt developers? Possibly. A small interruption is generally well worth the coordination benefits it yields. If you aren’t seeing coordination benefits you probably aren’t working as a team, but rather as a group of individuals. Stand ups aren’t useful for people working as individuals. If your stand ups are running longer than 15 minutes you have a problem.
I have seen no correlation to stand ups making a team communicate less. I have seen the opposite in my experience. About a third of the teams I have coached have one or more team member that is remote. It has never prevented stand ups from occurring. Teams that work poorly together remotely struggle with this more than those that already effectively work together with remote members. Technical debt has nothing to do directly with stand up or any particular Agile ceremony. Developers may feel less stressed without a stand up, but often a stressor is a good indicator for a looming problem or a motivator for performance. If stress free is the goal, you have already accepted mediocrity. Trust is a two way street. Most teams I have observed the members don’t trust each other completely. Stand up is a way for accountability among the developers to surface.
The remainder of the objection falls squarely into the “Chaos Development” model. The science just doesn’t prove this model out. People tend to not perform their best as free grazers. There is science that shows creativity increasing under a Chaos model. It may work well for research teams, but probably needs to be moderated for production teams. This is why you see many organizations doing 20% time etc.
Stop Doing Retros
The time to ask for help is when things are going good, not when they are going bad. The absolute right time to engage in couples therapy is when things are good not when they are in destruction mode. Your relationships, personal or otherwise should always be improving. That requires work, reflection and outside assessment.
If you can’t take thirty minutes to an hour every week to reflect, you are already running at an unsustainable pace. Perhaps that is why there is so much focus on the technical debt theme? If you are waiting to address problems only at a retrospective you are waiting too long. There is no need for stickies or sharpies to reflect. They can help from keeping things stale.
Some of the projected questions. That the article thought might get asked.
“How will I know what to work on?”
Nothing here seems out of place. The “Best” option could be a smell if it’s invoked frequently, but more than healthy in moderation.
“What do I do if I’m blocked?”
These all seem pretty sane to me, albeit a bit specific technology focused (trello, slack, etc)
“How will I track the progress?”
It is okay to ask everyday. Multiple times a day. A good team broadcasts so you don’t have to ask. I think a fundamental flaw here is that progress only matters to the team. It should matter to all stakeholders in the outcome of the work.
“Hold on. We totally handle tech debt and we do stand-ups!”
It is pretty common this happens. Any organization that doesn’t value quality isn’t going to prioritize preventing or eliminating technical debt. That has nothing to do with stand ups or Agile.
Conclusion
Question everything is brilliant advice. Start with am I the best at what I do? Is my team the best at what they do? Is my organization the best at what they do? How do I help get all of us to our best?
My advice to teams is that you are not nearly as good as you think you are. Discipline and habits are the best paths to performance increase and skill building. Having an objective outside party pushing you is the most effective way to accelerate performance. Process done well goes a long way. When you get to the point where you don’t need any process, you will find that you crave it anyways. Think Miyagi. Daniel san paint the fence. Wax the car.
We tend to resent that which we don’t fully understand. Are stand ups necessary to be awesome? Hell no. Until you understand what makes them powerful, you probably shouldn’t dismiss them.