Interviewing and SCRUM

Hosch250

Feb 21, 2016 23:50

BTW, what are some warning signs to watch for in a company when I am interviewing?

My mom doesn't work, and my dad is in a union, so he doesn't need to interview. I really don't know anything about the process.

nhgrif

> "How often will I be expected to work more than a forty hour work week?"

> "What kind of source control do you guys use?"

> "What do you guys do for continuous deployment?"

> "How often are code reviews?"

> "What's the expected level of automated test coverage?"

Vogel612

> "How often are performance reviews?"

nhgrif

Hang on, that's a different category

although, it belongs with my first question

Vogel612

@nhgrif depends on the job description...

nhgrif

Questions 2-5: The specific answers don't matter... the scary answers are obvious and do matter.

Vogel612

Feb 21, 2016 23:53

some jobs are basically impossible to achieve coverage on, because legacy

Hosch250

The person that seemed most interested explicitly noticed that I used GitHub and liked that I did open source.

nhgrif

@Vogel612 which is where we get to "the specific answers don't matter, just look out for the scary answers"

Hosch250

I'm working on a comprehensive cover letter to send to him.

nhgrif

The scary answers look like this...

> "We use a shared network drive for source control."

> "What is continuous deployment?"

> "We don't waste time on code reviews."

> "We don't write automated tests."

Vogel612

sidenote: Possible flags for the first question include "We don't, we just expect you to get the work done"

nhgrif

Feb 21, 2016 23:55

Right.

Vogel612

and "We don't really track time comprehensively ..."

nhgrif

So if that is answered

If they give a vague answer, then follow up with...

> "How frequently does the average developer at your company work over 40 hours?"

and

Vogel612

What's the overtime pay?

nhgrif

> "Who sets estimates for work I'll be doing?"

> "How often are performance reviews? Who does conducts my performance review?"

Vogel612

"we don't use estimates" is just as bad as "the marketing guy"

more on The Workplace

nhgrif

Feb 21, 2016 23:58

If you weren't an intern, this would be a question:

> "Can I work remotely? What is your flex policy like?"

Even though I don't personally care about working remotely, I care about my company's policy regarding remote workers.

Hosch250

So, what exactly is Continuous Deployment? Is that like our Appveyor thing on Rubberduck, or does it merge changes directly to prod?

nhgrif

Here's what continuous deployment/integration looks like at my company.

Vogel612

it's usually continuous integration (AppVeyor) + Something that regularly packs and installs the master to test / prod

Hosch250

OK.

Duga

RELOAD! There are 1879 unanswered questions (94.0697% answered)

nhgrif

Feb 22, 2016 00:00

I commit to develop (or whatever branch I set up for the build plan). A Jenkins server builds my app and runs all of the automated tests. If those tests all pass, the binary is pushed out to everyone interested.

Product owners get daily (or more than daily) builds.

Hosch250

So, basically like an Appveyor that immediately "releases" changes?

Vogel612

yep

nhgrif

It doesn't necessarily immediately release to production

Although...

I think Netflix does automated releases to production.

Vogel612

Stack Overflow actually does that, too

Hosch250

No, but it does release to anyone who is interested in the changes.

Vogel612

Feb 22, 2016 00:02

remember how the site graduated before it graduated?

nhgrif

But you don't have to automate releasing to production to be considered to be using CD.

Hosch250

Cool.

Vogel612

@MarcGravell, what do you mean live deployment? I thought that StackExchange was filled with professionals that don't need to test their code? — Malachi Jul 15 '14 at 15:16

nhgrif

To be honest, the most important part is that automated tests are automatically run every time you've pushed to develop.

Hosch250

Just like Rubberduck and VSDiagnostics.

Vogel612

Feb 22, 2016 00:04

that's usually called continuous integration

notable tools: travis, appveyor, jenkins

nhgrif

