AGILE Framework and Methodologies : Introduction to SCRUM

Aside


SPRINTFRAMEWORK

SCRUM is an excellent framework for developing complex software products. Broadly speaking, SCRUM is a collection of ideas related to project management time boxed to provide a high quality working software. Specific to IT, SCRUM is a simple framework for effective team collaboration on complex projects. SCRUM provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving the product requirements what might otherwise be an insurmountable challenge.

SCRUM Framework is an iterative incremental product development approach where interaction with the environment is allowed, accepts changes to the project scope, technology, functionality, cost, and schedule whenever required. Controls are used to measure & manage the impact of change. SCRUM accepts that the requirements are changing and unpredictable, the working product developed using SCRUM is the BEST possible software, factoring in cost, functionality, timing and quality.

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka,published a paper “The New New Product Development Game” in HBR suggesting Waterfall doesn’t work and needs a dynamic development model.

Later, Ken Schwaber and Jeff Sutherland, the co-creators of SCRUM, Ken worked with Jeff Sutherland to formulate the initial versions of the SCRUM development process and to present SCRUM as a formal process at OOPSLA’95.

The SCRUM framework consists of SCRUM Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to SCRUM’s success and usage.

SCRUM employs an iterative, incremental approach to optimize predictability and control risk.  Three pillars which uphold every implementation of empirical process control are

transparency, inspection, and adaptation.

Transparency:

Significant aspects of the process must be visible to those responsible for the outcome.

Inspection:

SCRUM users must frequently inspect SCRUM artifacts and progress toward a goal to detect undesirable variances.

Adaptation:

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

SCRUM prescribes four formal opportunities for inspection and adaptation:

– Sprint Planning Meeting

– Daily SCRUM

– Sprint Review

– Sprint Retrospective

Characteristics of SCRUM are as follows

1. Self Organizing Teams
2. Product progresses in a series of month long sprint.
3. Requirements are captured as items in a list of product backlog
4. No specific engineering practices prescribed
5. Uses generative rules to create an agile environment for delivering projects
6. One of the “agile processes”

The essence of SCRUM is
  • The team is committed to achieve its goal – high quality working software.
  • The team self organizes itself for meeting its commitment.
  • The team delivers at each iterative cycle the most valuable features to the product owner.
  • The team adapts to the changing needs suggested by feedback and retrospective from sprint review & retrospective meeting.
  • The team’s performance is transparent and can be measured in terms of progress being made.
  • The team and management honestly communicate about progress and risks.

The SCRUM way of working is based on values of commitment, team spirit, self respect, respect for others, trust and courage. SCRUM never suggest any methodology or engineering practice to teams to do their work but expect team to fulfill the commitment – high quality product.

The SCRUM FRAMEWORK  consists of the Team, SCRUM Master and Product Owner.

TEAM is collectively responsible for meeting the commitment of each sprint goal and of the project as a whole.

TEAM

are self organized, self-managing and motivated cross-functional members. The team is fully dedicated to innovate and create working product from product backlog items incrementally within the sprint.

SCRUM MASTER

is philosopher, guide to the team, helping the team to implement the scrum methodology for product development. He removes any impediments or hurdles for the team. He makes sure the process is moving. Institutionalize SCRUM process to the complete organization.

PRODUCT OWNER

is responsible for delivering the vision in a way that maximizes the ROI & minimizes the risk, formulates the plan and converts it to product backlog. He responsible to communicate the progress and changes of the working product to all the stakeholders of the Product. PO is also responsible for prioritizing the functionality of the product that needs worked upon by the team.

All work is done in Sprints; each sprint is an iteration of 2-4 consecutive weeks. Each Sprint is initiated with a Sprint planning meeting where Product Owner and Team get together to collaborate what product backlog items needs to be worked upon in next sprint.

All the backlog items that team commits is put into sprint backlog where each product backlog item is divided into multiple tasks in sprint backlog, the tasks in the sprint backlog emerge as the sprint evolves. With Sprint planning, the sprint starts and the clock starts to tick towards Sprint time-box.

The team members needs to attend the DAILY SCRUM meeting and keep the sprint backlog up-to-date. Everyone answers 3 questions in DAILY SCRUM meeting

  1. What did you do yesterday?
  2. What will you do today?
  3. Is anything in your way?

The SCRUM Master updates the Task board based on the briefing in the Daily SCRUM meeting. These are not status updates but commitments in front of peers.

At the end of the sprint, a sprint review meeting is held. the purpose of the sprint review meeting is to demo the working software to the product owner. Product owners discusses with the stakeholders and team potential rearrangement of the Product Backlog based on the feedback. Stakeholders give feedback and identify any new functionality and request additions to the Product Backlog for prioritization.

