10 things QAs (should) know about Agile Scrum

Codrin Păduraru has been a CGMer for more than 5 years, working with us as a Software Tester. So, after all these years of working on several projects, many presentations made and after winning the first place with his team at the Innovation Day, he took initiative and he organized a special workshop called „10 things QAs (should) know about Agile Scrum”, with participants from different areas, like POs, QAs or FE developers. 

The agenda was quite big, and the topics covered areas like Agile SCRUM, Agile mindset, Accountabilities, Responsibilities, subtleties of Scrum Accountabilities, Empiricism, Heuristics, Effectiveness, Value and Sustainability and many more. Plus, lots of exercises and free talks based on each participant's experience.  

"People were engaged, discussing, asking and answering questions, relaxed, curious. I liked how fast and easily they've organized themselves and worked together”, Codrin added. 

And because sharing is what we do every single day, let`s learn together more about Agile from Codrin`s workshop. Especially that, like participants said, Agile is not only in IT. 

What is Agile 

Agile is an approach (philosophy) to project management that focuses on the iterative development of your final deliverable.  

Agile is not a methodology. Methodology refers to a set of agreements (a system of methods) that a team accepts to follow. 

Agile is ultimately a mindset that is guided by the principles and values of the Agile Manifesto. They provide guidelines for creating and responding to change and dealing with uncertainty. 

Agile emphasizes customer focus, adaptability, and continuous improvement to deliver greater value faster. It encourages open cross-functional communication, regular feedback exchange, and constant knowledge sharing to achieve these results.    

Why Agile 

• Reduced risk of failing to deliver your projects and accumulating high project costs  
• Higher chances of meeting customers' expectations 
• Metrics for efficiency and data-driven decision-making 
• Improved work performance and transparency 
• Better team collaboration and continuous improvement 

The 4 Agile Manifesto values 

1. Individuals and interactions over processes and tools. 
2. Working software over comprehensive documentation. 
3. Customer collaboration over contract negotiation. 
4. Responding to change over following a plan. 

The 12 Agile Manifesto principles 

1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” 
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” 
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” 
4. “Business people and developers must work together daily throughout the project.” 
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” 
6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” 
7. “Working software is the primary measure of progress.” 
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” 
9. “Continuous attention to technical excellence and good design enhances agility.” 
10. “Simplicity — the art of maximizing the amount of work not done — is essential.” 
11. “The best architectures, requirements, and designs emerge from self-organizing teams.” 
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” 

The 3 SCRUM pillars 

Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation. 

Transparency 

•The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk. 

•Transparency enables inspection. Inspection without transparency is misleading and wasteful. 

Inspection 

•The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events. 

•Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change. 

Adaptation 

•If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation. 

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection. 

The 5 SCRUM Values 

Successful use of Scrum depends on people becoming more proficient in living five values: 

1. Commitment 
2. Focus  
3. Openness 
4. Respect  
5. Courage 

The SCRUM Artifacts 

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. 

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured: 

• For the Product Backlog it is the Product Goal. 
• For the Sprint Backlog it is the Sprint Goal. 
• For the Increment it is the Definition of Done. 

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders. 

The SCRUM Events 

The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. 

Optimally, all events are held at the same time and place to reduce complexity. 

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints. 

During the Sprint: 

•No changes are made that would endanger the Sprint Goal; 

•Quality does not decrease; 

•The Product Backlog is refined as needed; 

•Scope may be clarified and renegotiated with the Product Owner as more is learned. 

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. 

Sprint Planning addresses the following topics: 

•Topic One: Why is this Sprint valuable? 

•Topic Two: What can be Done this Sprint? 

•Topic Three: How will the chosen work get done? 

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog. 

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. 

Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. 

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. 

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. 

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. 

The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation. 

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. 

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. 

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. 

The SCRUM team 

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. 

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value for each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. 

The Agile mindset is a set of beliefs, viewpoints, and attitudes that allow teams to become more flexible and adaptable to changes. Agile thinking promotes collaboration, knowledge sharing, and feedback exchange, allowing organizations to focus on creating value and improving continuously.  

Therefore, an Agile mindset is this internal predisposition that shifts your behaviour, so collaboration, iterative execution, customer value, and experimentation become natural first choices. 

"Next, I would approach this workshop online, for the remote colleagues that could not attend physically. As for the topics, we can make this one more granular, going more into details. Other topics can emerge from feedback/wishes”, declared Codrin in conclusion, after more than 4 hours of intensive workshop.   

Stay tuned for more workshops and initiatives from our amazing CGMers and remember to keep it Agile.