AGILE TUTORIAL

1.     Introduction:

The Agile-Process model is applicable to development projects, which involve Development of new products or major enhancements to existing software products. Agile software development is a style of software development characterized by an emphasis on people, communication, working software, and responding to change.

Agile methodologies provide a collection of foundational values, guiding principles and development practices that to address the challenges of prescriptive, weighty methodologies to produce software in a lighter, faster, more people-centric manner.  Agile methodologies work best with motivated, reliable people who desire to work together to fulfill their stakeholder's business goals.  Slackers, complainers, and lazy developers need not apply!

All Agile methodologies engage in an iterative workflow and incremental delivery of working software in short time-boxed iterations. Iteration is essentially a small release of software. Generally during each iteration many activities will occur in parallel, such as requirements, coding, and testing. Iterations are typically a fixed length (although this length varies between the methodologies) and thus are referred to as time-boxed. The time allocated to each iteration sometimes referred to as a cycle time.

1.1                        Methodologies in Agile:

a.     Scrum

b.     Extreme Programming

c.      Crystal family of methodologies (Crystal Clear)

d.     Feature Driven Development

e.     The Rational Unified Process

f.       Dynamic Systems Development Method

g.     Adaptive Software Development

Scrum:

Scrum is an iterative, incremental framework for project management and agile software development. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.

Extreme Programming:

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (time-boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

Crystal family of methodologies (Crystal Clear):

Crystal Clear can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. The Crystal family of methodologies focuses on efficiency and habitability as components of project safety. Crystal Clear focuses on people, not processes or artifacts.

Feature Driven Development:

Feature Driven Development (FDD) is an iterative and incremental software development process. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.

The Rational Unified Process:

The Rational Unified Process (RUP) is an iterative software development process framework. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

Dynamic Systems Development Method:

Dynamic Systems Development Method (DSDM) is a software development methodology originally based upon the Rapid Application Development methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement.

Adaptive Software Development:

Adaptive Software Development is a software development process that grew out of rapid application development. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, time-boxed, risk driven, and change tolerant.

2.     Scrum Model:

Scrum is a process skeleton which contains sets of practices and predefined roles. The main roles in Scrum are:

a)     The “Scrum Master”, who maintains the processes (typically in lieu of a project manager)

b)    The “Product Owner”, who represents the stakeholders and the business

c)     The “Team”, a cross-functional group who do the actual analysis, design, implementation, testing, etc.

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog”, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

It aims to cure some of the common failure of the typical development process such as:-

- Chaos due to changing requirement.

- Unrealistic estimates of time, cost and quality of the product.

- Developers are forced to lie about how project is progressing.

It follows: develop-> wrap-> Review -> Adjust. It is cyclic in nature.

2.1            Process

Scrum process includes three phases: Pre-game, development and post-game.

2.1.1Pre-game phase

The Pre-game phase includes two sub-phases:

a.     Planning

b.     Architecture (High level design)

Planning includes the definition of the system being developed. A Product Backlog list is created containing all the requirements that are currently known. The requirements can originate from the customer, sales and marketing division, customer support or software developers. The requirements are prioritized and the effort needed for their implementation is estimated. The product backlog list is constantly updated with new and more detailed items, as well as with more accurate estimations and new priority orders. Planning also includes the definition of the project team, tools and other resources, risk assessment and controlling issues, training needs and verification management approval. At every iteration, the updated product backlog is reviewed by the scrum team (s) so as to gain their commitment for the next iteration.

In the architecture phase, the high level design of the system including the architecture is planned based on the current items in the product backlog. In case of an enhancement to an existing system, the changes needed for implementing the backlog items are identified along with the problems they may cause. A design review meeting is held to go over the proposals for the implementation and decisions are made on the basis of this review. In addition, preliminary plans for the contents of releases are prepared.

2.1.2    Mid-game phase

