Share
Getting started with a team in Scrum could have challenges of its own. Knowledge about Scrum as an agile framework is just a minor part of the challenge. The greater problems are getting rid of traditional methods and getting used to the agile mindset.
A set of developers who might have been delivering products in conventional software development life cycles would have trust in the system, which might make them resistant to change. It may sound tempting to start everything from day one. But as a scrum master or a scrum coach for such a team, breaking down this transformation journey is critical.
A concept that can help in this effort is Minimum Scrum. The key here is to take small steps and help the team adapt before a full-fledged launch. Unless the team starts to trust that the new ways of working are yielding results for them, there is no way we can succeed in transforming a team.
As the name suggests, Minimum Scrum refers to the bare minimum requirements for a small team to start it's journey towards scrum adoption. It can be divided into four parts:
Empowered Roles: The team must not have roles just for the sake of it. All Scrum Accountabilities (Scrum Team - Developers, Product Owner, and Scrum Master) must be empowered to make decisions. The Scrum Team is supposed to be self-managed and self-organized. The management must stand by the decisions taken by the Scrum Team. While this does not mean that the team will not need guidance, the decision-making authority must be decentralized. A fail-safe environment is a must for Scrum to thrive and succeed within a team or an organization.
Events with the Intent: People transforming to scrum often carry a myth that Scrum (or any other agile framework) is about a lot of meetings. The team must restrict itself to the five scrum ceremonies - Sprint, Sprint Planning, Daily Scrum, Review, and Retrospective. The creation of capacity plans will ensure that the time for these events is discounted from the capacity of the team, and any other meetings (technical or functional) must be preplanned, preferably during the Sprint Planning. The team should set a timebox for all these events and follow the same diligently.
If these events do not serve the purpose, they are as good as not done. The entire Scrum Team must know all their responsibilities and intend to meet their commitment to the Sprint Goal through these events.
Start Good, Finish Better: We cannot, and need not, have everything ready before we get started in a Sprint. However, to get started, the Product Owner must use the INVEST criteria to create the Product Backlog. Also, the Scrum Team must ensure compliance with the DoR (Definition of Ready) before pulling the issues into the Sprint.
The Sprint Goal must be clear, understood by everyone, and achievable in the timebox set for the Sprint. As said by the Greek philosopher Aristotle, “Well begun is half done.”
Moving on to finishing, the Scrum Team must ensure that the increment created meets the business objective. Compliance with the DoD (Definition of Done) criteria is a prerequisite for closing any issue in the Sprint. However, just meeting the DoD must not be treated as a success. Acceptance criteria qualification is the most important thing for the issue to be declared as accepted and closed as this validates the business purpose of the issue, the reason why it was created in the first place.
Handle Changes: Isn’t agile all about accepting changes? The answer is both Yes and No. Yes because flexibility is at the core of all agile frameworks, and No because we need to set boundaries for these changes. However, this does not mean we reject changes. It implies that we have a timeline to accept changes for executing any requirement. Any changes post that must be either treated as a change request or accommodated in the upcoming sprint or program increment. The team must learn that changes are acceptable if it does not hamper or affect the sprint goal.
The team meets in a Daily Scrum and discusses what is blocking the Sprint Goal. This is one of the best platforms to inspect and adapt. The team adapts to the current situation and moves on. Sprint Retrospective is another useful event that the team must conduct to retrospect their ways of working and adapt to the new requirements or give up the things that are no more working for them.
Minimum Scrum is only a starting point to help teams get a correct start in adopting Scrum. However, a truly agile mindset comes with time and through the successful demonstration of Minimum Scrum. Also, this model, just like any other agile framework, will not work if only the Scrum Team adopts it. The stakeholders, including customers and management, must imbibe these four things and make efforts to ensure that these happen with true intent.