Azure Jane Lunatic (Azz) 🌺 (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
azurelunatic) wrote2012-03-22 10:32 pm
azurelunatic) wrote2012-03-22 10:32 pm
Entry tags:
Scrum*
So there I was, fresh from watching the long-form presentation phase of the team meeting, and I had some thoughts for one of the developers, as one does. I popped over to her cube to share.
She conveyed that while I was shiny as usual, she had less than zero time, as she was due at the *second* meeting in a minute and a half, but I should totally come to that meeting too! (My design-feedback persona tends to be "eager puppy", in case that wasn't totally obvious.)
I hadn't really been sure that I was really the right sort of team member to be at this meeting (like I should be doing paperwork instead of meetings), but I came along, with a notepad, intending that I could do some of the same brainwork that I was doing at my desk, but while in the company of my team.
As it turned out, it was probably a good idea for me to attend.
One of Feynman's stories involves him being shown blueprints of a facility that he helped design, and being asked for his approval. He had never been trained in the decoding of architectural symbols, so he planted his finger on a symbol that *looked* like it might be a valve, and asked, "What if that valve gets stuck?" hoping that either a) he was right, or b) someone would gently correct him and tell him what it actually was.
He was, as it happened, right, and this prompted a flurrying, scurrying, and staring at him with awed eyes before hustling off to go fix it.
I looked at an array of four options (checkbox, not radio button), and asked how the sysadmin was supposed to know that these were AND, not OR.
Now, radio buttons are very *clearly* Exclusive Or: one of these options, and only one. Checkboxes can be either "all of these together" or "any one of these options (but not the other ones)". Which this is depends on the situation and the back-end handling.
The answer was that the experienced sysadmin would Just Know, but there was no note to that effect -- and anyway, only experienced sysadmins would be using it, and the effects of setting it with wrong understanding would immediately be apparent.
At this announcement, such a clamour broke out. It was glorious, and well worth the price of admission, and (inevitably) started to descend into bikesheddery. When the fracas was pulled to a halt, the upshot was that it was going back to the team in question for further study. They had assumed, and they would now investigate whether in fact their assumption was correct.
I grabbed a moment with the designer in question after things broke up, and acknowledged my role in the chaos. He pointed out that sometimes it does take the perspective of an outsider or beginner to notice the assumptions that someone who has been bathing in these things for years on end will make and then put forth, forgetting that not everyone has the same sets of assumptions and knowledge.
Tomorrow: more paperwork! YAY!
* Technically speaking, probably more of a standup. It went over the time limit it was supposed to be within.
She conveyed that while I was shiny as usual, she had less than zero time, as she was due at the *second* meeting in a minute and a half, but I should totally come to that meeting too! (My design-feedback persona tends to be "eager puppy", in case that wasn't totally obvious.)
I hadn't really been sure that I was really the right sort of team member to be at this meeting (like I should be doing paperwork instead of meetings), but I came along, with a notepad, intending that I could do some of the same brainwork that I was doing at my desk, but while in the company of my team.
As it turned out, it was probably a good idea for me to attend.
One of Feynman's stories involves him being shown blueprints of a facility that he helped design, and being asked for his approval. He had never been trained in the decoding of architectural symbols, so he planted his finger on a symbol that *looked* like it might be a valve, and asked, "What if that valve gets stuck?" hoping that either a) he was right, or b) someone would gently correct him and tell him what it actually was.
He was, as it happened, right, and this prompted a flurrying, scurrying, and staring at him with awed eyes before hustling off to go fix it.
I looked at an array of four options (checkbox, not radio button), and asked how the sysadmin was supposed to know that these were AND, not OR.
Now, radio buttons are very *clearly* Exclusive Or: one of these options, and only one. Checkboxes can be either "all of these together" or "any one of these options (but not the other ones)". Which this is depends on the situation and the back-end handling.
The answer was that the experienced sysadmin would Just Know, but there was no note to that effect -- and anyway, only experienced sysadmins would be using it, and the effects of setting it with wrong understanding would immediately be apparent.
At this announcement, such a clamour broke out. It was glorious, and well worth the price of admission, and (inevitably) started to descend into bikesheddery. When the fracas was pulled to a halt, the upshot was that it was going back to the team in question for further study. They had assumed, and they would now investigate whether in fact their assumption was correct.
I grabbed a moment with the designer in question after things broke up, and acknowledged my role in the chaos. He pointed out that sometimes it does take the perspective of an outsider or beginner to notice the assumptions that someone who has been bathing in these things for years on end will make and then put forth, forgetting that not everyone has the same sets of assumptions and knowledge.
Tomorrow: more paperwork! YAY!
* Technically speaking, probably more of a standup. It went over the time limit it was supposed to be within.
no subject
sometimes it does take the perspective of an outsider or beginner to notice the assumptions that someone who has been bathing in these things for years on end will make
This is often my job. My bosses (1) are greatly appreciative that I have this talent and (2) really, really annoyed that it Never. Goes. Away.
I get bimonthly lectures about "focus on solutions; not problems!" And about semi-annually I receive lectures about "not being so negative all the time." And then the next big weird project will come in, and they'll be getting ready to buy some ridiculous amount of supplies, and I'll say, "how are we going to do the covers, since our machine doesn't print on that paper" or "um, you are aware we can't name the scans to match the originals and also keep them in chrono order, right?"
If I did this once or twice, I'd be the damn hero who saved the project. Doing it every other project makes me the nuisance they tolerate for the one project in ten that would've utterly flubbed without that input. (The others would just have taken 20% longer than scheduled, and involved an extra dozen frantic phone calls to the client to sort out the missing details.) (Which phone calls get made *anyway*, and they resent me for making them pester the clients before there's an actual *problem* going on.)
After several years of this, I've concluded that the industry really doesn't want to run projects well, and the people doing e-discovery work really don't want to understand how computers work, and I try to keep my commentary and questions to those aspects of projects that I might be asked to take responsibility for.
no subject
I'm starting to get the urge to gather my people unto me at this job. Granted, it's still in honeymoon-phase a bit, but ... it's not making me actually froth with rage on any sort of regular basis, and the hitches so far have been largely technical in nature.
no subject
no subject
no subject