The development phase (also called as game or mid-game phase) is the agile part of the Scrum approach. This phase is treated as a “black box” where the unpredictable is expected. The different environmental and technical variables (such as time frame, quality, requirements, resources, implementation technologies and tools, and even development methods) identified in Scrum, which may change during the Sprints of the development phase. Rather than taking these matters into consideration only at the beginning of the software development project, Scrum aims at controlling them constantly in order to be able to flexibly adapt to the changes.

In the development phase the system is developed in Sprints. Sprints are iterative cycles where the functionality is developed or enhanced to produce new increments. Each sprint includes the traditional phases of software development: requirements, analysis, design, evolution and delivery phases. The architecture and the design of the system evolve during the Sprint development. One Sprint is planned to last from one week to one month. There may be, for example, three to eight sprints in one systems development process before the system is ready for distribution. Also there may be more than one team building the increment

2.1.3    Post-game phase

The post-game phase contains the closure of the release. This phase is entered when an agreement has been made that the environmental variables such as the requirements are completed. In this case, no more items and issues can be found nor can any new ones be invented. The system is now ready for the release and the preparation for this is done during the post-game phase, including the tasks such as integration, system testing and documentation

2.2            Roles and responsibilities:

There are six identifiable roles in Scrum that have different tasks and purposes during the process and its practices: Scrum master, Product owner, Scrum team, customer, user and management.

2.2.1    Scrum Master

Scrum Master is a new management role introduced by Scrum. Scrum Master is responsible for ensuring that the project is carried through according to the practices, values and rules of Scrum and that it progresses as planned. Scrum Master interacts with the project team as well as with the customer and the management during the project. He is also responsible for ensuring that any impediments are removed and changed in the process to keep the team working as productively as possible.

2.2.2    Product Owner

Product Owner is officially responsible for the project, managing, controlling and making visible the Product Backlog list. He is selected by the Scrum Master, the customer and the management. He makes the final decisions of the tasks related to product backlog, participates in estimating the development effort for backlog items and turns the issues in the backlog into features to be developed.

2.2.3    Scrum Team

Scrum team is the project team that has the authority to decide on the necessary actions and to organize itself in order to achieve the goals of each sprint. The scrum team is involved, for example, in effort estimation, creating the sprint backlog, reviewing the product backlog list and suggesting impediments that need to be removed from the project.

2.2.4    Customer

Customer participates in the tasks related to product backlog items for the system being developed or enhanced.

2.2.5    Management

Management is in charge of final decision making, along with the charters, standards and conventions to be followed in the project. Management also participates in the setting of goals and requirements. For example, the management is involved in selecting the Product Owner, gauging the progress and reducing the backlog with Scrum Master.

2.3            Practices

Scrum does not require or provide any specific software development methods/practices to be used. Instead, it requires certain management practices and tools in the various phases of Scrum to avoid the chaos caused by unpredictability and complexity.

2.3.1    Product Backlog

Product backlog defines everything that is needed in the final product based on current knowledge. Thus, product backlog defines the work to be done in the project. It comprises a prioritized and constantly updated list of business and technical requirements for the system being built or enhanced. Backlog items can include, for example, features, functions, bug fixes, defects, requested enhancements and technology upgrades. Also issues requiring solutions before other backlog items can be done are included in the list. Multiple actors can participate in generating product backlog items, such as customer, project team, marketing and sales, management and customer support.

This practice includes the tasks for creating the product backlog list, and controlling it consistently during the process by adding, removing, specifying, updating, and prioritizing product backlog items. The Product Owner is responsible for maintaining the Product Backlog.

2.3.2    Effort estimation

Effort estimation is an iterative process, in which the backlog item estimates are focused on a more accurate level when more information is available on a certain product backlog item. The product owner together with the scrum team(s) is responsible for performing the effort estimation.

