This post is in response to the following article: http://scrumprimer.org/scrumprimer20_small.pdf
Working for ASAP has exposed me to some concepts of the SCRUM system. I didn’t realize it at first, but now that I have looked into it with these readings, it becomes even more clear what it means. However, I can also see where ASAP’s method deviates significantly from this idea.
I think the part I like most about this working method, is that it is well planned and allows the team to work out the issues and manage themselves. Typically they are the ones with the most experience, and they also know what they do know and don’t know. This puts them in a better position to estimate the amount of time required to complete certain tasks, and then distribute them out.
Another aspect that I enjoy is that it is very flexible and very open about the communications required in order to continue progress as well as identify issues. I noticed how this was useful to Jacob and I’s work as we worked on our dark version of Haggis. We operated in a very similar way as we broke down the tasks, worked on them separately, and then brought them together. When one of us had issues, a simple conversation was extremely beneficial.
We were able to start off our day with the question of “What are you doing today?”. This gave us the opportunity to speak about the time we had invested in the project, but also identify where we had commitments to other tasks. Maintaining this communication was important and afforded us a very quick development turn around.
Adaptation is important in any situation. Scrum allows for the team to be flexible to changing standards. Though, having each sprint being locked down is a wonderful balance. Allow the team to complete the work they need to do, and any changes or new features are applied in future sprints. As a developer, I have noticed that it is easier to focus on the things that I can build, bring it to completion and have a working model. If it can be improved or redone, then great, but a working system is available in the interim.
Which brings me to my final point. The idea of having a potentially release ready product at the end of each sprint is a really nice concept. Having something that works is the most important aspect of product development. Even if it is not the entire concept that the customer wanted. It at least shows that the team can assemble a working product, and marked improvements can be noticed as each sprint is completed. Not only is this good for business dealings, but it also helps the product owner have confidence and peace of mind.
- How can the SCRUM methodology be applied to everyday tasks or long-term personal goals?
- Are you surprised that the scrum methodology has each team member working only four to six hours on a project? How does this compare to traditional team projects?