God bless this post. I am test shaman. But also have to be grug. "Make something idiot proof and I'll find you a better idiot," is my motto. Mostly because of this, both in implementation and...
God bless this post. I am test shaman. But also have to be grug. "Make something idiot proof and I'll find you a better idiot," is my motto. Mostly because of this,
complexity very, very bad
both in implementation and end-user experience. It also makes it really hard to test. And that sometimes means that it's really hard to use, too.
sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
My least favorite manager is like this. Your success is his glory, and your failure is your incompetence. I much prefer this, instead of having to explain to him and his higher-ups why something doesn't work.
very important senior grug say "this too complicated and confuse to me"
Complexity just leads to a constant friction when hunting bugs. I didn't write the code. I didn't break the code. I found it broken and reported it. If I miss a bug, it's also somehow my fault?
And that manager is probably getting paid a lot more money and is next in line to get promoted. I suspect it's this feedback loop that results in so many organizations headed by sociopaths.
My least favorite manager is like this. Your success is his glory, and your failure is your incompetence.
And that manager is probably getting paid a lot more money and is next in line to get promoted. I suspect it's this feedback loop that results in so many organizations headed by sociopaths.
He actually did get promoted about a year back… everyone was stunned at the decision and voiced their concerns to the higher ups. If he gets promoted another level I will seriously consider a...
He actually did get promoted about a year back… everyone was stunned at the decision and voiced their concerns to the higher ups. If he gets promoted another level I will seriously consider a switching jobs to a different organization.
As someone that believes agile values and principles can help teams beote effective, how can I be a good agile shaman? I'm a product manager and not a scrum master or coach, but I do advocate for...
As someone that believes agile values and principles can help teams beote effective, how can I be a good agile shaman? I'm a product manager and not a scrum master or coach, but I do advocate for improving practices based on the agile manifesto.
I've never had to actually accomplish this so it's probably easier said than done. The only important parts are the parts in the original Agile Manifesto, everything else is a way someone has...
I've never had to actually accomplish this so it's probably easier said than done.
The only important parts are the parts in the original Agile Manifesto, everything else is a way someone has thought of of accomplishing those items, or to sell a workshop.
Know what you're trying to accomplish with agile processes before suggesting or implementing them. What specific goals are you hoping to achieve with them? How would you explain it to the team that has to live with the processes what value it brings and which of their problems it can help solve.
If it doesn't seem to be working, ditch it. If people don't seem engaged or are straight up unhappy with processes that have been introduced, ask them why, ask them what they think could improve it, and be ready to ditch it if it doesn't work.
What may work for one team may not work for a lot of others. Enabling a high performing team is mostly about finding out what works best for them and to keep them engaged.
The parts of scrum/agile that people tend to hate are things like: when people get really bogged down in jira, pointing being used as time estimates instead of complexity estimates, being held to deadlines without being able to cut scope, having processes forced on them, having scrum processes eat up a lot of time, etc.
Thanks for the thoughtful response. I think I try to behave in this way and definitely agree with what you've said. I'll keep this in mind in the future.
Thanks for the thoughtful response. I think I try to behave in this way and definitely agree with what you've said. I'll keep this in mind in the future.
Couldn't have said it better than an angry tiger. I think the problem is scrum masters trying to justify their own existence by confusing the process with the end goal and turning every...
Couldn't have said it better than an angry tiger. I think the problem is scrum masters trying to justify their own existence by confusing the process with the end goal and turning every recommendation into mandatory overhead that more often than not has the opposite effect and just gets in the way.
God bless this post. I am test shaman. But also have to be grug. "Make something idiot proof and I'll find you a better idiot," is my motto. Mostly because of this,
both in implementation and end-user experience. It also makes it really hard to test. And that sometimes means that it's really hard to use, too.
My least favorite manager is like this. Your success is his glory, and your failure is your incompetence. I much prefer this, instead of having to explain to him and his higher-ups why something doesn't work.
Complexity just leads to a constant friction when hunting bugs. I didn't write the code. I didn't break the code. I found it broken and reported it. If I miss a bug, it's also somehow my fault?
And that manager is probably getting paid a lot more money and is next in line to get promoted. I suspect it's this feedback loop that results in so many organizations headed by sociopaths.
He actually did get promoted about a year back… everyone was stunned at the decision and voiced their concerns to the higher ups. If he gets promoted another level I will seriously consider a switching jobs to a different organization.
Everyone everywhere hates the Agile Shaman.
As someone that believes agile values and principles can help teams beote effective, how can I be a good agile shaman? I'm a product manager and not a scrum master or coach, but I do advocate for improving practices based on the agile manifesto.
I've never had to actually accomplish this so it's probably easier said than done.
The only important parts are the parts in the original Agile Manifesto, everything else is a way someone has thought of of accomplishing those items, or to sell a workshop.
Know what you're trying to accomplish with agile processes before suggesting or implementing them. What specific goals are you hoping to achieve with them? How would you explain it to the team that has to live with the processes what value it brings and which of their problems it can help solve.
If it doesn't seem to be working, ditch it. If people don't seem engaged or are straight up unhappy with processes that have been introduced, ask them why, ask them what they think could improve it, and be ready to ditch it if it doesn't work.
What may work for one team may not work for a lot of others. Enabling a high performing team is mostly about finding out what works best for them and to keep them engaged.
The parts of scrum/agile that people tend to hate are things like: when people get really bogged down in jira, pointing being used as time estimates instead of complexity estimates, being held to deadlines without being able to cut scope, having processes forced on them, having scrum processes eat up a lot of time, etc.
Thanks for the thoughtful response. I think I try to behave in this way and definitely agree with what you've said. I'll keep this in mind in the future.
Couldn't have said it better than an angry tiger. I think the problem is scrum masters trying to justify their own existence by confusing the process with the end goal and turning every recommendation into mandatory overhead that more often than not has the opposite effect and just gets in the way.
Oh this was fun read. And very quotable too.