riskymagemerge

Stupid title.

Weekly doesn't work for us because we're running a kanban-style process and things change a lot for us. But our meetings are super short most days.

We switched to a hybrid live/async stand-up. We use an automation to post status updates to Slack then jump on to discuss blockers and priorities.

Agile is old. A bunch of the ideas from the manifesto, like f2f communication being best, don't hold up in 2020. We basically made up our own style based on agile, scrum, kanban and a bunch of personal experiences.

I like the "unfocused" part. Constant context switching and lack of understanding priorities is a silent killer. As a lead I try to protect my crew from working on too many different types of projects concurrently because it makes it impossible to really go deep which causes the output to suffer and is less fulfilling for the developer.

I agree some internal, non-production alerts can be both important and urgent. If we merged a big branch without review for some reason, the team needs to have a conversation about it right away.

I know. The bot sucks!!! Sorry... it's my fault. My boss, Dan the author, just yelled at me and I turned it off :-)

Sorry! We know the bot sucks and we just turned it off. Lame marketing people.

Shots fired! It's true though. Using Jira is a struggle.

You have to be an expert in every person on your team job in order to be an effective manager? Not so sure about that part. But I love the hands on automation work he did when he started the team. More managers should do that.

Love this part... “Early on, I figured out that while we have awesome technologists, probably among the brightest in the world, no one knew how to manage development, release, and write good code. So I took charge. Part of leading, especially when you don’t have the title, is putting in the work. Initially, at Cymmetria, I was doing my job plus creating process documents, writing training guides, building automation, helping everyone… It worked for me in the army so I did it again.” Don't wait to be asked to solve the problem, just solve it!

"Keep your instincts. Change your behavior." Great point. The best dev leads know what their people are dealing with but respond as a leader versus a hands-on dev.

Great article! Thanks for sharing.

Maybe it is time to recognize that Scrum (and other variants) didnt really learn anything from Waterfall and need to be revamped altogether.

I.e. this makes me cry - "If they do take time to talk, it's to describe the customer experience so the dev team can connect the dots between their work and real-life use cases." The PO is the new BA. I've only had one great BA/PO. The rest were less than good. Mostly way less.

Anyway, the standups i have seen are either waste of time and/or management getting a daily update.

I like the thing about "dude and a half". It's very true. I can't tell you how many times I had a sales rep ask me when a feature that was supposedly on the roadmap was going to be ready and I had to be like "that task isn't even assigned to a human yet."

What's an example of a metric that engineering and product contribute to equally?

I'm not sure I'm buying the argument that PRs are a repository for institutional knowledge. But I do think thorough reviews are important if you work at a company that has a lot of customers and cares about quality.

Very true! The article doesn't mention that individual teams can't agree but that's another reason velocity is sketchy.

Java-man, I take it you don't track velocity? What metrics do you like to track?

Are VPs really sharing velocity with the CEO? I've never seen that. But I agree it doesn't make sense to try to use story points completed to do comparative performance measurement.

Assume positive intent is one of the most important ideas for teams. Especially right now when we are never in the same room and many of the non-verbal communication clues are gone. I also like heroic courage - never thought of it in a developer context but it totally makes sense. Cool article.

Risky? You sound like an agile coach :-)

Code changes are up and coding time is up... I think developers are taking more time to work on tasks. We get pressure to merge when we're in the office. Now we have more time to experiment and invest in quality.

What's wrong with measuring velocity? I find it useful.

You mentioned middle management do not normally add value to remote development. How would you fix this? Besides removing the layer :-) is there any model where they could add value?

Panda Zoom background... all time.

How do you calculate cycle time?

I don't know if "dozens" of developers constitutes the right sample size. Otherwise, good article.

Haha. That's worse than loser leaves town.

It looks a little high up there. I would not get anywhere near that window.