Agile methodology -Scrum

1. Executive Summary

Agile methodology refers to a disciplined project management process encouraging frequent inspection and adaptation. Before the Agile methodology methods of software development tended to be slow,bureaucratic and inconsistent creating the need for a more adaptive method of software development. Agile methodology encourages teamwork, self-organization,and accountability. Most agile development teams comprise 5-9 employees and as ingle customer representative that work in a single open office to promote
teamwork and cooperation.

2.1.Core Principles:
· Working software delivered frequently to customers
· Software is a measure of progress

· Simplicity

· Self-organizing Teams

· Adaptability

· Agile Modeling

· Agile Unified Process (AUP)

· Agile Data Method

· DSDM

· Essential Unified Process (EssUP)

· Extreme Programming (XP)

· Feature Driven Development (FDD)

· Getting Real

· Open Unified Process (OpenUP)

· Scrum

· Lean Software Development

One of the most popular agile methods is Scrum. It's one of the main working frameworks used by hundreds of companies among which Microsoft, Yahoo!, and Google.
Scrum as iterative development method has been developed in the 80’s and 90’s. According to (Takeuchi and Nonaka, 1986), projects using small, cross-functional teams historically
produce the best results. These teams are like the Scrum formation in Rugby. Scrum
has been practiced mostly by Manifesto authors Ken Schwaber, Jeff Sutterland
and Mike Beedle. Scrum as a management process for managing product development
is not used just in software development, but can be adapted for use for
different types of projects. According to Ken Schwaber (Schwaber, 2004), Scrum
is used for complex work in which it is impossible to predict everything that
will occur. Accordingly, Scrum simply offers a framework and set of practices that keep everything visible.

This allows Scrum’s keep the project moving toward the desired goals. Scrum helps in making things transparent by encouraging communication, embracing change and improving productivity. In order to work as Scrum suggests, the
entire team must possess solid knowledge in analysis design, implementation, testing and documentation.

The primary goal of Scrum is to organize teams and deliver software that provides the highest business value. It concentrates on prioritizing work based on business value, amending the beneficiary of what is delivered, and enhancing revenue.Nowadays, many cutting edge and leading Silicon Valley companies are practicing Scrum method in applications
development to reduce the time to the market and providing a stable platform for the web that should be able to take in new functionalities with as little changes as possible.

Scrum as a process is incremental. Each increment is called sprint, where each sprint lasts for four weeks. Prior to the sprint, there is a sprint planning meeting where the user determines what features should be developed and followed in the next sprint. During the sprint, the team meets
daily at the same time at a short meeting called a scrum or the daily stand-up meeting.

