This website uses cookies and similar technologies to understand visitors' experiences. By continuing to use this website, you accept our use of cookies and similar technologies,Terms of Use, and Privacy Policy.

Feb 28 2014 - 09:50am
Scrum and Team Building
Pranav organized a team building session yesterday for the development team. During the session, people expressed their concerns and ideas regarding how to better coordinate the work between each other when working on a bigger project. People discussed issues like meeting participation, bug tracking, dependency of work, prioritization of work, etc. Particularly, we discussed in depth what ownership is and how we should take it in our work. In the end, we figured out a list of rules, which are believed to resolve the concerns people mentioned as well as to help fulfill people's suggestions for making work easier. The software engineering domain has come up with various software development life cycle models for regulating development work, each targeted for a specific project category. The EdLab development team has been adopting the agile development model and has benefited from the many advantages of it, including iterative expanding of project, testing-driven development, periodical review of code, etc. Agile development model is a wide concept and many of the details of how it is applied are to be determined by the teams that use it. And that's exactly exemplified by what we did during the team building session yesterday. And hopefully we'll need more such sessions in future to work out a more complete scheme of applying agile development in our work. As the concept of agile development is wide and we started to be concerned about more specific rules, a natural question is whether there already exists a development life cycle model that is more concrete and provides some out-of-the-box rules. The answer to this is yes after I did a research online. The model is named Scrum (wikipedia link). Scrum is a variation of agile development model. It's actually a specification of agile. It has some interesting rules about how the team is managed, what roles people take, how a development cycle takes place and what specifically people do in such a cycle. Basically there are three main roles in a scrum team, product owner, development team and scrum master. The development team is made up of 3 to 10 people, each is capable of cross-functional work. Product owner is responsible for creating user stories in the product backlog and prioritizing them. Scrum master is the role to keep the team focused on their objectives and help remove impediments to their work. The very interesting concept is "sprint", which refers to a cycle of the development work. Each sprint is preceded by a planning meeting and followed by a retrospect meeting. In the planning meeting, people discuss with the product owner and specify which part of the product backlog should become the backlog of the upcoming sprint. They also specify a timeline for the sprint. During the sprint, the development team is focused on the sprint backlog, which is not subject to any change from outside the development team. When the time is up, the work should stop immediately even if part of the sprint objectives are not fulfilled. Tasks that are not fulfilled are moved back to the product log. In the retrospect meeting, people review their work during the sprint. The good thing I see from the definition of sprint is that it gives clear information of what should be done and how it should take place in each development cycle. It's also robust because it allows unfinished tasks and makes people restart working on them after retrospect. Although Scrum doesn't provide details for everything we are concerned, the rules it gives do provide a clear and concrete scheme of how the agile development model can be carried out in a well-organized way.
Posted in: Knowledge SolutionsEDAR|By: Yudan Li|894 Reads