Teams can measure their overall progress against this product increment utilizing a focus on story-based estimation points. In a meeting during which the boss/project manager is absent, teams estimate in abstracted figures to quantify the relative effort associated with a particular story (a story is often composed of multiple tasks). Some teams use numeric sizing (i.e. a scale of 1 to 10) to estimate the "size" of a story, while others use t-shirt sizes (XS, S, M, L, XL, XXL, XXXL). Some use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) to capture how difficulty tends to increase exponentially. Other teams have used dog breeds for estimation purposes, in which, say, a teacup poodle or Chihuahua would represent the smallest stories and a Great Dane or Bull Mastiff would represent the largest. What's important for effort estimation is that the team shares an understanding of the scale it is using, so that everyone feels comfortable with the values of the scale.

Although the project manager (or Product Owner, in Scrum) needs these estimates to effectively prioritize backlog items and, consequently, forecast the delivery of the product to be developed based on velocity, only the team can make these estimates and the presence of the project manager/Product Owner could pressure (intentionally or otherwise) a team to minimize its effort estimates. Even when team members estimate amongst themselves, it is recommended that everyone reveal their estimate at the same time to avoid influencing others. This process resembles a game of poker in that individuals "show their hands"-or reveal their estimates-simultaneously.

2.3.3    Sprint

Sprint is the procedure of adapting to the changing environmental variables such as (requirements, time, resources, knowledge, technology etc.). The Scrum Team organizes itself to produce a new executable product increment in a Sprint that lasts approximately thirty calendar days. The working tools of the team are Sprint Planning Meetings, Sprint Backlog and Daily Scrum meetings.

2.3.4    Sprint Planning Meeting

A Sprint Planning Meeting is a two-phase meeting organized by the Scrum Master. The customers, users, management, Product Owner and Scrum Team participate in the first phase of the meeting to decide upon the goals and the functionality of the next Sprint. The second phase of the meeting is held by the Scrum Master and the Scrum Team focusing on how the product increment is implemented during the Sprint.

2.3.5    Sprint Backlog

Sprint Backlog is the starting point for each Sprint. It is a list of Product Backlog items selected to be implemented in the next Sprint. The items are selected by the Scrum Team together with the Scrum Master and the Product Owner in the Sprint Planning meeting, on the basis of the prioritized items and goals set for the Sprint. Unlike the Product Backlog, the Sprint Backlog is stable until the Sprint is completed. When all the items in the Sprint Backlog are completed, a new iteration of the system is delivered.

2.3.6    Burn Down Charts

Scrum Sprint Burn Down chart shows implementation progress during a single sprint. It provides answers on the following questions: When sprint could be completed based on previous progress? What is the most possible scrum team Velocity in future sprints?

2.3.7    Daily Scrum Meeting

Daily Scrum meetings are organized to keep track of the progress of the Scrum Team continuously and they also serve as planning meetings: what has been done since the last meeting and what is to be done before the next one. Also problems and other variable matters are discussed and controlled in this short meeting held daily. Any deficiencies or impediments in the systems development process or engineering practices are looked for, identified and removed to improve the process. The Scrum Master conducts the Scrum meetings. Besides the scrum team also the management, for example, can participate in the meeting.

2.3.8    Sprint Review Meeting

On the last day of the Sprint, the Scrum Team and the Scrum Master present the results (i.e. working product increment) of the Sprint to the management, customers, user and the Product Owner in an informal meeting. The participants assess the product increment and make the decision about the following activities. The review meeting may bring out new Backlog items and even change the direction of the system being built.

2.3.9    Sprint Retrospective Meeting

The purpose of the Retrospective is to build continuous improvement into the regular Sprint cycles. Again, there are three key questions to be discussed by the team in the Sprint Retrospective after each and every Sprint:

a)     What went well?

b)    What didn't?

c)     What will the team do differently in the next Sprint?

Doing these Retrospectives so regularly throughout a project means that the learning’s actually helped to improve the team's Velocity throughout the project (and beyond). If it's kept simple, the things the team wants to do differently in the next Sprint should be actionable and should actually make a difference to the efficiency and wellbeing of the team and the project. There's no question this is a meeting you can't afford to give up. There's just too much value in it.

2.3.10                       Stack rank

