Agile Framework Scrum

Scrum is an agile way to manage a project. Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process. It provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge. Scrum, occurs in small pieces, with each piece building upon previously created pieces. Scrum emphasizes empirical feedback, team self-management, and striving to build properly tested product increments within short iterations. This emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike.

But what allows the Scrum methodology to really work is a set of roles, responsibilities and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic. Scrum provides structure to allow teams to deal with that difficulty. However, the fundamental process is incredibly simple, and at its core is governed by three primary roles.

Product Owners determine what needs to be built in the next thirty days or less. Development Teams build what is needed in thirty days (or less) and then demonstrate what they have built. Based on this demonstration, the Product Owner determines what to build next. Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.

The Scrum model sees daily stand-ups as a way to synchronize the work of team members as they discuss the work of the sprint. At the end of a sprint, the team conducts a sprint review during which the team demonstrates the new functionality to the PO or any other stakeholder who wishes to provide feedback that could influence the next sprint. This feedback loop within Scrum software development may result in changes to the freshly delivered functionality, but it may just as likely result in revising or adding items to the product backlog. Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting, including the Scrum Master and PO. The meeting is an opportunity to reflect on the sprint that has ended, and identify opportunities to improve Scrum Values.

Courage - The SM needs the courage to protect and guide the Team.

Standing up to the PO and Stakeholders at the right time, really takes guts.

The PO must have the courage to entrust the Sprint Backlog to the Team, a giant leap of faith as it is the PO who answers to the Stakeholders at the end of the sprint. Finally the Team must have the courage to aggressively commit to as much work as they think they can do each sprint.

Respect - In Scrum, the limits and boundaries of the Scrum roles really need to be transparent, and respected. Everyone on a scrum project needs to be aware that the PO is in charge of what the Team works on, but not how they do their work, and that the Team is responsible for getting the work done, but not questioning what work gets done.

Feedback - Get feedback quickly and often to uncover defects early. Many agile development practices focus on decreasing the time taken to get feedback. This helps eliminate waste and build quality in.

Communication - They are small teams, the optimum size for effective collaboration is 5-9 people; not too large so that communication becomes an issue, not too small that overhead is excessive. Effective communications reduces the amount of noise between communicating parties.

Simplicity- All you need to know is KISS: Keep It Simple, Sweet! That's all. Having unnecessary complex processes creates waste, and in agile we focus on eliminating waste.