The Radiating Programmer
dev.37signals.com
The Radiating Programmer
1–10 of 33 posts
Re: The Radiating Programmer
#2Radiating as in “radiate information”.
Re: The Radiating Programmer
#399% of the problems Scrum/Agile/Whatever try to solve boil down to “communicate more, more often”.
I personally have no issue with a daily stand up, but then it’s always been basically the only meeting in my day and 9 times out of 10 people have stuck to a structure and always shared something interesting and useful about their day. If you just say “no blockers” you’re doing it wrong in my opinion.
If writing and sharing works best for a team then do it that way however we, as devs, need to realise we work in service of a broader business so if we don’t do a good job communicating what we do then that business will force something on us.
Re: The Radiating Programmer
#499% of the problems Scrum/Agile/Whatever try to solve boil down to “communicate more, more often”. I personally have no issue with a daily stand up, but then it’s always been basically the only meeting in my day and 9 times out of 10 people have stuck to a structure and always shared something interesting and useful about their day. If you just say “no blockers” you’re doing it wrong in my opinion. If writing and sha…
> If you just say “no blockers” you’re doing it wrong in my opinion.
This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. No non-technical staff from the above list should have a right to challenge estimates. No product owner can belong to the above list. There should be openness when technical decisions made by a team get overriden from people on the above list. Especially when something painful like a terse edict to the effect of "allow x and y from security and audit team full, direct, read-write-execute permission to the backing data store of your micro service in production".
If there is no communication from the top, or there are negative consequences for speaking up, expect people to mentally check out.
Re: The Radiating Programmer
#599% of the problems Scrum/Agile/Whatever try to solve boil down to “communicate more, more often”. I personally have no issue with a daily stand up, but then it’s always been basically the only meeting in my day and 9 times out of 10 people have stuck to a structure and always shared something interesting and useful about their day. If you just say “no blockers” you’re doing it wrong in my opinion. If writing and sha…
> If you just say “no blockers” you’re doing it wrong in my opinion. This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. No non-technical staff from the above list should have a right to challenge estimates. No product owner can belong to the above list. There should be openness when techn…
> This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call.
not sure how I'd've ever justified suggesting engineering standup without our engineering manager present
Re: The Radiating Programmer
#6I'd rather have a 5-10 minute standup than have to write such an oddly detailed report twice a week on what I "weighted" in on.
Re: The Radiating Programmer
#7LOVE IT. MAYBE IM JUST HIGH
Re: The Radiating Programmer
#8I'd rather have a 5-10 minute standup than have to write such an oddly detailed report twice a week on what I "weighted" in on.
Same. I don't want to have to write OR read those reports, and a quick daily stand-up is far better, IMO, for effective communication.
Re: The Radiating Programmer
#9Earlier quoted context omitted.
> If you just say “no blockers” you’re doing it wrong in my opinion. This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. No non-technical staff from the above list should have a right to challenge estimates. No product owner can belong to the above list. There should be openness when techn…
> This only works when you trust your team members. This means absolutely nobody who can fire me on the spot, not my supervisor, not my skip, not the CEO/CTO/VP should be on the call. not sure how I'd've ever justified suggesting engineering standup without our engineering manager present
It sounds like your dev team isn't very empowered.
In the companies I work at we can create whatever ceremony our team deems nessesary as long as we're meeting our metrics.
Re: The Radiating Programmer
#10How about the person who needs the info to do their job should go get it.