September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I think everybody has a specific situation when they try Scrum (or anything else) for the first time and will make their own learnings.
If they come from a command and control culture (shooting the messenger) and strive for efficiency (not making mistakes), now moving to not only accept but work from experiments and failures can be a major change in perceptions and mindsets. Or not.
A good scrum master will help to change the culture and remove impediments also with perceptions.
The biggest challenge in Scrum or any agile framework is to be able to sufficiently change the system (i.e. the environment/process/tools/culture/policies in which people operate) to "fit" the framework's values, pillars, roles and practices.
The difficult part of Scrum is to undersand what Scrum really is which is stated into the Scrum Guide. When you understand it then the next step is to fill the framework up with the tools and techniques best fits for your current situation.
This is very good advice so far, thank you all! Sounds like a lot of practice, with open-mindedness and adaptation.
"Let the team make mistakes" and "buying into the model" sound like two ways of saying the same thing. The hardest part is often changing an organization's culture and practices such that teams are trusted and supported rather than being heavily managed to a plan.
Any cultural change is hard in an organization
The biggest challenge for Scrum Master is not to implement the Agile framework but before that he/she has to get everyone's buy-in. If the team or teams are not ready for change it will be big huddle for SM to move forward or to be successful. In such scenarios the expert SM can be ideal candidate. New role SM will see things more challenging than the expert one.
If the SM is great coach, SM can coach and train them to learn and avoid mistakes instead of allow them to make mistakes. SM primary responsibility is to avoid the scope creep and gold plated work. If SM allows mistake and team knows its allowed, project CPI and SPI will not look pretty
The main factor that determines the success of a team is the hard skills of the team members. Scrum can't make developers write better code or do a better job in general.
If you have poor or inexperienced developers and team members you will fail with Scrum, if you have competent team members you can succeed even with no methodology at all. I have seen this happen.
I have a software development background and I don't like Scrum at all. I don't know any other developer that likes it. I read different discussion threads about this and the majority of the developers hate Scrum with a passion.
I have read some opinions that are a paradox for me. Scrum is supposed to shift the culture from command and control to a culture where the employee has more independence and is more involved in the decision making process. Many developers however feel quite the opposite, they feel that in Scrum they are being micromanaged while when using other non-Agile methodologies they fell more independent.
In extreme cases Scrum is used for performance evaluation of the employees leading to a terror environment for them. For instance some Scrum metrics can be used to fire the team members that appear to be low performers.
So I would say that the most difficult part of Scrum is the fact that many software developers hate it making it hard for the so called Scrum/Agile promoters to implement it properly. Not to mention management that uses the Scrum metrics to evaluate the performance of their staff.
In software development, I've experienced usually waterfall being used for the hardware projects, and agile used for the software projects. Change within the organization's culture was far more prevalent with the agile/scrum framework. Not so much with hardware.
Please login or join to reply