Quality considerations for Agile Projects

In Agile, Quality and Testing teams’ roles and responsibilities often overlap. That is because ideally, matrices are not required in Agile Projects. So, Quality teams are often merged into testing teams for the sake of convenience, though it depends on a lot of factors. Also, as customers are closely involved in providing feedback every sprint, so even they can be considered as a part of Quality Team.
Now, in Agile projects, ideally, “Quality should be baked in”. What it means is that since coding, integration and testing happens in parallel, so there is no concept of quality being checked at a later phase, which in turn means that it has to be maintained from beginning till end, by the combined efforts of all the stakeholders put together. In other words, quality has to be fed into a product from the beginning, rather than trying to test it in later. Hence, even a Project Manager conducts a functionality testing if required. Even a BA conducts smoke testing if needed. And even the clients chip in with their random testing during demo and walkthrough. All of these efforts ensure that “Quality” is not a phase as such in Agile, it is an everyday affair.
Another thing to realize is that in traditional method, quality ideally should be allocated as much time as coding based on the relative importance, but more often than not, this is not the case. What happens is that coding takes longer than allocated, and that is compromised in the quality check/testing phase. But in Agile, each increment of coding is tested as soon as it is done, and immediately iteration after rectifying bugs. Developers can never actually get ahead of the testers, because according to Definition of Done, a code is not done till it is tested. This fundamental difference between both the methodologies is what makes Agile so much more Quality Conscious.
Regarding Testing, it is an altogether different approach in Agile Methodologies. Instead of writing test cases from a requirement document build by a BA, even before any coding has started, the testers will have to write test cases for user stories as per the priority in an iteration just hours before actual coding takes place. It requires a collaborative approach between a business representative, a domain expert and/or programmer. Functional testing, exploratory testing, smoke testing, pair programming etc. everything is done to ensure the quality of the iteration remains on the higher side. When tests demonstrating minimum functionality are complete, the team can consider the story finished.

To know more click on:  http://www.scrumstudy.com/blog/

How can scrum be made scalable?

Scalability of a process, network, or unit is its ability to adjust or adapt to any expansion. For example a central server is said to be scalable if it performs similarly when attending on either five clients or fifty clients. In Scrum, it means that the scaling mechanisms applicable for a single Scrum Team can also be used for larger projects with multiple teams.
Is Scrum scalable? Initially, Agile authors believed that Agile methodologies including Scrum was predominantly for small scale projects. This opinion was based on the fact that Scrum had not yet been applied on large scale projects. The Guide to the Scrum Body of Knowledge (SBOK™ Guide) gives comprehensive directions through which Agile methodologies including Scrum, can be scaled and applied on larger projects
When to scale? In small Scrum projects there is adequate scope for the self-organizing Scrum Team members to collaborate among themselves. The problem starts when team size expands and when there is coordination required between multiple teams. Scalability in Scrum can occur at three levels – Projects, Programs and Portfolios
How to scale? Scalability in Scrum is achieved primarily through the Scrum of Scrum (SoS) Meetings. Scrum recommends small teams; however if teams are larger it is recommended that they are divided into smaller teams who can meet occasionally to discuss their status.
What makes Scrum scalable? It is recommended that Scrum Teams should ideally have six to ten members. This does not mean that Scrum can be used only in small projects – it can be scaled to be used effectively in larger projects. If the size of the Scrum Team exceeds ten members, then multiple teams can be formed to work on the project simultaneously.
Scrum of Scrums facilitates synchronization between multiple Scrum Teams in larger projects. Team representatives update each other about team’s progress, challenges faced and coordination activities. Frequency of Scrum of Scrums (SoS) Meetings is determined by inter-team dependency, size of the project, recommendations by Scrum Guidance Body (SGB) and complexity level.
Scaling in Distributed Teams:
Scrum recommends collocated teams and face-to-face communication between team members. This is often not possible, as companies have distributed teams working in parallel across geographies and time zones. For the purpose of scaling, in larger projects employing distributed teams, the Scrum of Scrum Meeting can be held using video conferencing, chats, social media etc.
The ‘Convene Scrum of Scrums’ Process is facilitated by the Chief Scrum Master (or another Scrum Master). Representatives of various teams, usually the Scrum Master of individual teams or any other designated team member. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. In larger projects, as it is difficult to have all participants together at one time, all important matters should be discussed
The Scrum of Scrums meeting is usually held at predetermined intervals or when required, to collaborate and track progress, address impediments and dependencies across projects. An agenda for the meeting can be announced in advance by the Chief Scrum Master, allowing individual teams to consider the items for discussion. Impediments faced by individual teams, likely to affect other teams should also be indicated. Issues, risks and changes likely to affect multiple teams should also be communicated during this meeting.
Achieving Scalability:
Each team representative is expected to update other teams, usually in the form of four questions. (i) What has my team been working on since the last meeting?, (ii) What will my team do until the next meeting?, (iii) What were other teams counting on our team to finish that remains undone?, (iv) What is our team planning on doing that might affect other teams?
Result of Scrum of Scrums Meetings include Better Team Coordination facilitated coordination of work across multiple Scrum Teams, especially when there are tasks involving inter-team dependencies (as future tasks of one team may depend on the timely delivery of a task by another team). Discrepancies between work and deliverables are quickly exposed. The Scrum of Scrums is a forum where team members can transparently discuss issues and resolve them.
Scrum of Scrum of Scrums: In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums Meeting can be scaled up another level to a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.

To know more click on : http://www.scrumstudy.com/blog/how-can-scrum-be-made-scalable-3/