2 ms·
There have been a lot of software development methodology but one thing that's been overlooked a lot is the competence of the people doing the execution of the
by AngeloAnolin 7y ago
There have been a lot of software development methodology but one thing that's been overlooked a lot is the competence of the people doing the execution of the project. I am talking not just about the developers / engineers who are building the product but everyone across the pipeline - product owners, business stakeholders, process specialists, business analysts, project managers and just about everyone else.
People attribute failure to the process because it is demeaning to put the blame on people when established best practices can receive the finger pointing.
Stop the notion of being nice to the lack of skills of people. Hiding behind being nice does not resolve the issue but rather propagates it. Fix the issue by providing the grounds for people to learn and become productive.
- mempko 7y agoYes! One thing I don't see people mention is that Scrum requires that everyone on a team to be competent. It's for teams that are already great that want to be even greater. It's not for teams with inexperience and incompetence. My guess is many people are afraid of scrum because it may out them as incompetent.
- perl4ever 7y agoI'm not saying you're right or wrong, but "many people are afraid of scrum because it may out them as incompetent" sounds like the cliche of "X cannot fail, it can only be failed"
- mempko 7y agoYes, it does sound like a cliche. However, the point of scrum is to find problems that get in the way. Through the process, it's clear who knows what they are doing and who doesn't.
- crispyambulance 7y ago> Stop the notion of being nice to the lack of skills of people. Projects don't fail because people are "too nice". Projects staffed with fully qualified people with hardcore skills fail too. And projects staffed with utterly under-qualified people sometimes do just fine. The thing is projects succeed or fail for many different reasons, usually multiple reasons operating in concert. I think the best approach is not to be dogmatic about process and to recognize that "pointing fingers" rarely resolves anything, regardless of whether one is pointing at the process or the people.