Stack rank is the traditional method Product Owners use to rank/prioritize their product backlog items.

When you are adding items to the product backlog, simply associate a value for each item.

There is discussion about what values to use for ranking items, but an effective method is to use a 1 to 3 scale. The scale is as follows:

a)     System/process must support this user story

b)    System/process should support this user story

c)     System/process could support this user story.

Now, prior to each Sprint planning meeting, review/update your backlog and item stack ranks. This will allow the Scrum team to focus on the most important user stories. In turn, this will allow the team to deliver maximum value on the project through all Sprints.

3.     Why Scrum

§  Advantages of Scrum

§  Completely developed and tested features in short iterations

§  Simplicity of the process

§  Clearly defined rules

§  Increasing productivity

§  Self-organizing

§  Each team member carries a lot of responsibility

§  Improved communication

§  Combination with Extreme Programming

§  Drawbacks of Scrum

§  “Undisciplined hacking” (no written documentation)

§  Violation of responsibility

§  Current mainly carried by the inventors

4.     Tools for Scrum project management

Like other agile development methodologies, Scrum can be implemented through a wide range of tools. Many companies use universal software tools, such as Microsoft Excel to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary software packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any software tools, and maintain their artifacts in hard-copy forms such as paper, whiteboards, and sticky notes.

Below are some proposed tools for Scrum project management

1. Agilebuddy
2. Agile bench
3. Version one
4. Scrum works
5. Agilo
6. Acunote
7. Scrum desk
8. Scrum Pad

5.     Glossary

• Burndown Charts - Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.
• Daily Scrum Meeting  - Story Time, Planning, Review, Retrospective, Daily Scrum
• Impediments - Anything that prevents a team member from performing work as efficiently as possible is an impediment.
• PE – Project Engineer.
• PL – Project Lead.
• PM – Project manager.
• Product Backlog -The requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.
• Product Backlog Item - A unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.
• Product Backlog Item Effort - Alternative units might include story points, function points, or "t-shirt sizes" (1 for small, 2 for medium, etc.)
• Product Burndown Chart - A "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each sprint.
• Product Owner - A single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
• QC – Quality control.
• QL – Quality lead.
• Release - The transition of an increment of potentially shippable product from the development team into routine use by customers.
• Release Burndown Chart - A "big picture" view of a release's progress. It shows how much work was left to do at the beginning of each sprint comprising a single release.
• Scrum Master - A facilitator for the team and product owner. Rather than manage the team, the Scrum Master works to assist both the team and product owner
• Sprint - An iteration of work during which an increment of product functionality is implemented.
• Sprint Backlog - Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
• Sprint Burndown Chart - A chart that depicts the total task hours remaining per day
• Sprint Goals - Results of a negotiation between the product owner and the development team
• Sprint Planning Meeting - A negotiation between the team and the product owner about what the team will do during the next sprint.
• Sprint Retrospective Meeting - The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting.
• Sprint Task - A unit of work.
• Story - a backlog item usually using the template form: as  a [user] I want [function] so that [business value], cf Product Backlog Item
• Story Point - A unit of measurement applied to the size of  a story, cf. Fibonacci Sequence
• Team - Mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc.
• Team Member – A person working on sprint tasks toward the sprint goal.
• TL – Team lead.
• Velocity - Velocity is how much product backlog effort a team can handle in one sprint.
• CH DESIGN  - Need clarification
• CH FNSP
• CH TSTPLN
• CH_DESIGN
• CH_REQSP
• CH_TSTPLN
• PR DESIGN
• PR FNSP
• PR IMPCUT
• PR REQSP
• PR TEST
• PR TSTDV
• PR_DESIGN
• PR_TSTDV
• RTL
• TP COMPDS
• TP DTLDS
• TP FNSP
• TP TSTAUD
• TP TSTPLN
• TP TSTRPT
• TP UTLOG
• TP UTPLN
• TP_HLDS
• TP_REQSP
• TP_TSTPLN
• TP_UTPLN