The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the "What" that will be built. It is open and
editable by anyone. It contains rough estimates, usually in days. This estimate
helps the Product Owner to gauge the timeline and, to a limited extent,
priority (e.g. if "add spell-check" feature is estimated at 3 days vs.
3 months, that may affect the Product Owner's desire).

The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned; rather tasks are signed-up for by the team members as they like.

The burn down chart is a publicly displayed chart showing the number of tasks remaining for the current sprint or the number of items on the sprint backlog. It should not be confused with an earned value chart. A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule.

Like all other forms of agile software processes, Scrum has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.

Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with
commitment.

Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders' update – You have to have Advance Warning Mechanism, i.e. visibility to potential slippage / deviation ahead of time.

• You Have No Hierarchical Role; You Are an Expert

• You are Part of the Team

• The Team’s Goals are your Goals; you committed to

• Them

• Do whatever you can for the Team to meet its Goals

• Forget Role Thinking!

• There Is No Individual Failure – The Team Fails!

• There Is No Individual Success – The Team Succeeds!

• Done is done; as a team you completed these

• Activities

• You let the team down if you’re late to meetings

· Is QA part of Development Team?

· Can we fit QA in the same iteration as Development

· Who does QA?

· Does QA cost more in agile as product seems to change from Sprint to Sprint

· How can we scale QA

· Do we need “Test Plane”?

· Who define test cases?

· When do we know testing is done

· Do we need to track the bugs?

· Prioritize them within the team. In this case:

· Customer and Product Owner

· Development team

· Testing team

· This becomes your testing flow and strategy for attacking

· the product

· Use risk based techniques to identify tasks, phasing and focus

To make things easier we make several assumptions – clarification of development project specifics. So we will describe them as assumptions here:
1. Development Scrum consists of 2 week sprints
2. The software is a web based with certain data in database. The role of
tester will include testing software in “QA environment”, while developers are
still doing unit tests in their environment which is not as close to production one.
3. It is decided that software deployment in “QA environment” should follow the manual installation process the same as it will take place in production environment. It optionally needs smart decision if to redeploy data into database. The process may take up to 30 minutes and is never done this way by developers in their environment
4. The process of creating installation package (build process) may also take up to 30 minutes, so will be executed once per night (nightly build)
Day 1. Sprint Planning
During the first day of a spring – sprint planning meeting – tester participates in order to help to define acceptance criteria (by asking what if questions to product owner) and estimating testing effort for stories. It may appear that there are stories requiring a little development effort but a lot of testing effort. Story selection may be changed to disallow too much stories of
such type into one sprint. Alternatively part of testing activities may be
postponed, creating a separate story (adding what I would call “quality debt”)
and adding to backlog.
Day 2. Test Case Drafting
A tester works: one day behind” the team. The second day of a sprint is dedicated by tester to draft initial set of test cases for each features included in the sprint.
Day 3-8. Normal days
each day starting day 3 of sprint in the morning tester installs latest nightly
build (manually using installation procedure/instructions supplied by development team) to QA environment, do fast smoke tests if they fail and
emergency fixes are applied by the team.
Features developed yesterday shall be tested today by tester. As required
tester communicates with each developer to transition the knowledge of the feature functionality. Tester must also update (complete) Test Cases in the process of testing as more test ideas may come out during Exploratory Testing. If a feature testing requires too much effort or tester discovers too much ideas and can’t accomplish testing within the day he create new story ticket for further feature investigation. If the ticket is not closed by the end of a sprint it appears to be “Quality Debt” and must be announced to product owner for prioritization. Because developers do unit testing most of the features should pass acceptance criteria. However if for any reason they do not pass them in QA environment, QA may return ticket to the team. If acceptance criteria are met but there are more bugs around, tester reports them separately, sending the initial story to End-To-End testing. Tester also has to do wider investigation (based on project quality goals) and report any usability suggestions, performance, security or other potential treats. Such bugs must be assigned to Product Owner if they don’t directly break the acceptance criteria of a story. Bugs that (developer) team disagrees with or appears to require too much effort also get assigned to Product Owner. They have to be addressed during sprint retrospective meeting. So it appears that during sprint retrospective no feature could be demonstrated if it has an open bug against it assigned to anyone but product owner.

Day 9 – The QA day
because tester works one day behind, the day 8 of the sprint shall be the last day of a new feature development. That is the reason why day 9 can be dedicated by team to bug fixing, re-factoring and analysis of new features which might be included into next sprint i.e. next sprint preparation.
Day 10 - retrospective meeting
In order to demonstrate a feature in retrospective meeting it should be
implemented; tested and all bugs either fixed or assigned to Product Owner for
clarification (otherwise feature is postponed to next sprint). Tester should
demonstrate that features meet acceptance criteria and demonstrate the issues
assigned to product owner if any. Product Owner should decide and prioritize
those features/defects. The team participates in the meeting to qualify their
performance and probably counter tester’s negative opinion. Tester also describes “Quality Debt” changes – what was not tested due to lack of time. Product owner may prioritize the postponed tests or even allow skipping them.
More QA stuff after sprint
Test Cases created during sprint shall be peer-reviewed by another tester at
any time later. For example by End-To-End tester if there are any. Ideally review should be done during or by end of the day 10 so that tester has the feedback by next planning meeting, but it may be impossible. In any case tester is not forced to respond to review feedback (fix test cases and run additional test if identified) until the end of sprint (so that tester commitment during sprint planning is not compromised). If more tests are identified during review they must be executed later and any defects discovered should be assigned to product owner (added to backlog).
Testing outside sprints
Still there are types of tests that are not directly related to functionality
implemented by sprints. For example non-functional tests: to validate that
given architecture satisfies high availability requirements. Actually the
tester may not have enough skills to do performance tests and a separate team
or person may be assigned to do performance testing based on agreed schedule.
More over it is highly welcome to develop system-level automated regression
tests (based on, but not necessarily repeating manual test cases) along with
developer created unit tests. Those tests will aim for different type of
regression bugs. This activity may also take place with a significant delay to
feature implementation. The tester should make a smart decision to nominate the build that was
especially successful (without critical bugs) to be installed to the special environment such as for performance test or test automation environment.

Adaptive, adjustable – in this context, that project goals or

change.
Burn-down Chart, a diagram that monitors how much
work remains to implement a segment of the software being

Daily Scrum, brief, daily meetings (about 15 min) between

Empirical, based on experience.

Agile development, a methodology for software

Sprint Retrospective, meeting (about 3 hours) held after

Predictive, foresighted – in this context, project goals and

Product Backlog, current “to-do list” that contains the

project’s goals and priorities. Managed by the Product Owner.

Product Owner, the person responsible for the product’s

Product Backlog and that the project is working with the right

Release Backlog, the same as a Product Backlog, but restricted

Scrum Master, “the team leader” for the Scrum Team.

Scrum Team, ”the work force” – in this case, software

Sprint, the iteration comprised (normally) of thirty days during

Sprint Backlog, a to-do list for a Sprint. Consists of the

Sprint Review, an informal meeting (about 4 hours) at

Timebox, a period during which something is to be carried