As a lefty who moves the mouse to the left side of keyboard, WADS is no more awkward than any other keyboard combination for left or right headed people. Just, you know, shift your keyboard a little bit more towards the right for comfortable spacing lol.
I agree that there are individuals and companies who have defined such ridged structure and expectation into their Scrum method that they can no longer be considered an agile approach missing two of the key purposes of agile approaches:
* Individuals and interactions over processes and tools
* Responding to change over following a plan
Now, I cannot say that Scum abstractly is a bad approach to attempting to be more agile. Many of us have employed some form of it with varying degrees of success, but, the expectations on software developers from a business perspective are more rigid for business development and tracability purposes, which can,on occasion, omit the consideration of resource demands and complexities.
Often, i believe, it is that a lack of understanding the purpose of the agile manifesto and the poor implementation of a method at the top level of the developer and managment ladder which is the underlying cause.
In the post, the author cites 3 hour or more meeting where he feels there are too many people there. This would be an item for the retrospective feeding the next iteration, but he only says "Blergh" about the needed feedback.
He states that the standup is more ritualistic, but the point is to ensure each member understands where the sprint stands, inspire collaboration, but really take ownership of the code. It could be that the team size is too big, or that the team really has not taken ownership of their code.
When all is said and done, you have to buy into the Scrum process, the process has to be flexible, and the stakeholders have to not believe it is a magical development method that fixes all the issues of the software development process.
His complaint about the standups interrupting productive work rings a bell with me though. I see no reason why a daily status update over the general channel on slack doesn't serve the same purpose as a standup meeting. In fact, make it so there's a loose timeframe, say 30 minutes, and you wouldn't be interrupting people, nor forcing them to stare at a wall.
My team hasn't tried anything like that, but I think it could really be useful. It encourages better communication throughout the day as well, as it gets people using Slack. Plus, it gives managers the ability to keep track of what people say each day.
For me, the daily status meeting at my current job has been the only time I can guarantee the team lead will be available to answer questions, as he tends to get pulled into meetings (or is busy marking up tasks or working on code reviews) most of the rest of the day.
At this place, where there are lots of different code bases of various quality and approaches to how the features are implemented has shifted over time, I tend to have questions most days.
I have worked at companies where we're only really working on one thing and I'm familiar enough with it that I really didn't have to ask any questions (they also didn't care much on how it was implemented, either, just that it worked) and daily status meetings were pretty much a waste of our time and ended up becoming more like once every other month.
> I see no reason why a daily status update over the general channel on slack doesn't serve the same purpose as a standup meeting.
I haven't used slack in anger. When you need help, how do you tell the difference between a teammate being busy, unavailable, or just too distracted to respond? Part of the point of the in-person standup is to remove ambiguities about this at least once a day.
We've tried that using Slack (and also IRC in previous projects, perhaps even email at some point). It works well, and I don't remember when I did a face-to-face daily standup the last time.
In the commentary for a previous story, another user mentioned that they have a "today-I-will" room in Slack. I've been itching for a chance to bring that up with my management.
"the team size is too big" - this is a very good point. Towards the upper limit of the recommended Scrum team size (3-9) they can get really unwieldy. I've been to a standup with an even larger team, which included a couple of design and marketing folks, and it was unbearable. The recommendation's there for a good reason.
but in this case, the users, through the Power website, did give permission to receive, or send, the "snail mail".
From the article "Power users also authorized the software to send Facebook messages to other Facebook users for them"
So in your analogy. I created a business of sending snail mail to addresses I already had in my possession on my list of contacts. My contacts might not appreciate my snail mail, but I am not sending snail mail to the Facebook corporate Office -Or- if I am sending to the Facebook Corporate Office, then only though its mail routing department, which was set up to handle these very packages.
The C&D, I think, is equivalent to preventing contacts from communicating with each other, or, Postal Censorship[1], which I suppose is more a policy issue than a legal one. Which I suppose extends FB to be a governing body, which I guess leads us to CFAA...
Another great tool for touch-less interfaces. I think the odd aspect of this Google I/O demonstration is the novelty usage of the technology for a smart watch. This tech seems like it is more difficult than it's worth in that form factor, but for devices that must remain sanitary, say in a kitchen, or a medical device in an OR, I like the potential.
Perhaps this is good for feature development, or maintenance, but, what about contracts that deal with wholly new development of a complex system? It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure. Perhaps I am being disingenuous.
I do love the idea of being able to not let the numerous tedious meetings interrupt progress.
[edit] Thanks everyone for adjusting my perspective. I am sure junior engineers (and seasoned stubborn ones) would learn a lot with cradle to grave development in such a fashion [/edit]
Having spent thousands of hours pair programming I would assume that this is were mob programming is especially valuable. The decisions you make early on are the decisions that everyone on the team will have to deal with. So if you do nothing else as a team this should be it. I actually recently had a client who was lukewarm about pair programming. But they mob programmed on new laying foundation work fit new services. We pair programmed on three new services together at the same time. So much syncing had to happen afterwards that mob programming the foundation would easily have been more efficient and effective.
> It seems like you would want to operate in parallel at least for the initial push through the architecture and boilerplate structure.
I'd disagree there, if there's a place for mob programming, it's probably here. Given every member of the team will most likely be branching features from a singular foundation, it becomes far more important for every person to have a chance to understand the core completely. This also has the side benefit of reducing friction later on by establishing basic conventions.
A former colleague of mine, one for whom I have great respect, is applying mobbing for this right now. So far, they think it's a great way to get and keep everybody on the same page.
I'm still skeptical of mob programming, although as somebody who's done a lot of pair programming I'm open to it. But the theory makes sense to me. Early on it's easy to make decisions or fall into habits that cause trouble later. Figuring out some of those initial choices strikes me as the best place to apply a lot of brainpower. Once the architecture is established, I'd expect things would be much easier to parallelize. (But I'd still keep pairing and frequent pair rotation to keep everybody in sync.)
"So around the time a lot of people have kids? ...you need to make a LOT of money to pay for daycare ... you might as well just stay home."
The "you" can be the other partner. Ensuring fair pay and opportunities for all qualified workers would encourage only a brief departure from a woman's career for maternity leave, allowing either partner to be the home support (as needed), instead of making the choice based on poor future earning opportunities vs their male peers.
Our culture's acceptance of stay-at-home dads has not neutralized in step with its acceptance of working women. As relationships link people into social units, social costs imposed on men can counter-intuitively harm women.
Do we know that that's the reason that more women are deciding to stay home? This looks like a big conclusion to draw when the data only _may_ correlate.
Where's the survey of double-income family moms working in tech where they specified the reason why they chose to stay at home?
There are a lot of reports coming out that look at numbers and say what may be the reason, but I've yet to see anyone go ask women the reasons why they left jobs in tech.
1) People in tech are assholes to women. I don't think most of them realize they're doing it. Sending images of swimsuit models over slack or otherwise sexualizing your work environment is an awful idea, and you shouldn't do it even if you don't have women on your team. My partner gets asked out by coworkers regularly, even while pregnant.
2) No really, people in tech are assholes to women. I've heard women give presentations where people talk over them the whole time, and then critique them for not being prepared afterwords. Nah pal, you literally stopped her from presenting information. People do not take suggestions of women as seriously wrt technical problems.
3) Kids. State of paternity leave in the U.S...
4) Being pushed into management. Women are pushed into management at a disproportional rate -- while some see this as a success metric, it can also be seen as an extension of point 2.
5) HR problems. Using HR sucks when you're the only woman on the team. Having someone else call HR sucks when you're the only woman on the team because everyone assumes it was you.
6) Culture, combination of all of the above, lack of a critical mass of women to make actual change, etc.
I'm not at all saying that I don't believe you, but we're at the point where we need to leave anecdotes out of this and start gathering good data. As much as I've seen your examples, I've also seen all of the counter examples (except to point 3 because that's just how it is in the States).
I spent the first few years of my working-life in female-dominated industries/workplaces and almost the entirety of my tech career in female-dominated or equal workplaces. I've yet to work somewhere without pay-parity (actually the hedge fund I worked for paid women more). From my anecdotal perspective, the world out there is wonderful.
But I know that's not true. I have a strong filter against toxic work environments - I simply would never end up at a company like that.
I'm just asking for good data that can speak for itself. This is what our industry does.
Aside: frequent surveys/studies show that more than 50% of participants have engaged in an office romance, equally across genders. I've never done this, but it's a big stretch to say that asking out a coworker is asshole behavior at this point. It's much more about the how.
I didn't mention pay parity anywhere. The majority of pay disparity between men and women in the U.S. is due to job/field selection imo. The questions we have to ask are ones that determine why people choose certain fields, what social pressures are there, etc.
Which is why I agree that we need good data, but the best I can do is actually talking to women and seeing their problems, and they're remarkably similar.
That office romance bit might be different in a situation in which you have an equal number of male and female coworkers. But when you bring in a disparity of 5:1, asking out your coworkers, you're literally just having people being pestered all day.
And honestly, you're referring to a study that disseminates itself via an ad carousel with no methodology I can find. A survey of 2000 people with no published methodology is hardly reliable.
There's a reason you've never done it, and most women I talk to cringe at the idea.
These are startup problems. Larger mature tech companies (there are many of them) shouldn't be that hostile. I work at one with 1000+ employees and while it's not 50/50, I can't imagine it being that bad.
Also, I'm a black person. All of the horror stories they say about POC in tech, I have never experienced one. I've had individual jerks but, I haven't had things like the company passing me up or ever felt that I wasn't getting a promotion, ever.
So, mapping that to what they say about women, I would say it's unlikely to be as bad as they say. Now, that's completely and utterly subjective but, attitudes concerning your perceptions of how others treat you is subjective.
> Also, I'm a black person. All of the horror stories they say about POC in tech, I have never experienced one. I've had individual jerks but, I haven't had things like the company passing me up or ever felt that I wasn't getting a promotion, ever.
One thing interesting about the company I worked at from 2012 to 2014 was that, despite it being an abusive startup with dysfunctional management, it was the single most ethnically-diverse place I've ever worked at, and I'd never heard about a single problem related to race there (while I'd heard a lot about the company's other problems). This was all despite the company being a tiny startup that never exceeded 15 full-time employees when I worked there (augmented by a handful of contractors and part-timers, so a little more than 15 on the payroll at a few points). To wit:
I'm Jewish, as were both of the co-founders. We had three Indian employees (though not at the same time). We had two black programmers, one of whom is also an albino and legally blind. Our lead content people were a woman of Cambodian descent and a guy of Iraqi descent who's an actual Assyrian Christian. We also had a few part-timers, including an Asian guy and a summer intern from Sicily (technically white, but I'd still say she's a minority because her accent stood out). WASPs were very much a minority at that company.
Also, I'm transgender, and so was one of our contractors, but that actually did cause issues (not with my employer, but with our landlord, who went out of their way to make life difficult for me because I'm trans).
Not to shit all over other peoples' career choices, but those and fresh startups are exactly the sort of places that hardly ever pass my shit-test for work environment.
The absolute best places to work, I've found, are in (non-tech or tangentially tech) businesses that have a solid tech team but aren't in the Tech Co Echochamber. Surveying my friends and colleagues seems to point to the same.
Want to be seriously valued and friends with everyone at work? Be the person that asks questions, sees their problems and then makes the magic happen. You're not going to do this at Google or Facebook and you're not going to do this at DeathMarchOnwardNextFundingRound-ly either.
Tech-bro shenanigans not flying in the "traditional" business world is a huge bonus.
At a small, technically-focused company where "manager" also means "tech lead", it's very unlikely that being disrespected is synonymous with "being pushed into management", but at a big, bureaucracy-heavy company that follows the Dilbert Principle where people perceived as incompetent are routinely kicked upstairs to get them out of the way, I can see that happening.
Ensuring fair pair wouldn't allow either partner to be the home support. Why? Because woman desire their partner to make more money than them.
Even if she makes the same salary as her peers she will statistically be married to a man who makes more money and so the economic pressure will be on her to be the stay at home partner.
Now to find women who want their husbands to stay at home looking after the kids while she works, good luck with that. And to be clear unless 50% of the coupled women out there commit to this you wont see any meaningful change in how society perceives stay at home dads, which currently is "lazy"
That is a lot of trust in a corporate entity who in all honesty trys to profit from you wherever possible, and they would not be sued if such items were spelled out in the TOS. In this plug in, the plug-in author placed a notice where it could be found by anyone, not hidden away. Here, just as dspillett said, do your own due diligence and select products accordingly.
At the same time,even large trusted corporations can impose interesting license agreements (runtime or otherwise) that you better be well versed on before you start creating releases of your product.
