Do you really know SCRUM?

Fail Fast, Learn Fast, Feedbacks

I guess we all know about SCRUM, nearly every software company is being Agile and following SCRUM. But, Why? What about old Software Development LifeCycles? Are they faded?

Maybe yes, there’s a continuous requirement of delivering the software to the stakeholders or the client. The old Waterfall Model, the base model of the Software Development Life Cycle is still good for learning, understanding the process, and core concepts but, no longer good practice. The rigorous planning and deterministic approach doesn't work in today's scenario. The delivery of software to the stakeholder after a year isn't a good idea as the business requirements are subject to change, and there isn’t enough scope or flexibility to make that change. The Software product developed with a deterministic plan might be a great one, bug-free, but if requirements are variable, the product, teams are doomed to failure. The product might be no longer useful to the client.

Most of us might know SCRUM only as a Scrummage, where we break the software into smaller pieces which allow teams to deliver milestones as small pieces but there’s still much to be done in Scrum.

Is the Agile methodology, and SCRUM the same?

No, they have some minor differences,

• There's no Team Leader in SCRUM, the entire team jumps in to address the issue or problem.
• Agile has a small but expert product development team, the vision is clear. In SCRUM, requirements are rapidly changing.
• SCRUM fosters a self-organizing, cross-functional team, the team works independently whereas, in agile leadership plays a vital role to fulfill all the tasks appointed.
• Agile frequently delivers software build to the end-user for feedback, whereas SCRUM delivers to the client for feedback. Regular feedbacks build more robust software, as well as team, builds trust & relationship with progress.

What exactly is SCRUM?

Scrum is a framework for Agile Software development or Feature-Driven Development. This means we actively deliver features throughout the project to our business partners. Also, measure success using completed software. The scrum allows us to fail fast. We don't have to wait until a year to know we have delivered a failed software. 

Let's breakdown the SCRUM Framework step by step:-

The first and foremost important thing is product vision, decomposing a vision, we have to identify themes -

Let's take an example of a restaurant, every customer has its profile, orders, payments, delivery. These are critical things to be developed for Minimum Viable Product.

MVP is when a product has been developed just enough to get user feedback. This allows for a fast feedback loop and reduces scope creep.

The second step, we break down themes into features

• Profile to have a simple login, password,
• Orders page to have recently placed orders,
• Menu list for the order to be placed, nearby delivery locations.

The third step is to create User Stories,

It is a detailed, valuable chunk of work that the team can deliver quickly.

INVEST Acronym

• I - Independent
• N - Negotiable
• V - Valuable
• E - Estimable
• S - Small, usually completed in 1 sprint
• T - Testable

It can be written down as a user role, user requirement, desired benefit.

User Story, non-functional aspects like as a developer I'd like to upgrade the Database to the latest version so that we have a well-supported version.

Must have dedicated acceptance criteria,

• Customer name, phone number, a password is captured and saved.
• Additional acceptance criteria:- Must have a forgotten password reset, strong authentication to reject the invalid email, password.

Success to be mapped by a Team Boundaries: A proper definition of done like the product has been code reviewed, thorough testing is done in a pre-release environment with errors fixed. Backlog prioritization - the most valuable stuff is delivered first.

Fourth, Sprint, each user-story to be completed in a sprint, and each Team-member is aligned to a dedicated story. Sprint Cadence (duration), If it's one week, the team panics and quality fails. If sprint lasts four weeks, the team unconsciously relaxes thinking there’s plenty of time for completion. Therefore, two weeks is ideal and gives an urgent basis mindset.

Fifth, Time Framing in delivering:

There are two kinds of estimations:-

1. Actual - 2 Miles for the destination.
2. Relative - It's like a rough size of work usually comparing, this work might take double than that sprint/project. Just an estimation, not a commitment. Later on, switch over to actual estimate after relative sizes.

Sixth, Release plan: Each task gets clear and estimated in a number of hours.

Okay, but how to keep a track of your scrum progress?

Information Radiators contains Project Vision, Team norms, Team's definition of done, roadmap.

Tracking Scrum progress in a Scrum Board

Picture Credits: ZOHO

Sprint BreakDown chart - Time Vs Work

Scrum relies on 3 Cs

• Collaboration
• Communication
• Cadence

Sessions in SCRUM

Picture Credits: https://www.acmagile.com/en/what-is-scrum/

Daily Standups

Every day, there's a 15-minute standup meeting, everyone from Developer to Tester has to participate standing so that its duration is no longer than 15 minutes.

Meeting should consist of -

•  What did you do yesterday?
•  What are you going to do today?
•  Is anything blocking your progress?

If blocks are to be removed whole team steps in. Even Scrum Master.

Scrum Master is like a facilitator, keeps the team working at a sustainable pace. Opens dialogues on what can be achieved, what cannot be. Therefore, Scrum Master is the most visible spokesperson in the team. Scrum Master has to protect the team and help them improve.

• Scrum Master reports to Product Owner and Product Owner to the Stakeholder.

There's also a backlog grooming session that lasts for 30-60 minutes, checks any changes to existing sprint, new features acceptance.

Scrum Done?

If the usable product meets the acceptance criteria the scrum is done. But, the Product Owner has to approve those acceptance criteria are met. Then, all tasks are moved to "done".

• PO is a business representative, who keeps ordering the work, interacts with stakeholders, maintains the product vision, and works in the highest value work.

Then there's a Sprint Review where all the unaccepted, incomplete work is reviewed, prioritized, and moved to another sprint.

Once all the sprint is over, the team agrees to demonstrate to Stakeholder. A demo is scheduled with the stakeholder, the product owner is accountable to stakeholders. The stakeholder acknowledges the progress, gives feedback, accepts whether he wants it or not. If not, the team can pivot to what stakeholder wants.

After the Demo, There's a retrospective session.

Meeting focussed on team performance at the end of each sprint.

Three-pointers -

• What worked well?
• What did not work well?
• What can be improved?

Read More on Agile Principles here

*END*