After this SCRUM Master holds Sprint retrospective meeting with the team, At this time-boxed meeting SCRUM Master encourages team to review, within the scrum process to make it more effective for the next sprint. To track remaining work Sprint Burndown chart is used, This reports remaining estimated workload over the course of the project

To Summarize, SCRUM is a most popular framework of AGILE project management methodologies. It has ROLES (Product Owner, Scrum Master, Team), CEREMONIES/EVENTS (Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum meeting) and ARTIFACTS (Product Backlog, Sprint Backlog, Burndown charts). In my future coming articles I will be explaining in detail all the ROLES, CEREMONIES/EVENTS and ARTIFACTS of SCRUM FRAMEWORK till then happy reading and drop me any feedback or comments below.

Agile Framework and Methodologies : Introduction to Agile

Aside


Process Diagram of Scrum Methodology, one of the Agile Methodologies.

Process Diagram of Scrum Methodology, one of the Agile Methodologies.

An enterprise that aspires to respond in real-time should be agile and show affinity towards rapid adaptability. Every passing day end users needs are changing very fast, as they want more than their basic needs. This leads to very dynamic markets.

In this dynamic market, Agile methodology is an alternative to traditional project management like waterfall, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints.

Agile is all about embracing and rapidly adapting to changes, work is performed in a highly collaborative manner by self-organizing teams that embrace and adapt changes to ensure that customer’s needs are truly met.

The idea behind the Agile approach is that of an organization would adapt to dynamic changing conditions by breaking a release into smaller shorter cycles of 1 to 6 weeks called sprints, instead of building a release as in waterfall that is huge in functionality and often late to market making product irrelevant to the changing market.

Agile development methodology provides opportunities to assess the direction of a project throughout. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially working product incrementally.

In waterfall methodology, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development is constantly reviewed throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in the right direction.

To understand better, every IT Professional is his career would have come across this question:

Can a Client envision his product features completely before interacting with working prototype ?
Many development teams have realized the solution for this a hard way and struggle to provide a proper fix for the product when the product is in the last stages of development, making the software irrelevant at the end of the project since the business realities would have changed rapidly. This scenario would lead to huge losses to the customer as well as the development team. This situation is very familiar to the teams who have been following the waterfall development cycle. In waterfall, teams have only one chance at the begin of the product development cycle to interact with the business to ensure that the project is moving in the right direction. This leaves the development team & the client to take huge risk and uncertainty as business requirements keeps changing rapidly.

Main difference between traditional approach like Waterfall Methodology & Agile Methodology is that
1. Team work in linear phase as in relay race.
2. Each phase is succeeded by another phase sequentially.
3. Traditional team have numerous specialized teams which rarely interact and collaborate for project ultimate goal.
4. At the end the Feedback is taken

In Agile
1. Team work is iterative & incremental as in rapid race.
2. No phase development, Multiple features of product are prioritized and worked incrementally & simultaneously by the team to complete features in working software.
3. Team is composed of mixed skills focused on completing on the committed features
4. Feedback is taken at each incremental sprint in during sprint review meetings from the business and the customer.

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which criticized sequential development. He recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialized groups that complete each phase of work.

Agile empowers teams to continuously revise their release plan to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. An agile development preserves a product’s critical market value and ensures a team’s work doesn’t wind up on a shelf, never released.

In  Agile Software Development, Each cycle is called an iteration, or sprint, and it’s almost like a miniature software project of its own, because it includes all of the tasks necessary to release the incremental new functionality. At the end of each sprint, the product should be ready for a GA release.

In addition, one of the most broadly applicable techniques introduced by the agile processes is to express product requirements in the form of user stories. Each user story has various fields including an “actor”, a “goal” or task that they need to perform, an explanation of “why” it is needed and the associated value, and a corresponding “priority”.

Most agile teams include all the people necessary to release software. Typically an agile team will also include a testers, interaction designers, technical writers, and programmers.

At a minimum each agile project has, team of programmers and the group they are developing the application for, i.e. “customers”, customers define the product; a.k.a product owners. And to facilitate between product owners & the team there is Scrum Master.  Scrum Master plays a pivotal role, he is guide, philosopher, friend to the agile team, helping the team to complete the commitments in the rapidly changing requirements.

Agile Methods are used in:

  • Large scale enterprise software projects
  • Consumer software products
  • US FDA approved software
  • High Availability Systems
  • Financial Payment Applications
  • Multi Location development
  • Non Software Projects

Overall, Agile is a management framework to develop a product usually it is software product. Agile can be implemented in projects where market is dynamic and requirements from the customers keep changing, in this scenario the final working product is of high quality and very much relevant to the current market needs. Agile development can be a very exciting and exhilarating approach.  The collaboration and visibility offers a much more rewarding richer experience for teams to develop great software products.

This is first article of 10 part series of article on “Agile Framework and Methodologies”.

In the next I will explain the why Agile should be used and different Methodologies already existing in the IT Industry.