Small Scale Scrum principles address the preferred approach towards communication, the processes introduced to ensure the highest quality of delivery, and the benefits behind implementing Small Scale Scrum for the business.
Small Scale Scrum principles are non-negotiable.
[Download the Introduction to Small Scale Scrum guide]
Value-based communication includes inner (within the development team) and outer (with the customer) communication. It is focused on delivering a value. Understanding the solution, its purpose, and its desired functionality depends upon effective communication. Initiating and maintaining communication between parties requires openness and dedication to look for the best solution to a given functionality request or fix. It may also lead to further discussions around progress made in software delivered, which can, in turn, uncover omissions in the requirements.
With finite time, the focus should be put on valuable and urgent communication as opposed to communication deviating from importance and usefulness. This aligns with the Eisenhower Matrix of making urgent vs. important decisions to help prioritize communication flows.
Quality-first development focuses on taking a quality approach to software development during each sprint. This means ensuring that features are delivered according to acceptance criteria, the solution is bug-free (or at least free from any evident bugs), any inconsistencies in the software are removed, the solution is tested, and any edge-case bugs and omitted features are reported, logged, and considered by the customer.
Delivery ownership is about the development team taking initiative in driving software delivery on a sprint-to-sprint basis. Enabling the team to consult the customer directly positively impacts the team’s overall performance and the customer’s satisfaction. Elimination of any micromanagement-related barriers is critical to allow the team to take ownership in delivering software solutions.
Iterative signoff focuses on reducing technical debt and identifying gaps in requirements through an iterative signoff approach. As the solution evolves and matures, business requirements change. With iterative development, functionality delivered within a sprint should be signed off upon the sprint’s completion. Similarly, requirements for the upcoming sprint should be signed off on before it begins.
A related version of this article was originally published on Medium and is republished with permission.
Comments are closed.