lol some people on the team still dont know why i'm there and i've gone multiple days without hearing one person say another word to another.

if my boss wants some type of scrum system this is pretty much the worst possible environment for it

he wants to meet at the end of next week for some "sprint planning" but i still have yet to know what the concrete expectations of me are and what his expectations for the projects are. he needs to put together a priority sorted backlog with my counterpart and the CTO. the team needs to be informed and discussions need to take place before our first "sprint planning" meeting but he hasn't indicated if anyone even knows changes are coming - it seems like he wants to slightly modify the current system, which is fine, but i need to know exactly what he has in mind, cuz it seems like they're winging it.

what it seems like is he's gonna tell me "here's what i want accomplished in the first 3 sprints" and i'm gonna be left to figure that out. if that's the case, ok, but i need to know some things first. since i know basically 0 about the project and the source code and am underqualified compared to everyone else, i really would like to ask him in a gentle way how he expects me to accomplish his expectations. i really just want to find out if those expectations are reasonable and if theyre not i want to know sooner rather than later. so that's why it's a difficult conversation.

I’m so confused right now

How can you plan sprints when you just got there?

It's the kind of thing a bad boss at a bad company where no one communicates and job descriptions are ill defined would expect.

I think you just need to relax a lot more.

Yes, they are winging it, so is everyone, that's how it works for the most part.

You should just take some time to see how things work now, and try and find some things that can be improved. Focus on one thing at a time.

Right now it sounds like communication is an issue for the team. Think about how to solve that and work with your boss on a plan to try some things to make it better.

Just slow down and take it all in, learning from failure when it isn't on your dime is the greatest privledge in business there is.

I generally second what Larry said.

yea i do need to relax. i am not really used to failure but i feel like i'm being set up for it here.

luckily the project overall health seems really good and they have real talent. there are a few people i can tell don't do much and they are carried by 1 rockstar dev but he seems really unhappy to me.

eventually in the next ~6 weeks want to have a meeting with the team and get a sense of where everyone is at, sans my boss, but i'm not sure how well that would go over or if i should even do that.

been reading everything i can get my hands on on agile/scrum development and it's like a ****ing religion. the one question i have for my boss this week is "on a sliding scale of full drink the kool-aid scrum and what we have now, where would you like us to be?" and go from there

it seems like just getting everyone in the same room for 10 mins a day would probably increase productivity by a huge factor.

doesnt sound like a good idea to phrase it anywhere close to this. really, just go with the flow, I doubt that much is expected of you at this point.

in ~5 weeks i am going to be handed off the responsibility of hosting my own sprint and daily scrum meetings so it feels like it's fairly soon

do you have some sort of sprint tracking software? if not, get it. trello or tfs are popular.

scrum meetings are easy. ask the devs what they are working on if they need help. dont let the devs ramble.

you are a business analyst, just as I predicted.

Agile is a lot like a religion, but remember, just like a religion most people who use it are actually Agile But. "We do Agile but we don't have autonomous, self contained teams." "We do Agile but only after we plan everything out first." "We do Agile but we have hard deadlines for features."

The biggest feature to make use of with Agile is the way it iterates over itself. Use the retrospective to evaluate the process and suggest changes to make it a better process.

It's going to be difficult if your boss wants you to be a change agent but isn't giving you any cover, like introducing you to the damn team. Ask him when he's going to do that and if they have engineering meetings to talk about their process.

However, I agree with Larry that you should spend some more time understanding how they do things now. You can't figure out how to get to the goal state if you don't know the current state...

yes the "scrumming the scrum" part of the process is what i like the most about it

so one of the devs pulled all the pull request data for our project from tfs. he was tracking how much time he spent doing code reviews. anyway, he said that I had the most pull requests approved for the entire project this year. and thats only submitting 3 this month since I dont really code anymore.

so ya, lets take a productive developer and make him look at error logs and health monitoring. makes sense.

Jmakin: Nothing really matters. Don't take life so seriously.

I'm on a new team at work that is entirely analytics focused. They use agile. It's a ridiculous choice for data science in my opinion. Why can't we just ****ing use the scientific method? By far the best choice. But idk much about software development or project management, so I'm open to being wrong.

Why not both? Each story is a hypothesis that you investigate. Although trying to get data scientists to estimate how long it's going to take them to do stuff is worse than developers in my experience...

It is SO HARD. Sometimes I'm done way earlier than expected. Sometimes way later. If I haven't worked with the dataset(s) before, then it's even more difficult.

Just do what everyone does when trying to force agile somewhere that it doesn't belong - have standup meetings and fudge everything else.

50% of the benefit agile is the daily standups imo. When I did waterfall, devs (including me) would fall through the cracks and go weeks w/o doing anything - then have to play massive catch up. Daily standups keep devs and the people who are supposed to supply them with work accountable - and everyone is happier for it.

Suzzer,

That would be funny if fortnite wasn't a free game

Is there a Fork Knife or anything similar?

Yeah, we lost a few weeks because our data scientist would find new ways the data was crappy after trying to fit a model to it. Doing more data analysis up front is hopefully a lesson that will get passed on to whoever works on this project later.

Your first mistake is believing this is an actual exchange that took place

and the worst part is forcing devs to do useless administrative crap like tasking story cards. sht, we have even been asked to task a card after its already finished. i

Yeah. I worked at a place where we had these interminable project planning poker sessions where eventually I would just fix the bug (I was on the phone) and request we move on.

Standups are a good idea, IF they are run by someone who is ruthless. You get like, 30 seconds max, anything longer, let's talk privately after the meeting. So the facilitator has to be "boom, you. ok, you're talking too long. next"

Depending on what they use the tasks for it's not useless. If they are just using them as a check mark in the process than they are, but if they use them to see capacity at a finer grained level than the story it isn't. If you look at a scrum board and see someone has 60 hours of tasks left to complete in the last week of the sprint you can start to plan around that. If you see someone just has half their stories to do in the last week you may not see the problem.

If you're tracking tasks in hours, you've already failed to be Agile