A friend recently asked me to explain my version of what a daily stand up is and what the main benefits are to having them every day. He usually works on the business development and sales side of technology and isn’t as familiar with the day to day operations of a developer so I gladly indulged his curiosity. During our conversation, I noticed that in the years of doing daily stand ups the benefits and main purpose had a huge variance depending on the company and the culture. In hindsight, those variants were very indicative to the company culture and also brings to light how Scrum and Agile can be used as a weapon to create toxic work environments.
Pre-Standup Business Logic
Let’s quickly outline the process that gets us to a daily stand up so everyone is on the same page. When we are creating software we try to estimate the amount of time it will take to accomplish a desired solution. We compare a development estimation with the value proposition the solution might yield. The value doesn’t have to be monetary gain. It could be strategic, subjective or an investment for future efficiency. When the value seems to be worth the development costs we move forward to planning the implementation details, commonly referred to as sprint planning. In this phase, we break down the desired solution into smaller more focused tasks. These tasks usually break down into two categories: research tasks or implementation tasks. Research tasks are time boxed with the goal of getting a reasonable future time estimation and better context of what might be required to implement a desired feature. Put another way, research tasks are for uncharted territory that require further investigation. Implementation tasks are are concrete and actionable tasks where we feel pretty good about the estimation because we’ve completed a similar task before. Once those tasks are created, we assign them to a human with the goal that they can understand the desired outcome, have a clear understanding of what to do, understand the time we feel it should take and then begin working on the task. This is just a really detailed way of explaining a process that asks: what feature do we need, is it cost effective to build, and what are the risks associated to build this solution.
“The goal of software development is sustainably minimizing lead time to business impact”
The Sprint(cake) is a Lie!
Everyone can probably agree with the general idea of the process above. It’s a simple business analysis process to justify resource investment for future growth. Once we have completed that process a software team compiles those tasks into a “sprint” and sets a time commitment based on the estimations that were made. Already we have our first opportunity to weaponize a process against an assumed dedicated employee. Throughout companies of all sizes I have seen time estimations clearly communicated as “estimates” and not time commitments but depending on stakeholders, culture and outside influences the once clearly communicated estimate can be translated into many different forms that are anything but simple time estimations. I’ve also been witness to overbearing stakeholders who take time estimates and try to bargain them down. Some ambitious developers might try to brainstorm a more creative way of completing the task to help meet business timelines. Unfortunately, and more often than not the stakeholder who is continually bargaining down time estimations has a higher likelihood of holding the developer accountable for not reaching the "bargained estimation" instead of acknowledging the original estimation and thanking the developer for trying to think outside the box for increased efficiency. These type of stakeholders create a toxic environment because they continually keep success out of reach while leaving employees with no incentive to work harder when their neck is continually on the line. Another form of time estimations translating into commitments occurs when stakeholder schedule important business decisions based on estimations. This can place the developer into a stressful position of accountability that has further reaching effects than just a busted sprint. In these scenarios, the company’s success can becomes reliable on the developer’s ability to meet their estimations. This is another example of how Agile can be weaponized against employees to create (or validate) that their company culture is toxic. In time the developer who is trying to keep their sanity and have a work/life balance will adapt to this type of environment and begin over-estimating to deflect the backlash of and stress of an over-optimistic stakeholder. In any variation of translating a time estimate into an expectation there are negative consequences that will naturally arise in time. Usually the underlying foundation of these consequences come from caring more about results than the people accomplishing the results. There is nothing more demoralizing than working extremely hard for someone who doesn’t acknowledge your effort and commitment and instead only praises results. A friend once told me “the happiest people do the best work” and I’ve seen that first-hand. Scrum and Agile are great tools to track and increase efficiency but when they are in the wrong hands, like most things, they can be very destructive to your work environment and most importantly they will eventually kill company morale and loyalty.
Why Standup Tho?
Before we try to tear down Chesterton’s Fence, let’s look at why the fence was created for Agile and Daily Stand Ups. Based on our business logic in the first paragraph we used the information we had to make a decision to move forward on developing a software solution. What would be the best process to make sure that we can manage the project and ensure the value proposition is still worth the investment as the process continues forward? From a deliverables perspective, it would make sense to turn in smaller portions of work on a more frequent basis. From a cross-functional perspective, it would make sense to communicate with team members more frequently to give updates on progress and estimates. By having these frequent updates it allows us to see where current progress is and reassess if it still makes business sense to move forward or readjust. The dictionary definition of agile is "quick and well coordinated movement" so it seems to make sense according to Webster’s definition that if we are quickly readjusting we know why. Readjustments could be determined by market shifts, better revenue streams, user analytics, consumer complaints or just realizing the cost of moving forward is too expensive. Sometimes you can’t know the true cost of something until you try to build it. The goal of agile is to minimize that risk and stand ups should be a way to realign the current progress with the initial estimated progress. That’s really all it needs to do. They don’t need to be daily. They don’t need to have a time limit. They don’t need to be face to face. Without all these rules you can still receive progress updates and readjust your strategy if everyone involved understands the real purpose for the stand up in the first place. Stand ups are for simply for business alignment not micro-management.
What Stand Ups are Not
Sometimes it’s good to give examples of what something isn’t. If you’ve worked in tech awhile I hope this doesn’t trigger any PTSD. We’ve all worked in the toxic environment where standups were a gross abuse of power. Here are some examples of what a standup isn’t:
Standups are not a way for you to justify your paycheck. If you feel like that RUN!
Standups are not a way to micro-manage employees.
Although you are getting progress updates, the purpose isn’t to track when or how hard someone is working. It’s to track their progress. If you are worried that your employees aren’t working hard enough or long enough, you are probably the problem.
Standups are not brainstorming sessions.
Standups are not planning sessions.
Standups are not for scolding anyone. If you feel an employee is having troubles that’s a private conversation, not a public one. Praise in public, penalize in private.
Teams are dynamic and vary by many different variables. Your standup should not be defined by me or anyone else. Your standup is YOUR standup. Create the tools and patterns that work for you and your team and track what works best for you.
Where Stand Ups Break Down || Failures & Opportunities
Not all standups and agile processes go smoothly because they rely on human interaction. Human interaction tends to screw things up but infrastructure can also affect standups. Here are some examples of where standups can fail us and how we can use them as opportunities for growth.
The only voice
Sometimes standup is the only opportunity for a developer to voice their opinion, frustrations or concerns. When Sprint Planning is handled by a Project Manager and a Dev Lead is making technical decisions there is the chance that a developer can get left on an island and not have the proper context needed to complete their tasks to the best of their ability. When you don’t make an environment for all employees to contribute ideas you can’t call that collaboration or teamwork it’s just a hierarchal passing down of directions. I’ve been amazed working with different teams where managers aren’t asking (or listening) to input from their developers. What I found more amazing is that some of those developers had side projects that demonstrated proficiencies far beyond the chain of command above them. Because of politics or poor management they didn't have a voice at the table but if they did the company would have a higher quality product. Make sure to create an environment where everyone has a voice at the table even if that is done through 1:1 interactions. Having input on a project shouldn't be dependent on your job title or even experience. Some of the best ideas I’ve heard have come from the least likely places.
Everyone has to be on board
The example we used above would be great for a small startup but for larger companies there are a lot more layers. The sprint we wrote code on plus a bunch of other sprints get bunched together into quarterly goals. When unknown issues arise that cause estimates to balloon into reality that knowledge has to get carried up multiple channels. This creates an environment where people can throw others under the bus. It’s really not hard to do. If one person is overly cautious and critical all the time something is bound to go wrong which gives them the opportunity to say “I told you so” and get the ear of stakeholders who want more efficiency. That’s not a culture that anyone wants to be a part of. When the sprint time estimations are then used for epoch estimations which are then used for quarterly goals it creates multiple layers of potential failure.
In a system that relies on frequent communication it’s obvious that emotional intelligence and an inner sense of security are necessary for that system to work. In a culture where everyone is free to ask questions self-awareness goes along way. It’s pretty simple to have an open culture environment where people can ask “dumb questions” without getting ridiculed. The problem I often find with the open question culture has nothing to do with ridicule but instead with the question askers ability to take criticism. People don’t like to be wrong and developers get disheartened when the code they wrong won’t get used. When asking for help it’s crucial for people to not feel personally attacked and sometimes that is out of everyone’s hand except for the individual. The ability to detach yourself from your work and allow your work or thought process to be criticized and not take it personally takes work though. More often than not, it requires the person answering the question to have the skill of deescalation and dancing around a potentially fractured ego. For proof of this dance read the code reviews of large open source projects. It can get nasty. Another aspect of emotional intelligence required for software development is vulnerability. In a male dominated industry that often sees heated arguments about the best or smartest way to solve a problem the insults thrown about are usually related to stupidity or lack of experience/knowledge. This is not the friendliest environment for someone to openly come forward and admit they don’t understand how to solve the problem or don’t understand the problem in general. That’s never easy but especially in our environment it’s amplified when stupidity is perceived as the biggest insult and a large threat to your career growth. Hiring people who are secure enough to be aware and admit their shortcomings will eventually come around to be successful in what they do but only if the environment allows and praises the strength required to openly admit our weaknesses.
What Stand Ups Can Reveal
Standups when done properly and with a well trained team can turn into multipliers which advance the team as a whole much further than any one of them could go individually.
Find problems sooner
Developer weaknesses/ pair programming, getting assistance
False assumptions / less time wasted on dead ends
Your Agile Medium is the Message
If the medium is the message and the message is the medium (Marshall McLuhan). Take a long hard look at your standup and it might tell you a lot about your company and it’s culture. Examine how your company uses Agile methods, how humans implement them and how everyone feels about them. You might be surprised to see the tools meant to make life more efficient and transparent are being used as weapons that contribute to a toxic work environment. Hopefully your employee's focus is the a success of a project, not the success of making it through another day.