August 25, 2012 at 12:35My look at Scrum
Over the years of participation in software development, I have come up with 3 rules for myself , the intersection of which gives the desired result: Do the right thing correctly and quickly. Curious to see how Scrum helps us achieve these goals.
The right thing - Scrum doesn't even care if the right thing is being done. The formation of the backlog is left to the product of the obner. The development team doesn't really care if they do the right thing or not. There is a scapegoat - an oouner product. With him and all the demand. The product of the OUNER turns into a monumental figure, which should know everything about users, know everything about the market, know everything about trends, generally know the dofig of everything in order to single-handedly decide which product to do.
Moreover, attention, quote
By and large, the success of the entire product is based on the product of the OUNER. If he has a file, it doesn't really matter which cool beavers were on the team and what cool coverage test on the project.
Things are right - Scrum generally does not care how what is done. This is left to the team. The main thing is that the team get together and discuss what is right and how do we do things right in general. How the team does this - Scrum absolutely does not care. Scrum suggests that the team is cool enough to improve their process. Unfortunately, this is not always the case. For example, a team without experienced developers is unlikely to be able to quickly figure out what is good and what is bad.
Quickly- Scrum generally do not care whether things are done quickly. As a team can - it does. Maybe fast - great. It can’t - let's get together and talk about how to fix the situation. For this, we have retrospectives.
At least something good- in fact, Scrum still provides something, it speeds up feedback and strongly recommends creating cross-functional teams. For a manager who was waiting for the result of the project for a year, to see a working version with limited functionality after 3 months seems like a miracle. It became possible for him to poke buttons and say that here the system behaves unexpectedly. It became possible for him to influence the further development and choose features by priority. Reducing the feedback loop is by and large the only useful thing that Scrum definitely gives. Everything else comes directly from Scrum trainers, from their personal experience and vision of the software development process.
Due to the external simplicity of the process, Scrum seemed very attractive to many managers. But for an inexperienced team without external consultants, improving their Scrum-based process is difficult. This is a laborious and lengthy process that can take years.
Scrum alone is not a strong innovation. He was just lucky. Extreme programming contains almost the same things, but has not gained such popularity. Scrum commercialized and managed to become the number 1 methodology in the agile world through marketing. Nevertheless, it serves as a good basis for the development and construction of its own processes. With some refinement with a file (but rather tuning), Scrum can be turned into a good development process.
The right thing - Scrum doesn't even care if the right thing is being done. The formation of the backlog is left to the product of the obner. The development team doesn't really care if they do the right thing or not. There is a scapegoat - an oouner product. With him and all the demand. The product of the OUNER turns into a monumental figure, which should know everything about users, know everything about the market, know everything about trends, generally know the dofig of everything in order to single-handedly decide which product to do.
Moreover, attention, quote
The Product Owner is not part of the team
By and large, the success of the entire product is based on the product of the OUNER. If he has a file, it doesn't really matter which cool beavers were on the team and what cool coverage test on the project.
Things are right - Scrum generally does not care how what is done. This is left to the team. The main thing is that the team get together and discuss what is right and how do we do things right in general. How the team does this - Scrum absolutely does not care. Scrum suggests that the team is cool enough to improve their process. Unfortunately, this is not always the case. For example, a team without experienced developers is unlikely to be able to quickly figure out what is good and what is bad.
Quickly- Scrum generally do not care whether things are done quickly. As a team can - it does. Maybe fast - great. It can’t - let's get together and talk about how to fix the situation. For this, we have retrospectives.
At least something good- in fact, Scrum still provides something, it speeds up feedback and strongly recommends creating cross-functional teams. For a manager who was waiting for the result of the project for a year, to see a working version with limited functionality after 3 months seems like a miracle. It became possible for him to poke buttons and say that here the system behaves unexpectedly. It became possible for him to influence the further development and choose features by priority. Reducing the feedback loop is by and large the only useful thing that Scrum definitely gives. Everything else comes directly from Scrum trainers, from their personal experience and vision of the software development process.
Due to the external simplicity of the process, Scrum seemed very attractive to many managers. But for an inexperienced team without external consultants, improving their Scrum-based process is difficult. This is a laborious and lengthy process that can take years.
Scrum alone is not a strong innovation. He was just lucky. Extreme programming contains almost the same things, but has not gained such popularity. Scrum commercialized and managed to become the number 1 methodology in the agile world through marketing. Nevertheless, it serves as a good basis for the development and construction of its own processes. With some refinement with a file (but rather tuning), Scrum can be turned into a good development process.