Agile Analytics

Scrum methodology to implement Agile philosophy for Analytics teams.

Photo by Kelly Sikkema on Unsplash

Waterfall Methodology

Traditionally analytics teams have followed a waterfall methodology to project management. This involves dividing the project into sequential steps involving requirement gathering, development, testing, delivery, and maintenance. The benefits of this approach are that budgeting is easy, however on the flip side there is less to no contact with the customer after the requirement gathering stage up until delivery.

Agile Philosophy

Agile is an alternative philosophy that strives to make production process more efficient and manageable. Agile staggers the project into consecutive iterative sprints. There are many different project management methodologies used to implement the Agile philosophy. Some of the most common include Kanban, Extreme Programming (XP), and Scrum. In this article, we will be focusing on the Scrum methodology.

Scrum Methodology

The Scrum methodology is characterized by short phases or “sprints” when project work occurs. Sprints typically take two weeks, have clear deliverables and are focused on improving the results based on feedback from business users. Each sprint ends with working, tested, ready to ship product. The benefits of this approach are that the customer gets to see the minimum viable product (MVP) quite early.

A sprint can be cancelled (only by the Product Owner) if the sprint goal becomes obsolete due to change in laws or regulations, change in direction of the company, or the technology became outdated.

Scrum Artifacts

Product Backlog Items (PBI): these are user stories or epics. User stories are a way to represent a product feature or functionality in an agile project. They could be about new ideas, features, technical requirements, or bugs. They are usually small enough that dev team can develop half a dozen of them in one sprint. They are always written from a user perspective, for example “As a university student I want to access my marksheet online”. Large user stories are called epics and they are too big to be handled in one sprint so need to be broken down. User stories are not a replacement for requirements documentation.

Product Backlog (PB): collectively, user stories and epics form the PB. This is a prioritized list of PBIs. Items at the top will be implemented soon.

User stories are supposed to be DEEP:

• Detailed appropriately — PBIs to be implemented soon have detailed specifications.
• Estimated — how much time will it take to complete a PBI. More detailed PBIs usually have mode detailed estimation. Some estimation techniques are planning poker, team estimation game, and ideal hours.
• Emergent — suggests that as the project progresses, user stories are added, removed, or rearranged in the PB.
• Prioritized — PBIs are arranged in a way that at top are PBIs that will be implemented soon.

Scrum Roles

• Product Owner (PO): only focuses on one product. They negotiate and communicate with the stakeholders and evaluate the product from a user perspective. Additionally, they also manage the PB ensuring that currently developed features are best choice given current circumstances. They need to be available to answer questions during the sprint and act as the encyclopedia on the product. Lastly, they review the result at end of sprint (during a sprint review meeting) and assess whether the product is ready or needs more work before being delivered to user. POs usually possess extensive domain knowledge and excellent interpersonal skills, and they are responsible and decisive.
• Scrum Master (SM): can work with multiple dev teams, they support but do not manage the team. Their primary role is to ensure that everyone in the team understands Scrum framework and how it is to be applied. They don’t plan the dev teams work or verify the progress they are making, but just promote cross functionality and self organization. Additionally, they eliminate obstacles of dev team during sprints. Further, they strive to maintain effective communication between dev team and PO, and also work closely with the PO to define and organize the PB. SMs are usually courageous, responsible, cool-headed, but most of all adept at influencing. They observe and draw meaningful conclusions, and look for new techniques to improve dev team effectiveness.
• Development Team: is responsible for delivering the sprint goal. In order to do that they decide how many PBIs can be delivered in a sprint and then decompose them into SMART tasks (specific, measurable, achievable, relevant to sprint goal, time-boxed and trackable). They communicate the progress to the SM during daily Scrum meeting. They are good at self-organizing and cross-functionality and know something about everything and everything about one thing.

Scrum Events

• Sprint planning: the project team identifies a small part of the scope to be completed during the upcoming sprint
• Development team work: this is where the development team will actually work on the project backlog items. A Burndown chart can be used to monitor sprint progress. The chart shows number of backlog items identified for the sprint on Y axis and the number of days passed since the start of the sprint on X axis.
• Daily scrum: is a 15 minute meeting held at same place and time everyday. The idea is to Prepare a plan for the next 24 hours specifically identifying what was done yesterday, what will be done today and note down any impediments that can hinder the sprint goal. The Scrum Master is not required to attend this meeting, but ensure that it happens.
• Sprint review: conducted by the Product Owner, this meeting marks the end of a sprint. Scrum team gathers to check the result and get feedback from invited stakeholders. Scrum team and stakeholders collaborate on how to increase the value of the product in the following iteration. Should not last more than 4 hours for a month long sprint and proportionately shorter for shorter sprints.
• Sprint retrospective: led by the Scrum Master, this meeting is a review of the sprint. The goal is to discuss problems related to the process, people, relationships and tools as well as the things that went well and helped the scrum team. Should not last more than 3 hours for a month long sprint and proportionately shorter for shorter sprints. Some techniques that can help gather insights during this meeting are 5 times why, cause and effect diagram, a perfect sprint, the worst sprint ever, one wish, speed dating, undercover boss, a written brainstorm, pessimize, drawing a poster, and political party manifesto. Scrum retrospective is arguably one of the most important meeting led by the SM and deserves an article of its own, which i might write later.
• Backlog refinement: done after a spring, not part of sprint. Facilitated by the Scrum Master, the basic aim of this meeting is to arrive at a list of most defined and ready to implement PBIs for the following iteration. Should not last more than 5–10% of the total sprint duration.

To conclude, in todays day and age it is hard to come by a pure waterfall model to project management. Due to tele-commuting there is always some sort of unorganized agile approach being followed. So what I usually do is try to figure out early on who is playing what scrum roles within my project team and try to streamline and organize the development process using the agile framework. This usually leaves me with a mix of waterfall and agile approach that works best and requires least amount of training within the team to implement.

Hope this article helps you apply agile philosophy on your projects!

Comments welcome!