Hello fellas, how is the diving experience coming along so far? I hope you enjoyed your snorkeling experience last week. 🙂

This week we are going for a Scuba dive in the Sea of Scrum, are you all set and ready for this one? You betta SUIT UP ! 😉

What is Scrum?

As discussed in my last article, Scrum is an Iterative and Incremental approach to product / software development – developing small pieces, with each one built on top of the previously developed piece. Developing product one small piece at a time helps foster creativity, helps the teams respond to feedback sooner, helps them absorb change more swiftly, and hence helps them build a well polished product without losing any competitive edge.

Scrum is one of the most popularly adopted flavors of agile software development. It definitely provides a lot of flexibility to the teams, yet there are some ground rules to be followed, like do attend your meetings, lol ;-). If we compare different software development frameworks, scrum is more adaptive than prescriptive when compared to RUP and XP. And at the same time relatively prescriptive than Kanban and “Do Whatever!”. So to me, Scrum strikes that perfect balance on the scale of being adaptive vs. prescriptive. It provides just enough structure for the teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

However, note that all this still doesn’t make Scrum a silver bullet, “One scale DOES NOT fit all”, does it?

 

Building blocks of Scrum

Product Owner, Scrum Team and Scrum Master. Product owner drives the requirements (epics, features and user stories) which the development team takes on and churns out working pieces of software/product, and the scrum master, in this whole process, acts as a referee, as a protective shield, as a coach, as a mentor for the team and despite of being a process advocate, ensures that the process doesn’t get into the way of product development. Process is to help the product, not impede its development.

Lets consider an analogy for better understanding – A NASCAR or RALLY race.

The objective in a Rally race is to get from the start to the end point, can be a circuit loop in case of Nascar racing or a point-to-point format in case of Rallying in which the participants and their co-drivers drive between set control points. To win such a race, you need a great performing car, a skilled driver and an experienced co-driver. The great performing car (development team) plays the most critical role, it ensures that the crew gets from the start point (requirements) to the end point (working software). However, the car doesn’t drive on its own, it needs a skilled driver (Scrum Master) who can drive the car with great skill, maneuver through the sharp turns swiftly and a lot more. But again, the driver needs assistance with the right directions, the best possible route and several other things, which brings the co-driver (Product Owner) into the play. So…

The Car = Development team

The Driver = Scrum Master

The Co-driver = Product Owner

Start Point = Requirements

End Point = Working Software

Hence, the three building blocks of Scrum are the Development Team, the Scrum Master and the Product Owner.

Product Owner (PO) determines what needs to be developed in the near future, provides business directions, builds the product road-map, generally work worth of 2-3 sprints and/or 2-3 releases. He acts as the voice of the Business.

Development Teams build/develop what needs to be developed and they do so in small cycles, generally ranging from anything between 1-4 weeks. Once done with the development, they demonstrate their work and gather feedback from the PO or any stakeholder involved and based on this feedback, they decide their strategy for the next cycle (Sprint). And hence they deliver working pieces of code/software sprint after sprint – a repetitive process, where they improvise each time based on the feedback and their own learnings from the previous sprints.

Scrum Master(SM) is the choreographer of this entire show. He ensures that this entire process happens as smoothly as possible. He ensures continuous improvement of the process, people (teams) and the product – the 3 Ps.

The Scrum Rituals

The Scrum Master aka Process Advocate is responsible for hosting / facilitating / organizing most of the scrum rituals. If we go by the book, there are four mandatory scrum meetings – Sprint Planning, daily Stand-Up, Sprint Demo and Sprint Retrospection (in chronological order). I am going to describe below how these meetings should be run in a ‘by the book’ fashion. We will go over different ways of conducting these sessions and much more in upcoming articles.

Sprint Planning is conducted on Day 1 of the Sprint, safe to say, it marks the start of the Sprint. By the book, planning session is an all day event, divided into two halves – Planning I and Planning II. In the first session, the PO and/or BA/BSA walks the team through a list of User Stories (requirements) in the order of priority, aka, Product Backlog. They explain how business expects the end product to look like, what is to be developed as part of the user story, define the acceptance criteria, address any questions the team may have. In the second session, team revisits the prioritized backlog to size the stories, break them down into actionable tasks and provide estimates on each of these tasks. Based on their velocity and capacity they then pull user stories into the Sprint Backlog. Sprint Backlog is the commitment of amount of product the team will deliver by the end of that sprint. Each of these sessions generally last around 4 hours.

Daily Stand-Ups is one of various ways to inculcate and improve the habit of constant communication and coordination within the team. In this 15 minute time-boxed meeting each of the team members provide an update on what they worked on the last day, what their plan is for the current day and if they have any issues / impediments. This brief meeting happens at the same place, same time everyday.

Sprint Demo is a time for the team to get feedback on what they have built/developed in that sprint. They demonstrate their work (generally a working piece of software) to the PO and any other stakeholders (there are NO restrictions on who should be an audience to this meeting). The feedback can be anything from a thumbs-up to push to production to bad implementation or a need for rework. Think of this meeting as an opportunity for Course Correction, if need be.

Sprint Retrospection is that one time opportunity every sprint where every team member can speak their heart out about how they felt about the sprint, what they feel went well and what did not go that well or areas for improvement, and discuss any kind of issues (even inter-personal)… ALMOST anything under the sky. And they can be as open and candid as possible as there is nothing to fear about, the audience is strictly limited to the team members and the scrum master and it is almost like “What happens in Vegas, stays in Vegas”. 😉

There are a few other rituals / meetings that most of the organizations have as part of their Sprints and Releases, and we will discuss them in detail in our next article “The Real World Scrum”.

So at this point we pretty much know what Scrum is, who are the key players and what the various events are in Scrum. And you may be thinking, “Wow! this ain’t that difficult to do”. Well hold on my friend, I may have made Scrum sound very simple and easy, however, Scrum is much more than a simple framework, it supports our need to be human and not be machines or slaves at work, our need to learn, to grow, to do, to create, to improve, to interact, to value, to respect, and a lot more than we usually do.

“To be a better professional, be a better human!”

In the next article, we will try to build a bridge between this “by the book Scrum” and “The Real World Scrum”. Happy Reading!

Wish you all a very happy Thanksgiving Week, enjoy the delicious Turkey and all the yummylicious deals on Black Friday. Be safe and have fun! 

– Nirbhay Gandhi