And then, the second most important part is that product owners get that build as soon as possible so that developers can, as quickly as possible, get feedback on anything that needs to be changed/fix.

Hosch250

So, who is considered a product owner?

Vogel612

Tools vary significantly depending on the language. Sometimes it includes environment control like Docker

@Hosch250 read up on Scrum

nhgrif

@Hosch250 It depends, but there's normally in a person in a role that's literally called "Product Owner"

Vogel612

@Hosch250 the one calling the shots and prioritizing "tickets"

Hosch250

Feb 22, 2016 00:06

OK.

Vogel612

also the person you ask when a ticket is unclear

nhgrif

What features come in and in what order. How do particular features prioritize versus particular bugs.

Vogel612

and it's (for vanilla scrum) exactly one person

nhgrif

Where developers are technical experts for the project, the product owner is the business expert for the project.

Hosch250

So, that would be @Mat'sMug for Rubberduck.

Vogel612

Feb 22, 2016 00:08

and then there's the Scrum Master that most people seem to not understand

nhgrif

Yeah...

Vogel612

@Hosch250 yea, but they usually aren't the Lead Architect simultaneously

PO doesn't meddle in code

nhgrif

There's nothing better than an amazing scrum master, and there's nothing worse than anything less than that.

Vogel612

@nhgrif I call a crappy PO is worse than a good scrum master

nhgrif

I'd disagree.

Hosch250

Feb 22, 2016 00:10

And a Scrum is where we say what we plan to focus on during the day and what difficulties we think we will encounter, and what we did yesterday.

Vogel612

I never actually worked on a "real" Scrum team (whatever that is)

@Hosch250 that's right and wrong at the same time

Hosch250

OK, seems people have differing views around the web. What is the right one?

nhgrif

Purely from the perspective of a developer, a good PO is great, but scrum masters can be major pains.

Vogel612

@Hosch250 for "the one and only" scrum, check scrumguides.org/scrum-guide.html

nhgrif

@Hosch250 You shouldn't waste time in a meeting talking about things that could be determined by looking at a tool like JIRA.

A scrum master has one job. He is the idiot plow.

And if he is an idiot, how can he plow the idiots out of your way?

Vogel612

Feb 22, 2016 00:13

ohhh yea... fun times.

the interesting part here is that this counts for inside the dev-team and outside of it

so if the PO is a moron, the Scrum Master is supposed to keep them in check

nhgrif

His whole point of existence is to make sure that things are running as smoothly and efficiently as possible.

Hosch250

So, one question I've always had about sprints: What happens when a sprint is completed ahead of time?

Do you just close the sprint early?

nhgrif

@Hosch250 pick up stuff from the top of the backlog

And talk about why you finished so early during your retrospective.

Hosch250

What if that stuff would run out of the sprint time frame?

Vogel612

@Hosch250 you might consult with the PO

Hosch250

Feb 22, 2016 00:15

What happens when the planned product cannot be finished during the sprint?

Vogel612

and ask them what to do

Hosch250

Does the sprint end and the next sprint takes up where we left off?

Vogel612

@Hosch250 Sprints are timeboxed.

they start and end at predictable dates

Hosch250

I know. But say that a sprint is entirely about Major Feature Xyz. It is planned for a month, but it is not releasable for 6 weeks.

How do you manage things like that?

Vogel612

and when you get the work done faster (but nothing else fits in) you can always clean the codebase up

nhgrif

Feb 22, 2016 00:16

To be clear, the point of the sprint being time boxed is that you're also looking at how much your team is able to complete in that time frame. Over enough sprints, you get an idea of how much can be done in a sprint.

Vogel612

@Hosch250 At the end of the Sprint, the software is by definition theoretically releasable

nhgrif

@Hosch250 Major Feature Xyz should be broken down into smaller components that can be completed within a single sprint.

Vogel612

every end of a Sprint is (at the core idea) a possible release date

Hosch250

I mean, what if an unexpected delay happens, like a dev getting hit by a bus?

