Acquired Wisdom from Agile Methodologies

For more than ten years, I’ve been using one of the many methodologies of Agile, called the Sprint model, to develop software. Over time, it has become easier for me to manage after managing many rounds of these Sprints. However, the journey wasn’t always smooth.

I still remember the day when we initially considered using this approach. Back then, terms like “sprint,” “backlog,” “daily scrum,” and “scrum of scrum” seemed peculiar and unfamiliar, as if they hailed from another realm. Picture attempting to shift from a customary method of working, akin to following a detailed plan (as in a Waterfall model) with four primary steps (generating the concept, designing, coding, and testing), each demanding a significant chunk of time. However, in this novel Sprint approach, the pace is considerably swifter.

It requires a considerable amount of self-discipline and effort to facilitate effective collaboration among various teams in a scrum, all working harmoniously toward a specific component of a larger objective. At times, challenges arise in ensuring timely preparedness for development tasks, including obtaining requirements promptly, acquiring the necessary designs/mock-ups and models for web pages, as well as ensuring that the QA team possesses the essential resources. Furthermore, promptly addressing issues is essential?—?this includes fixing problems swiftly and efficiently, encompassing a diverse array of potential concerns.

Here are the key lessons I’ve learned:

• Sticking to the plan and maintaining discipline is of utmost importance
• Each member of the scrum team should dedicate at least 5 minutes before beginning the day to update the accurate status of their assigned tasks
• The individual overseeing the process (known as the Scrum master) should assist in resolving any issues that arise among the teams
• The daily meeting, where we discuss our current work, is crucial as it aids in planning the day and identifying significant challenges
• Planning ahead for sprints is essential to provide the development team with sufficient time to prepare for the next cycle
• Swiftly addressing problems and being prepared for unforeseen issues is vital
• The Scrum master should collaborate closely with the team responsible for determining the software’s purpose (the product team) to gain a comprehensive understanding of early requirements. This collaboration helps prevent conflicts between teams
• Implementing automation, such as using tools like Slack bot , can reduce the time needed for daily standup meetings, streamlining the process
• Use Jira Automation: Link
• In an ideal scenario, the product and design phases should be at least one sprint ahead in terms of requirements, mock-ups, and so on. However, this rarely occurs in the real world?:)
• Conducting a mid-sprint review to recalibrate for tasks that overflowed
• Structured retrospective meetings yielding actionable tasks aimed at enhancing processes
• Instead of designing for the future, focus on the current use case and then expand it for future scenarios
• Each task should have a corresponding Jira ticket for tracking purposes

As a Scrum Master, your responsibilities include:

• Vigilantly track individual and team velocity
• Routinely assess Burn-down/up charts, Velocity Charts, and Release/Epic Burn-down reports
• Strictly adhere to the escalation matrix
• Ensure active participation from all departments in the retrospective meeting
• Oversee a comprehensive range of delay metrics, extending beyond Engineering
• Acknowledge that delays may arise in various stages, yet Engineering often faces undue pressure and blame
• Assume leadership to steer the ship; avoid being at the receiving end
• Implement a well-structured release calendar
• Manage the team’s leave calendar

Key dates to monitor:

• Individual ticket’s Dev to QA release date
• QA sign-off date for each ticket
• User Acceptance Testing (UAT) and demo date
• Release notes sign-off date
• Production release date

As I explained above, good planning is really important in this Sprint approach. Among all the planning we do, like estimating how long a sprint will take, deciding what to do first, planning when to test, and getting ready to release the software, one of the most important parts is planning when to test (Dev to QA release planning).

In this kind of planning, the team in charge of creating the software decides when each part of the software will be tested. It’s important to keep the promises we make about when things will be ready and to spread out the testing times. If we put too many things to test all at once, the team testing might get overwhelmed and the chance of something going wrong becomes bigger.

By spreading out the testing times and making sure things are tested at regular times, the first round of testing for each part of the software can be done quickly in the next week, especially if we release new versions every two weeks. But this isn’t always easy. Sometimes unexpected things happen, like really important problems that need fixing, things we didn’t plan for, or even technical issues. This is when someone experienced in the Sprint approach (the Scrum master) can help a lot.

A skilled Scrum master knows how to handle these unexpected challenges. They might give a task to a different team member who has time, or they might ask for help from the whole team, or they might talk to the people in charge to find a way to solve the problem. Their role becomes very important in guiding the team through these tough times.

So, when we talk about planning in the Sprint approach, it’s not just about setting dates. It’s also about being flexible, taking action when things go wrong, and making sure everyone works well together to keep the promises we’ve made, even when things get complicated.

More: https://ajhawrites.blogspot.com/2023/08/acquired-wisdom-from-agile-methodologies.html