What is a Stand Up and Why is it a "Stand Up"?
What if I told you the average adult attention span is eight minutes per hour (and that's being generous)? That means you have eight minutes before no one cares - said the guy that used to be a teacher. Sure, there are things we can do to overcome that boundary; but, it's a good number to know. Remember it. Your manager may want to know it and I'll definitely write about that number, later.
Many companies now boast an "Agile" workspace. However, "agile" often means messy, un-standardized, and excuse-laden. True agility takes practice, constant self-reevaluation (team introspection), process standardization, and - typically - a team member dedicated specifically to a workspace's agility management.
What's so hot about agility? True agility saves time, ensures product quality, and tailors the product to customer needs through a client-driven requirements elicitation process. Ultimately, the thought is, after enough deliverables, we are left with less technical debt and a more market-responsive product.
The Scrummage
In the world of Religious Studies, we often used fancy terminology - like "transhumandt agropastorialism". It's a great reassurance someone will have a job; after all, you'd need a Ph.D. in the field just to decipher the amount of intellectual self-gratification that permeates the field's literature (can you tell why I switched to programming?).
"Stand up" or "scrum" is a lighter version of the same - as is the term "agile", really. It's a hot, new marketing point that isn't standing the test of time well - though, if practiced well, should.
A team's daily stand up (sometimes called a "scrum" after the intense rugby restarting play, a "scrummage") is a great litmus test for a team's agility health.
So, what is a stand up?
A stand up is a quick, structured daily meeting between team members. It's that simple. Anyone can join a stand up (a buddy of mine works at a company whose daily stand up is over fifty strong); however, there are a few rules for participating, all focused around the stand up's main function: to keep the manager from panicking about deadlines and to call out for help, if needed (maybe a little bit of accountability thrown into the mix).
The first rule is pretty apparent: stand up. There's flexibility, here, but the most successful stand ups I've been witness to and participated in have had every member standing. You'd be surprised how heated people get about this requirement. Look, we're all programmers - we spend our days sitting.
I had a manager who insisted we stand during our daily scrum. Why? The second rule: a scrum should be quick (an oft-cited time limit is fifteen minutes; remember that generous estimate of eight minutes). If everyone is standing, no one will want to keep the meeting lasting very long (and people who keep the meeting running with trivialities will become aware, very quickly).
"Bogus!," you might say. "I've got mission-critical information I need to get from my team". Let's run a quick scenario utilizing the effective fifty-person scrum described earlier. That mission critical information takes five minutes to describe. Let's space that out over fifty people held hostage for that specific-to-manager information: that's two-hundred fifty minutes (four hours).
Four hours, today, of developer time will run you $180.00 (x five times a week is $900.00). That's if one developer decides to run it for more than the allotted time. Again, that is an extreme break down; but, let me take a minute to write to you first about what belongs in a scrum and when else it might be appropriate to address mission-critical items.
What Belongs in The Scrum?
Again, people will vehemently disagree, here. There are two philosophical approaches to this: one for the smaller team and the other for the larger team. Here, I'll cover the latter just to prove the point of how lean the stand up process should be (you can checkout Luxury Extensions for Smaller Teams, below, if you want more).
For a larger team - greater than eight people - the list of what belongs is as follows:
- A cry for help
- A mention to coordinate with another teammate outside of the scrum
Some managers might even insert a paramaterized or constrained status update from the developer (if not crying for help isn't indicative enough). One manager I've worked with would ask for a single word - this also provided some much needed potential for quick, Monday-morning humor.
"But, what about...." Nope. Agile office environments of larger sizes should be employing other tools to coordinate and communicate team efforts across the team. The daily stand up is a status check and that's really it. If your manager needs more, then you should be doing a better job of maintaining your tickets.
Luxury Extensions for the Smaller Teams
If you feel like your scrum needs more detail, then break apart your team, further (seriously checkout What Doesn't, below). Smaller teams - organized around whatever logical grouping actually makes sense - means more time to check in with each of your team members.
True agile stand ups will be extended to include short-worded updates. The list for smaller teams is a bit longer:
- Did I accomplish what I said I would accomplish, yesterday?
- What am I working on, today?
- Are there any foreseeable hazards?
- Do I need any help?
What Doesn't?
"Dude, I wrote this baller code, yesterday. I dug into the library's box..." Chances are no one really cares when they've got a deadline looming, especially when they are standing. Implementation details and detail-oriented solution and process descriptions for ticket resolutions do not belong in a stand up.
If you find yourself answering the above five questions with more than one or two sentences, one of two things will have happened: you'll have derailed the stand up; or your manager will have asked you a question that would have been better resolved outside the stand up (in which case the first is still true).
This doesn't mean teams can't have a good time or that stand ups are boring. It does mean the warlock who's been with the company for twenty years can get back to his desk and crank out code. If you've done something amazing, share it. But, consider how.
"Hey, team, I've found a great solution to yesterday's problem. If you're interested, stop by, later."
As soon as the conversation becomes irrelevant to your hottest team member, they've got time to think about how much better that job offer from that soon-to-IPO sounds. After all, we are there to code.
If you need more detail or want to give more detail, ask to who the detail is pertinent and whether it can be addressed directly after the stand up or later in the day.
Can You Save Your Stand Up?
Yes, and you can do it, tomorrow. Tell the guy who won't stop talking "Rodney, we can deal with this outside of the meeting". That's not an admonishment. Again, it's respect for the time space that is the stand up.
Another really great tool I've seen used is a timer. A set amount of time is given to each team member. Fifteen minutes eight ways is shy of two minutes each. The timer might even change color the closer the team member gets to the end of their allotted time (these tools are everywhere on the interwebs).
This may not solve the problem of people going over their time allotment, all the time; however, you'd be surprised by how just being aware of how long you have been talking reduces your tendency to speak.
The other thing I'd add is that people should be prepared for the stand up. People often come casting about wasting their allotment trying to remember the time since the last stand up.