nhgrif

Then the discussion on why you didn't complete what you committed to is pretty easy.

Vogel612

Feb 22, 2016 00:18

then you pick up the pieces, adjust the estimates for the sprint and hire a new dev

Hosch250

OK, so the sprint just ends and another one starts without a release.

nhgrif

Slow down for a second...

So, I'm actually actively working in a real scrum team...

We base our velocity on story points.

We pulled about 100 story points into our current sprint.

Vogel612

@nhgrif I think you're too fast

Hosch250

Just tell me everything. I like stories.

nhgrif

If you don't understand story points, ignore it for now. It's just a way of measuring how much work we're completing/committing too

When our sprint ends, there are three outcomes.

1. We completed less than what we committed to.
2. We completed exactly what we committed to.
3. We completed more than what we committed to.

No matter the outcome, we talk about why we had that outcome. We talk about whether that outcome is something we can expect to repeat. Or if we expect better or worse in future sprints.

Captain Obvious

Feb 22, 2016 00:21

-1

Q: Function divergence and DRY code

I am working on writing a module for my portfolio that loads a requested page. The page requested could load either new "content" data or new "content" data AND new grid data. There is still quite a bit I am working on here and some things aren't hooked up yet, but the issue that bothers me curre...

nhgrif

We talk about things that are happening that are preventing us from getting more work done. We talk about things that are happening that are helping us get more work done.

And then we plan the next sprint.

Vogel612

also... those meetings are usually terse

nhgrif

heh

I mean, they're supposed to be.

Hosch250

15 minutes each day, and a 4-hour or less one at the end of each sprint.

So, Scrum teams are usually small?

nhgrif

Right now, I'm talking about the one at the end/beginning of sprint

Vogel612

Feb 22, 2016 00:24

@nhgrif so you're doing retro and planning in one go?

@Hosch250 the 4 hours change depending on sprint length

nhgrif

@Vogel612 Yeah. Our sprints start/end on Wednesday. We have a demo, retro, planning on Wednesday afternoons.

Vogel612

Before you start, you decide on a sprint length. usually between 2 and 4 weeks

nhgrif

planning is the worst...

We watch the scrum master fill out his stupid spreadsheet...

Vogel612

oh... so you don't have an amazing scrum master :/

nhgrif

No.

There's also a meeting in here which we haven't mentioned: backlog grooming

Which is the only meeting out of all of these that I actually like.

Vogel612

Feb 22, 2016 00:26

@nhgrif that's not vanilla, is it?

nhgrif

I believe it is.

Vogel612

or did that change since I got my certification?

nhgrif

...certification?

Backlog grooming is when you work your way through the backlog and assign story points to the stories in the backlog.

Vogel612

@nhgrif seems it's not vanilla

@nhgrif I have a "Professional Scrum Master"-Certificate

nhgrif

What is "sprint review" and how does that compare to retro?

Vogel612

Feb 22, 2016 00:28

Monking @Snowhawk04 btw

Snowhawk04

sup

Vogel612

@nhgrif review seems to be the demo meeting

it can include externals (like major stakeholders)

nhgrif

oh, makes sense

Vogel612

retro is internal only

nhgrif

Yeah

so, how does the backlog get groomed then?

Actually

probably what's going on is that our planning meeting is a pile of idiocy

Mat's Mug

Feb 22, 2016 00:30

lol

Vogel612

> The Scrum Team decides how and when refinement is done.

nhgrif

And what we do during backlog is closer to what should be done during our planning meetings

Vogel612

@nhgrif theoretically the PO should do the ordering and breaking down.

Estimation happens in planning

nhgrif

uh

Why is PO estimating how long development work takes?

Vogel612

he isn't

nhgrif

Feb 22, 2016 00:31

oh, I misread

Mat's Mug

PO decides what deliverables they want in next iteration, besically.

The 2nd Monitor

Participants