No, it sounds like you have worked out a good process as opposed to obsessing over tools.
To expand, when I teach people productivity, I keep it simple. I am familiar with both GTD for tasks and BASB/PARA for knowledge. Both approaches boil down in to having a central location to put stuff, organizing stuff around based on how immediate it is, and then having a regular review process to trim excess.
It's very similar to scrum. Dump everything into the backlog, organize it around what's going to be the most actionable, and then periodically trim/refine it.
It's not so much the MBA itself as it is what it represents. An MBA refers to an individual who is a general manager and typically come from sales or finance organization. They generally aren't concerned too much with research and development except they view them as cost centers to be optimized. They tend to be hyperfocused on the bottom line and will do anything needed to maximize profits, even at the expense of the product.
Yes, scrum limits individual autonomy. An effective team that is working together is far more productive than an individual. As a manager/director/executive, I'm far more interested in optimizing and rewarding one of my team's performance than any individual on the team. That's what I mean by "right team right people". I would rather get rid of the 10x developer who is unable to work and communicate with others and instead put a 1x developer who is capable of improving his team. That is what I see as the divide here. Developers are focused on their individual performance whereas I am focused on the whole team.
Yes, because context matters. If you want me to respond to agile, this is why you don’t have management at standup. To prevent micromanagement. My whole point is that there’s nothing inherently wrong (or right) with agile. It’s a process. The success of it depends partly on the people involved. One principle of agile is the right people on the right team.
Yes, at some point, management can ask you to justify the work you did. They are paying you, after all. Scrum and agile was never about letting people do whatever they wanted do. Management has already had a role in making sure there were appropriate limits set. In other words, if you're responsible for building a word processor and end up building a video game, I think it's appropriate for someone to ask what are you doing?
I think I'd disagree here. This article is not about scrum but about trust. Here's a quote from the article:
>As head of sales and marketing, Suresh didn’t need his CEO to buy into the process or give his permission to start the discovery process. He was in charge.
Suresh is a VP of marketing. It's his job to develop a plan, get buy-in, and execute on it. If the CEO is standing in the way, then all this boils down to is that the CEO is micromanaging his VPs. No process can solve for that.
> If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies.
Seems to me that if you can't justify why not keeping your stated commitments was in the interest of the team and the company, then the issue is with your communication and not the process itself.
I find the posting, sharing, and status updates on Facebook to be not valuable, outside of keeping up to date with some family members. I've found the real value of Facebook to be Messenger and groups.
To expand, when I teach people productivity, I keep it simple. I am familiar with both GTD for tasks and BASB/PARA for knowledge. Both approaches boil down in to having a central location to put stuff, organizing stuff around based on how immediate it is, and then having a regular review process to trim excess.
It's very similar to scrum. Dump everything into the backlog, organize it around what's going to be the most actionable, and then periodically trim/refine it.