The good, the bad and the ugly standup
kristoff.it
kristoff.it
That stated - I liked it better than when I was in teams where there was the same dynamic (IE: very little necessary coordination across the team) but we met daily (or in some cases, twice daily shudder).
My jaw kind of hit the floor. That was my point all along about standups, the information being conveyed isn't actually needed for your job.
I don't really understand why people believe the only way communication happens is by standing up every day to talk about their feelings.
To be fair to the agile movement, self-orgainizing teams and the value of individuals are all themes expressed quite clearly.
Maybe you could try a small pilot and see where it goes.
So, the project manager/Scrum Master for the team, plus the technical members of the team. That's it.
You can have guest attendees, if there is a good reason. You can have temporary members, if they're working with the team for a short period of time.
But the basic rule should be just the engineers plus their project manager/scrum master.
And no one should be in multiple standups without a really good reason. Maybe the PMs or Scrum Masters should be in a Scrum of Scrums, but that's about it.
Allow all guests, even announce all times. People will learn to attend where it matters, and simply won't have time for many standups. Format should cut off bad management and time-sinks too. Harder to contain democratization (the opposite of every other suggested model!).
Having been a sysadmin / various kinds of techie for the majority of my career,nevertheless from most of my initial visibility into business & management worlds; and now having been full-time manager for 18 months; my feeling is that absolutely you need to understand, support, and enable your engineers to work on and in the way that makes them productive and satisfied... but last thing you should possibly do is "leave them the fuck alone". Otherwise, very quickly, there would be no salary for anybody :|
That being said, to the topic here, most "standups" I've been to have been a "spoke and hub" model where a PM elicits list of one-on-one status updates, and having done their part, people can doze off for rest of the meeting. In meetings I own, I try to change that to "Tell us of things that matter / are interesting to everybody here". It's not an easy criteria to fulfill though, for management or techies alike.
First, people got demotivated due to seemingly no one caring what they do and when they are done. Some people were unable to finish tasks or self-organize. And this was the most functional team under the circumstances.
Second, in one team where cooperation was necessary, actual lack of defined responsibilities and leader meant that important tasks were not done. There were fights over how less important tasks should be done. Some controlling people tried to take over leadership, fighting among themselves. Then for a while everyone gave up leading to no one having initiative. Then fights again followed by people not talking to each other.
Third, customer ended up complaining over low performance and having to tell everyone the same thing again and again, cause people did not shared info.
In my experience (27 years worth), agile is a watered-down compromise _on paper_ but is actually worse in practice.
time, features, reliability: pick two
In principle you could have those three if you throw enough resources at them.
How unnecessary!
In my experience, almost anyone who insists on synchronous, in-person standups is doing so because they want them to function this way, whether consciously or unconsciously.
I also suspect that standups with no active brevity constraint frequently come about not because of a lack of leadership but because they're actually a means for disordered thinkers to feel productive, which I think goes part of the way towards explaining why you see such irrational attachment to standups even among ICs.
But, yeah, IC = prole.
In large agile projects I've worked in before, we've split into teams of 5-10 and had separate stand ups, with leads from each team having a weekly "scrum of scrums" separately.
There are two critical things that a leader must do to run an effective standup:
1. You must have a leader who is willing to enforce the rules in order to effectively extract the right information to support managerial tasks (and not arbitrarily, but through team buy-in), and
2. They must be willing and able to understand most of the technical intricacies of the tasks taking place.
In my experience, most organizations' standups are run by people who fail at one or both of these.
Maybe they'll put in a PM who enforces the rules, but doesn't understand (or doesn't care to understand) the tasks the developers are doing with enough detail to be an effective facilitator. They act as a note-taker, letting the developers manage themselves ad-hoc, and don't ask questions unless someone specifically brings up a blocker. This can work with a team 100% full of self-starters who are comfortable with asking hard questions of each other, but that's your only hope.
Or on the opposite side of the spectrum, you have organizations that put more senior developers in that role. Then, you often end up going down design rabbit holes until you've run out of time, and you never end up doing the tasks that you actually needed to do: planning everyone's time effectively, and recording/communicating progress so that stakeholders expectations are correctly managed.
In both of those failure cases, you end up failing to deliver a quality product on time and/or fail to communicate expectations to stakeholders. In the first case, you made a plan, but it wasn't a full picture. In the second failure case, you had all of the right tasks figured out, but you failed to plan and communicate it.
Few people running software projects have formal study that spans both management and software. Many have neither, in my experience. Sure, formal study is not a requirement for good performance, it sure helps to get everyone in an organization on the same page.
In my experience, the few periods stand-up works (comedy aside), is when the leader (and noone is gonna do it without one!) understands what is to be gained by the people involved.
Unfortunately, whenever something randomly works, the next random reorg negates that overnight.
For me the main problem with stand-ups, especially when they are more than 2 times a week, is that they make it impossible to do lengthy unstructured work. It's embarrassing to say that you worked on something and didn't get anywhere. My theory is that max task size becomes the length of time between standups in most orgs.
I believe weekly OKRs are the best of two worlds: they are restrictive enough to feel the peer pressure for ones committed goal and descriptive enough for any manager to get a grip on the current situation, while at the same time relaxed enough for engineers to not feel like they are trapped in a cage. One week is plenty of time to either finish some work that just needs to be done or write a small prototype. In fact I liked it so much, that I brought the idea of OKRs back to my research lab and everybody loves it!
Scrum is the worst of this for me. We've rotated through a couple of daily formats and it always feels micromanaged and pointless. In addition to that it takes away the personal feeling of achievement. My best work in this framework has been done when I ignored the framework as the whole...
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I personally interpret "individuals and interactions over processes and tools" as a warning against the snake oil and magic bullets that agile consultants sold / are selling to corporations.
Standups are not at all a bad idea, but I feel like most implementations are simply a response to a prescription rather than a symptom. Nor do I feel like the prescription is particularly effective: rather than using the structure of a standup you could just, of your own volition - when useful; take an interest in your teammates' work, talk to them, and collaboratively come up with a solution.
http://programming-motherfucker.com/
Excuse the profanity, btw.
Problem is a lot of companies only engage QA for post-build integration testing. They try to phase it as a mini-waterfall within the agile cycles, which doesn't play well with agile and drags the process. At that point, leaving them to their own horizontal meetings seems like a plus, but there's a ton of opportunity cost for not having them in the primary conversation.
Other companies try to leverage QA for unit tests, but those really should be written by whoever wrote the interface as part of ensuring their intended contracts are fulfilled. That makes unit test writing not really a good QA role, other than making sure they're there.
The exception would be if you're going to pull QA in and pair-program/test TDD style--which is its own potential boondoggle. But you need real SDETs at that point, as opposed to scripters. Real SDETs aren't terribly common, and are not terribly cheap as they're niche specialists.
The best solution I've seen is to split the advocacy/short-term roles and the test/architecture/long-term development roles (even if it's two hats on one person), have them in the meeting for the former and have the horizontal run their own projects with milestone syncs for the latter.
At that point you can treat the short-term role as a team member, and the long-term roles as an internal vendor or external dependency (i.e. no expectation of control). Any sort of one-size-fits-all approach won't work.
I am also curious as to what you mean by "Quality works better when there's an advocate from the beginning." In my experience, even when (or if) I am invited to an agile Sprint Grooming or Planning sessions, I am more there to report on how a bug works and how severe I think the issue is - no matter how well I document some bug I found or whether product is there (as they should be deciding severity). I'm not sure how to meaningfully leverage my QA experience into helping developers drive their design and architecture to create more bug-free, quality code. I do notice that once I join a company and find/report zillions of bugs, their code slowly gets better over time, but isolating an incident and then measuring my impact is nigh impossible.
Anyway, I know this has nothing to do with the topic, I just wanted to see what you thought because SDET/QA talk is rare to find on this website.
Compare to someone who only does black box testing and only tests from the standpoint of manually testing via a user interface.
It implies an education/experience background equivalent to any other T&I Software Engineer, but usually with additional experience in QA. Alternately, it could be a QA engineer who would be genuinely qualified as a general SWE in a promotion path, but who chooses to stay in quality as a domain. But either way it implies equivalent qualifications as a SWE at the same level.
The "real" bit is because over the last half decade or so, SDET has been blurred by title inflation. Scripters have been getting the title without any real experience maintaining longer-term or larger software projects, and who aren't qualified enough to be hireable as a SWE generalist.
That's one reason you still get "lesser than SWE" status arguments about SDET, when IME you actually tend to demand a little more in the market because of the need for experience in two separate disciplines.
My response to the comment above you has a lot more detail expanding on that.
In short, there's been a lot of title inflation in QA, in part to avoid the "black box tester" stigma for both the employees and the organizations alike.
One of those inflations has been calling what were QA Automation Engineers--generally people writing scripts--SDETs. I saw it start to rev up in the late 2000s, and saw it accelerate (maybe not coincidentally) in the early 2010s, shortly after a GTAC talk where they claimed SDET makes 30% more on the average than QA. I suspect a lot of people asked for title changes, or a lot of managers realized they'd also look 30% better managing SDETs than QA and advocated for them.
Thing is that SDET as originally conceived was/is supposed to be a Software Engineer who specializes in testing, with the same qualifications and training as any mainline SWE. The normal domain of SDET would not be scripts, per the other response, it'd be tools, infrastructure and harnesses, maybe seeding test frameworks for incremental development during test creation, usually along with some level of QA thought leadership.
The primary difference there would be the ability to scope, implement, and maintain longer-term software engineering projects. A QA Automation Engineer might be as skilled a coder, but test scripts tend to be short bursts of isolated code and don't require as much architectural or lifecycle experience.
But SDETs are also useful in cases where you want to blur SWE and test, since most SDETs have heavy experience in both and can talk shop and build rapport with both sides. That comes in very handy when pairing with a mainline SWE, hence mentioning it as a near-requirement for that process.
No offense to you and your journey, but I'd have never stepped back from an SDET role to a QA Automation Engineer. It really is objectively worth less in the market, for one thing, and there really is a stigma there with QA in the title. It shouldn't be that way, but it is, and inflation has been the natural response.
Re: advocating for quality from the beginning,
Testing is by nature quality control. You can do it early, you can do it late, but at the end of the day it's a screening process.
That's different than Quality Assurance, which is monitoring and influencing the process and decisions when they're made to promote and advocate for quality when determining the good/fast/cheap project management compromises.
That includes arguing for testability as a primary requirement, arguing against overly complex requirements likely to produce emergent bugs you can't easily catch with QC, pointing out gotchas (hey, everyone is on vacation in December, expect crap code rushed checkins in November), basically anything you can do to reduce risk.
So in that role you're not a tester, per se, but a Subject Matter Expert in quality, hopefully influencing a whole team towards testable products, intelligent context-driven processes and good use of test pyramid, use of static analysis and other code quality techniques (think SonarQube), etc.
All this is over and above just testing, because you simply can't test quality into a project, you can only delay it until it's good enough. That type of gatekeeping is an adversarial tension fraught with both process and organization risk, and it should be avoided.
When you're an obstacle, people will have the natural tendency to work around you and resent you when they can't, which makes it an unsustainable dynamic to rely on as your 80% case. Ideally, most testing should just confirm what you already know: you have a solid process that caught all major bugs before you ever did a final pass.
Even if your org is going to just go full QC instead of QA (which is pretty typical, unfortunately) being able to absorb the full architecture and use cases around what you'll be testing is vital for coming up with an efficient and sustainable test strategy.
If you've been in QA any length of time, you know that these qualities--efficient and sustainable--aren't exactly associated with that corner of the process. A lot of that is because QA/test is often relegated to reporting on how a bug repros and how severe the issue is. You could be doing so much more, but that requires cooperation from the people around you.
When I was doing my time as a QA Engineer before swinging back to SDET, I did this by leveraging my SWE experience to talk shop with devs in low level terms until they trusted me. But it's a hard road to climb, particularly if you didn't have a flipflop like I did.
I hope that answered your questions. It does reflect a degree of personal bias, of course, but it's pretty well-informed by a long time in this corner of the industry.
You will be surprised with the results.
In software, standups make it easier for stakeholders to track that people go to the office, and do so at a reasonable time, although most people will not admit it because it sounds bad.
Of course, making sure that team members are making progress and they're not blocked is very important, but that might not be relevant for non-stakeholders.
Sometimes it's all unintelligible mumbling and serves no purpose other than cargo cult.
If you are blocked, you don't want to wait until the next standup meeting to address the issue anyway. Standups provide no benefit here.
> Sometimes it's all unintelligible mumbling and serves no purpose other than cargo cult.
I've come to the conclusion that standups exist simply to read the commit log to those who do not understand how to use <insert source control system>.
Also, an important note. Even if there was a standup, it's ok to talk more in detail about the tasks/tickets after it, during a day. People seem to forget it and make the stantups far too long for everyone to hold one's attention until the end.
I'm currently involved in several, what I like to call, "dead standups". Zombie's could give an update and no one would bat an eyelash.
Stand up can be useful if there is an effective leader. I'm actively trying to identify these characteristics and implement on the teams for where I am involved with the goal to cultivate/develop/train people to make these stand up meetings useful. Because we all know a dead standup is where productivity goes to die.
I'll have to share my results. Tomorrow, I hope someone asks me for an update on my progress ; )
That's not the same as "not caring about their project". I care about my project, but I don't want to hear 30+ status updates for tasks which are progressing nominally.
> Tomorrow, I hope someone asks me for an update on my progress ; )
Suggestion to take or leave - instead of being asked, volunteer your status and set the tone for how you'd like others to make use of standup (format, brevity) :).
You are not a leader; you are an enforcer.
Right now for me, the project managers own the whole event. You are asked for an update on a task that is on the project managers list, you give your update, and then he moves on to the next guy. There is only one developer in the meeting (me). The rest are QA, BA, Product Management, Delivery Management, and Change Management staff.
The developers who work under me will get prodded randomly throughout the day by various other project managers for their updates.
This is what happens when your company is "project oriented".
Strongly agree that with certain teams you don't need a regular standup. That's part of why I think the decision to do a standup should be left to the team themselves, absent some clear dysfunction bad enough to require outside intervention. Otherwise you're probably just wasting everyone's time with 15+ minutes of boring crap that could just as well be a 2-minutes-to-write daily status update message or email to the project manager, assuming they can't get the status info they need out of Jira or git commits and skip the side-channel status updates altogether.
I guess another major tell aside from "multiple unrelated teams are in the same standup" might be whether, if every single non-manager/PM quickly checks in with the rest and they all conclude a formal standup's not needed that day (or the entire week, or whatever), a standup either still happens or else someone (a PM or a manager, probably) gets really bent out of shape if it doesn't. If so, you're likely dealing with a regular ol' daily status meeting. And again, that's what a majority of "standups" I've seen have actually been. They're not for the team, and however they manage to occasionally serve the team members' needs is accidental—they're just micromanagement and "agile" box-ticking.
It is nothing more than the dev team coming together to discuss how to move forward towards the goal. No one else should be at the meeting. If further detailed discussion is needed, save it for afterwards.
I do think it skipped a common severe corruption of the daily standup, which is a daily application of micromanagement and deadline pressures.
I’ve heard about successful daily scrum meetings but I now believe the inherent chemical instability of this practice makes it too dangerous for all but a few very disciplined teams and only when absolutely necessary.
To me, scrum is the nitroglycerin of management methodologies. People who think they can handle it safely probably can’t. It’s wildly tempting for managers or stakeholders who are concerned with deadlines to hijack the meetings
(I genuinely thought the article was gonna be about comedy. I was disappointed.)