Maria Mannani, Scrum Master | August 20, 2019
Due to constant changes in technology, business, and the wants or needs of the client, Agile frameworks and methodologies are becoming increasingly necessary for development teams to implement. Previously, development teams used a traditional framework called the Waterfall method. This method is best suited for projects that require very little adaptation to change and have rigid deadlines. Another aspect of this traditional framework is that client or stakeholder feedback is only provided at the beginning and the end of the project. The most common issue with this scenario is the customer’s priorities have shifted, therefore the project completed by the development team isn’t ideal or in some cases, useless. Since technology is constantly evolving, the methodologies used by development teams should be adaptable as well.
This is where Agile and Scrum come in.
Agile Development is more than just an approach for completing work, it’s a mindset that encompasses the values of the Agile Manifesto and the 12 Principles behind it, allowing teams to create, respond and adapt to change. This framework places importance on people and their interactions rather than the processes and tools being used. It also ensures the work completed is regularly evaluated, functional and releasable to provide the most value to the customer.
There are several different Agile frameworks – Scrum, XP (Extreme Programming), or Feature-Driven Development. The term “Scrum” is derived from rugby and it refers to the manner that the team works together to move the ball down the field to achieve a goal. Scrum is based on the simple concept of starting a project, regularly checking in, ensuring the project is headed in the right direction, and validating that it is meeting its intended purpose. It also allows those who are working on said project to self-organize and consistently evaluate how they are working together as a team.
There are five Scrum events: The Sprint, Daily Scrums, Sprint Review, Sprint Retrospective, and Sprint Planning. Scrum teams work in Sprints. The Sprints can last from one to four weeks. The Sprint contains all the work done within the Sprint and is encompassing of the five Scrum events.
During the lifecycle of the Sprint, the teams have Daily Scrums (15 minute timeboxed meetings) where each team member answers these three questions: What did you do yesterday? What are you doing today? Are there any roadblocks or impediments that may stop me from completing my work? These meetings occur at the same time each day.
At the end of the Sprint, a Sprint Review will take place. This is the time for the team to showcase and demo the work they completed during the Sprint to the stakeholders. The Product Owner (PO) will also provide insight about what is coming in the next Sprint. While the team is not required to release at the end of the Sprint, one of the advantages of Scrum is that the team has completed an increment of work that is functional and could be implemented if the PO chooses.
After the Sprint Review, the Scrum team will take part in a Sprint Retrospective where they will inspect and adapt their process by evaluating what went well, what didn’t go well, and how can they improve in the next iteration/Sprint.
Once Sprint Retrospective is over, the team will go into Sprint Planning where they determine what they’re going to complete in the next Sprint and how they will execute upon that work.
Scrum teams are comprised of three roles: Product Owner, Scrum Master, and Development Team. The primary responsibilities of the Product Owner are the vision of the product and creating and prioritizing the backlog. The backlog is a prioritized list of features and defects containing descriptions of functionality and/or how the product should behave. Product Owners work as an interface between the needs of the stakeholders and the Development Teams execution of the backlog stories. The Product Owner will also validate if the solutions put in place by the Development Team are acceptable.
A Scrum Master’s primary duties include ensuring that the Scrum team follows the Agile values and principles and the Scrum process, removing impediments, and protecting the team from interruptions/disruptions that would prevent them from completing the work in the Sprint within the designated timeframe.
A burndown chart is used to monitor the progress of each sprint. The outstanding work is placed on the vertical axis with the time (the Sprint timeframe) along the horizontal axis. When measuring progress, if the actual work line is above the ideal work line, the project is most likely behind schedule, as there is more work to do than originally estimated. The reverse of this means the project is most likely ahead of schedule. The chart should trend toward zero. While this makes the Sprint work visible, it also keeps the work running on schedule and allows for any impediments or roadblocks in the Sprint to be identified and addressed as they come up.
The Development Team is responsible for estimating the amount of effort necessary for them to complete the work in the Sprint. They are also responsible for accomplishing and validating (testing) the work in the Sprint to ensure that it is functioning correctly and meets the acceptance criteria that was outlined by the Product Owner. While individuals on the team may take the lead on certain work items, the team as a whole is responsible for completing all items within the Sprint.
While there are benefits to traditional methodologies, Agile seems to be the best fit for development environments due to the frequent changes in technology, business, and end users’ needs. An agile approach aims to provide high value work and consistent deliverables while also increasing transparency and visibility not only into a single project, but within an organization. Due to the increased visibility and transparency of projects this framework provides, Agile can also be the beginning of a cultural transformation within an organization.