Category: Scrum



Scrum is an Agile Methodology, it is modelled and designed for Hyper-productive teams and high quality work, these teams operate at the rate of 5-10 times the velocity and very high quality than that of waterfall teams. Scrum is modelled so that it can scaled across the globe to any size.

In 2001, Sutherland, Schwaber, and fifteen colleagues got together in Snowbird, Colorado, and drafted the Agile Manifesto, which became a clarion call to software developers around the globe to pursue this radically different type of management.

Since then, Sutherland, Schwaber, and their colleagues have gone on to generate thousands of high-performance teams in hundreds of companies all around the world under the labels of Scrum and Agile.

SCRUM COACH Mike Cohn reports in his classic book, Succeeding with Agile :

“During the first year of making the switch, released 94 percent more features, delivered 38 percent more features per developer, and delivered over 500 percent more value to their customers compared to the previous year. . . . Fifteen months after adopting Scrum, surveyed its employees and found that 86 percent were having a ‘good time’ or the ‘best time’ working at the company. Prior to adopting Scrum, only 40 percent said the same thing. Further, 92 percent of employees said they would recommend an agile approach to others.”


High performance and productive is directly depends on the self-organizing capability of teams, Understanding this self-organizing capability and continuously improving on it is a challenge.

The huge forte of complex adaptive systems to be adapting new system and environments helps us to follow certain rules namely

  • Shock Therapy.
  • Choice uncertainty principle.
  • Punctuated Equilibrium.

There are teams who follow waterfall but use terms and jargon of “Agile”, thinking that is enough to be an agile team. Then there are teams who follow few SCRUM principles and not every person in the team and management follow completely SCRUM, these teams are known as “SCRUMBUTT”.

It is believed that majority of the teams are not SCRUM teams only 20% -25% are pure SCRUM teams capable of working above than the performance of Waterfall team.


The best way to check if the scrum team is truly following the practices of SCRUM and Agile principles is to ask the scrum team members to undertake NOKIA Test.
Following are the questions asked during NOKIA test:
– Do you know who the product owner is?
– Is there a product backlog prioritized by business value that has estimates created by the team?
– Does the team generate burndown charts and know their velocity?
– You cannot have project managers (or anyone else) disrupting the work of the team.
– Only 10% of teams worldwide meet this criteria.
If the average score of the team is more than 6, then the scrum is properly followed otherwise it is SCRUMBUTT team.


Another way of checking if the organization is implement very good scrum and have hyper productive scrum teams is by measuring if their revenue or return of investment of the organization per annum.
There are very few exceptional top performing scrum teams who had successfully meet the specified commitment and since the outcome was overwhelming. The management and sales & marketing team were so overwhelmed that were unable to share the pace of the output and had find excuses and drop the idea of marketing to the client. Few of the examples given by Jeff Sutherland are below:

  • The most productive team ever recorded at Borland produced a failed product.
  • The most productive distributed team (SirsiDynix) had quality problems, management problems, and internal company conflicts that caused the product to be killed.
  • The second most productive team in the world (Motorola – David Anderson data) was overwhelmed with bureaucracy, completely demotivated, their product was killed, and the team died a painful death


There are very few exceptional top performing scrum teams who had successfully meet the specified commitment and since the outcome was overwhelming. The management and sales & marketing team were so overwhelmed that were unable to share the pace of the output and had find excuses and drop the idea of marketing to the client. Few of the examples given by Jeff Sutherland are below:

  • The most productive team ever recorded at Borland produced a failed product.
  • The most productive distributed team (SirsiDynix) had quality problems, management problems, and internal company conflicts that caused the product to be killed.
  • The second most productive team in the world (Motorola – David Anderson data) was overwhelmed with bureaucracy, completely demotivated, their product was killed, and the team died a painful death

The best way to understand the scrum is by studying failed scrum projects which performing exceptionally well but were killed due to the other factors of the organization. It is similar to the analogy of Thomas Alva Edison who failed 10000 times to final invent a modern light bulb. So we need to study the failed projects and understand the impediments and try to overcome them in our scrum project.

The Toyota Way

One of the best way and well established process of hyperproductive teams is the “Toyota Way”. The development and manufacture process of No. 1 Car Maker of the World. The following are the guidelines implemented by Toyota

  • There are many things one doesn’t understand, and therefore we ask them why don’t you just go ahead and take action; try to do something? Agile Principle #3 #11
  • You realize how little you know and you face your own failures and redo it again and at the second trial you realize another mistake…so you can redo it once again. Agile Principle #11#12
  • So by constant improvement…one can rise to the higher level of practice and knowledge. Agile Principle #3
Toyota Fights Back!!

In 2007, Toyota had very bad week, they had to face lot of criticism and feedback from the owners of Toyota cars. Since Toyota follows very strict quality and agile policy they recalled all the defect cars from Japan. Later Toyota strived and worked hard to rectify the defects and improved the cars to greater extent and got their market leader share. Earlier that week their market share less than their competitors almost down to fourth or fifth place but regained it back very soon to 1st place in the market.

Invention of SCRUM

A well-known technologist “Alan Kay” who invented Personal workstation, Mouse, Ethernet, Windows Interface, Laser Printer and Small Talk has followed a strategy of selecting the data points for research and innovation.

Alan Kay’s Innovation Strategy

Every time Alan Kay followed extreme data points of the IT & Technology Field for inventing something in that domain. He never used to look for data points which were incremental to already existing products in the IT field, he never looked for Cross Discipline products for innovation. By following this kind of strategy Alan has been successful in inventing very successful and high impact products.

Similarly Jeff and Ken followed the extreme data points for identifying the projects for inventing scrum, They choose IBM Surgical team, Takeuchi & Nonaka research paper on high productive quality teams and Borland Quattro Project as research data or extreme data for inventing scrum.

Anyone who is planning to use scrum and be an industry leader has to high motivated person first, this motivation helps the team perform better. So if you are planning on scrum you need to be motivated and ready to strive for greater goals like being Industry leader and revenue of the project is skyrocketing. Anyone can aspire to be great and that aspiration can be your starting point for scrum implementation.

Are you practicing SCRUM?

Once you have planned for scrum and start using scrum, how to verify you are doing it rightly. For that there is Nokia test. You and your team need to undergo Nokia test and make sure you have the scoring of more than 6. IF your team score is less than 6 then you are not doing SCRUM.

Two Sibiling of Agile : Scrum and XP

The core and forte of a successful SCRUM has been utilizing the best practices of engineering and good communication. IF you see the first scrum at Easel Corporation implemented by Jeff Sutherland, it incorporated all the activities of extreme programming’s engineering practices. All the Most high performance teams use Scrum and XP together. It is hard to get a Scrum with extreme velocity without XP engineering practices. You cannot scale XP without Scrum.

Example 1: Anatomy of a failed project – SirsiDynix – ScrumButt

Example 2: Xebia ProRail project – Pretty Good Scrum

Learn from venture capital investments

As agile became popular both in Japan, US and slowly spread around the globe. VC start preferring companies which invest their process & practices in agile. Some VC have start using SCRUM and agile methodologies in their own management and their portfolio started to have SCRUM and XP practiced companies. All the VC felt that having clients in their portfolio are agile companies they felt it has double safe. So VC have started the following:

  • – Invest only in Agile projects
    • ! hyperproductive company out of 10 is good enough to meet investment goals
    • Invest in Scrum training could get 2 hyperproductive
  • – Invest only in market leading, industry standard processes – this means Scrum and XP
  • – Ensure teams implement basic Scrum practices
    • Everyone must pass Nokia test
    • Management held accountable at Board level for impediments

First Non Software Company Strategy : OpenView Venture Partners Strategy

OpenView Venture Partners strategy is invest in Software company which practised SCRUM: They also incorporated SCRUM in their company. They were the first non-software company to:

  • Investment partners practice Scrum
  • Invest only in Agile projects
    • Use only market leading, Industry standard process – this means Scrum and XP
    • Ensure teams implement best Scrum practices
  • Drive Scrum implementation at Board level. Ensure management is totally involved and understands Lean Product Development
  • Many portfolio companies run senior management team, sales, marketing, client services, and support with Scrum.

What Investors know about Companies?

All the investors start searching for the secret ingredient for their portfolio recipe and start asking
What is the secret recipe for building hyperproductive teams? They started summarizing what Jeff had advised to Open View, i.e.

  • – What is the secret recipe for building hyperproductive teams?
  • – First step is implementing basic Scrum practices and passing Nokia test.
  • – Second, management needs to get totally involved, understand team velocity, and remove impediments.
  • – Third, basic XP engineering practices need to be implemented, namely: o Test first development (may be pair programming, TDD);Continuous integration
  • – Then they are ready for the fun stuff

To be a Hyper Productive Team

According to Scrum, Hyperproductivity is defined as at least Toyota level of performance, it used to require at least two years for a non-agile company to reach 200 to 240% improvement. Now the scrum company requires only 300% improvement in 3 two weeks sprints. The only challenge is to keep the consistency of the teams to that optimum level very quickly and then remain in the hyper productive state. This is the main truth of self-organized teams to remain in hyper productive state

(Courtesy InfoQ)

Courtesy (Jeff Sutherland Agile Seminar)

How can an agile coach achieve Hyperproductivity in typical company?

Following are the successful examples of Shock Therapy are
1. MySpace in Beverly Hills.
2. JayWay in Sweden.
3. Pivotal Labs in San Francisco.


MySpace has been very good example of successful agile projects in most of the studies done in Agile.
MySpace has several hundred developers
– About 1/3 waterfall
– About 1/3 Scrum Butt with Project Managers
– About 1/3 pure Scrum

Scott Downey (Owner at Rapid Scrum LLC), when he was coaching MySpace the Agile practices and scrum training, he reportedly taken teams to high production state in a few weeks

It has been recorded that Average time to 240% of the velocity of a waterfall team is 2.9 days per team member where the team includes the Scrum Master and the Product Owner.

Establishing a Scrum Team

When a new team is sent for scrum training at MySpace, Scott Downey has a very strict and rigour training. Also Scott Downey sets all the rules of effectively running the scrum training and the projects. The rules are: My rules remain in effect until the team has met three criteria:

  • They are Hyper-Productive(>240% higher targeted value contribution)
  • They have completed three successful Sprints consecutively
  • They have identified a good business reason to change the rule

– The rules are roughly these:

  • Everyone on the team will attend scrum training session. I conduct an extremely condensed Scrum at MySpace course in about four hours, and the entire team comes together to a session. Until everyone has been trained, we won’t begin our first Sprint.
  • Sprints will be one week long.

The biggest and crucial point of defining a successful product from SCRUM Development team is the commitment to definition of DONE:

MySpace uses Jeff Definition of “DONE”

Definition of “Done” is this:

o 1. Feature Complete

o 2. Code Complete

o 3. No known defects

o 4. Approved by the Product Owner

o 5. Production Ready

Initially Scrum Master guides and helps the new team to do Daily SCRUM Meeting, He guides each and every move of the SCRUM team till the new team has become familiar with the best practices of SCRUM team.

Initially Scrum Master guides and monitors the Estimation and discussions in Sprint Planning meeting, as the team matures they start handling the activities of sprint planning into unique meetings. The Product Owner participates as visitor and advisor to the meeting, Scrum master guides development team in creating user stories. Stories are made to comply the INVEST principles. In the Sprint Backlog meeting Commitment of the team of Product Backlog is read aloud and taken consent of team again after explaining clearly the team what “Commit” does and does not mean so there is no ambiguity about the product requirements and definition of DONE. Once the team commits to the sprint work, the meeting ends.

The work should be completed in right order and with regression testing with no defects. A lot of emphasis is placed on priority order than multi-tasking, this helps in completing the commitments early rather than having incomplete items on the list. Every member of the scrum team follows the standard layouts for all the artifacts of SCRUM namely Sprint Planning Boards, User Stories, Story Cards, Burndown Charts and Velocity tracking.

Once the Master Scrum master feels that he has team matured enough, he moves on to another new team and new Scrum master is assigned to monitor the team’s scrum development process. The main aim is to make the team a hyperproductive team.

facilitating self-organization

As the team becomes matured and completely self-organized, the team member starts correcting each other and evokes lot of positive energy in the team. Soon the team becomes very agile, active and focused.

Cosmic Stopping Problem

The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.

Jeff Sutherland in one of his paper “AGILE DEVELOPMENT:LESSONS LEARNED FROM THE FIRST SCRUM” suggest that, The most interesting effect of Scrum on Easel’s development environment was an observed “punctuated equilibrium” effect. This occurs in biological evolution when a species is stable for long periods of time and then undergoes a sudden jump in capability During the long period of apparent stability, many internal changes in the organism are reconfigured that cannot be observed externally. When all pieces are in place to allow a significant jump in functionality, external change occurs suddenly. A fully integrated component design environment leads to unexpected, rapid evolution of a software system with emergent, adaptive properties resembling the process of punctuated equilibrium observed in biological species. Sudden leaps in functionality resulted in earlier than expected delivery of software in the first Scrum.

A punctuated equilibrium – the equilibrium being the “Safety Zone” of working in a stable system for a while (e.g. during a Scrum Sprint when the Sprint Backlog does not shift within the sprint) punctuated by events that allow the chaos/shifting world outside to affect the system, and then return to the “Safety Zone” to have an opportunity for behavior that fits the new reality to emerge. This has been observed in nature as well as contributing to effective evolution.

This punctuated equilibrium is accompanied by Choice Uncertainty Principle also known as “Cosmic Problem”. It is found everywhere, at every level of the world. A very good Scrum master is able to handle this at every step of development, a good scrum does the following to avoid Cosmic Problem:

  • o Don’t accept backlog that is not ready
  • o Minimize work in progress
  • o Stop the line when bad things happen and fix it so it can never happen again
  • o If it is not “Done” put it back on the product backlog

Another major factor why Scrum is better than waterfall, is that collocation factor affects velocity which affects the cost of the project. In a study done at PatientKeeper a project from Scrum development moved to Waterfall team, the company had expenses instead of savings of 30%, so $2M of Scrum development at PatientKeeper company costs $6M when outsourced to waterfall teams. So never outsourced to waterfall teams, only outsource to Scrum teams.

The Road to Hyper-Productivity

A success path to Hyperproductivity is based on the Complex Adaptive System theory.

The essential architectural design concept that encourages refactoring at granularity level with regression testing and rigours system testing to build a product with zero defects. Team develops the software components in the right hierarchical order with optimization of speed of displaying the new features of the product. Working on only the well-defined stories and removing the requirements that are not ready which otherwise led to cosmic Stopping Problem, minimizing work in progress, avoiding obstacles through self-organization and finally applying the Shock therapy that decreases the Sprints count.

Finally SCRUM recommends, those who can do ‘Pretty Good Scrum then should do Great SCRUM’
There are 3 types of companies namely,

  • – Doesn’t want to see or hear impediments. Suppress Scrum master. Prevents the process implementation. These companies always suffer and lose out.
  • – Talk about impediments, but doesn’t fix impediments, internal struggle goes on. These companies suffer for a long time to be better.
  • – Look for Impediments and fix it immediately. Avoid internal Conflicts. These companies are successful companies.

The Success of SCRUM driven work and its positive impact on the employees has forced almost all the non-software firms also to move to SCRUM, as clearly stated in Forbes

“The success of software development at firms like [CRM], along similar customer-driven iterative methods in auto manufacture at firms like Toyota, has led to the spread of this different way of managing to related fields.

  • • The Quality Software Engineering group at IBM [IBM] is responsible for software development processes and practices across the company. As part of the effort to promulgate Scrum in developing software, an iterative process of working was adopted for doing change management.
  • • At the Chicago software firm Total Attorneys, iterative work patterns were so successful that they spread to the staff of call centers: small cross-functional teams work in cycles of three weeks.
  • • At the Danish software firm, Systematic, iterative methods have been spreading from software development to other parts of the firm.
  • • At the Swedish software firm Trifork, iterative methods have spread from software development to conference management.
  • • And OpenView Venture Partners, a Boston-based venture capital firm, has expanded client-driven iterations into consulting and finance.”

The Power of SCRUM is now enthusing other firms to join the main stream of new methodology of management of work.


Agile Framework and Methodologies : Introduction to Agile

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.


Agile Framework and Methodologies: Why Agile?


In this article, I will explain why follow Agile Framework instead of Waterfall. Later I will explain the different methodologies of Agile Framework.
Enterprises following agile development process helps their team to cut risks and to mitigate uncertainty. This has led to cut development time and delivering of relevant high quality product to the current market.

Agile Methodology is becoming popular and catching up with the IT industry because of the following reasons:
1. It helps teams embrace rapid changes & increase adaptability with customers easily.
2. It helps teams to mitigate risks at early stages of product life-cycle.
3. Customers see the visible progress as they are able feel of working software.
4. Customers give feedback at every stage of the product life cycle, since they are part of the product development.
5. Early adaptation of feedback leads to  a system that meets the needs of various stakeholders.
6. Complexity of the features are properly prioritized and easily managed by the team.
7. Team has chance to learn from mistakes during each iteration of development.

Using the Agile methodologies helps team to avoid pitfalls of traditional approach such as
1. Stabilization of Product and Releases are too long.
2. Unable to carry out Frequent Code changes
3. Unable to do rework development.
4. Requirements are not clear as client is not involved in every iteration of development.
5. The time difference between requirements taken and product released time was very long, This elapsed time made product irrelevant as market has changed rapidly.

For all the above reasons IT teams are embracing Agile Methodologies and develop new rapidly changing products.

The Different methodologies of Agile Framework are as follows:
1. DSDM : Dynamic System Development Methodology is an agile framework for software projects, it was used to fine tune the traditional approaches. The most recent version of DSDM is called DSDM Atern. The name Atern is a shortening of Arctic Tern – a collaborative bird[citation needed] that can travel vast distances and epitomizes many facets of the method which are natural ways of working e.g. prioritization and collaboration. DSDM addresses the most common failures of information systems projects, including exceeding budgets, missing deadlines, and lack of user involvement and top-management commitment
2. Scrum: Scrum is most popular agile framework in the world, Scrum uses iterative and incremental development model. Scrum concentrates particularly on how to manage tasks within a team-based development environment. Scrum provides the simple framework of basic tenets to solve problems and deliver good results – more valuable software faster.
3. XP : Extreme Programming is a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels. Extreme Programming is a software-development discipline that organizes people to produce higher-quality software more productively. XP addresses the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product.
4. TDD: Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the least amount of code to pass that test, and finally refractors the new code to acceptable standards.
5. Lean: Lean is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. Working from the perspective of the customer who consumes a product or service, “value” is defined as any action or process that a customer would be willing to pay for. Lean is centered on preserving value with less work.
6. Kanban: Kanban is a system to control the logistical chain from a production point of view, and is not an inventory control system. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and keep up a high level of production. Kanban is one method through which JIT is achieved. Kanban became an effective tool in support of running a production system as a whole, and it proved to be an excellent way for promoting improvement.

To close Agile Framework helps teams to benefit like
1. Faster Time to Market.
2. Reduce Uncertainty & Risk.
3. Increase ROI by focusing on Customer Value.
And all the teams who want to carry out Agile can choose one of the above methodologies depending upon their team flexibility and adaptability.
In my next blog article I will explain about Agile Values and Principles.


Agile Framework and Methodologies: Principles and Values of Agile.


Agile empowers teams continuously plan their release to optimize its value throughout development life-cycle, so teams are competitive as possible in the marketplace. Development using an agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

A small group of people got together in 2001 to discuss their thoughts about the failure of traditional approach of software development life-cycle and is there a better way to do this?  They came up with the agile manifesto, which describes 4 important values that are still relevant today, The use of the word agile in this context derives from the agile manifesto.  It says, “we value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.” Ever since then, the use of methods that support these values has become increasingly popular.
The twelve Agile principles derived from four key values in agile manifesto.

These twelve Agile principles are as follows:

1.  To meet the Customer Product expectations through iterative high quality, customer friendly software
2.  To accept changes as the come from customer to increase customer’s competitive advantage in the market.
3.  Deliver incremental working software to the customer in agreed time-boxes or period.
4.  Team is mix of cross functional professionals i.e. both technical and business domain experts.
5.  Team works in a highly motivated helpful environment, team enjoys all support & trust during project life-cycle.
6.  Most effective communication among team members to convey information between them regularly i.e. daily face to face meeting.
7.  Working Product is the only measure of progress.
8.  Agile believes in constant iterative development, all the team members & sponsors need to keep up this constant development speed.
9.  Continuous focus on Quality & Design Enhancements improves effectiveness & usability of the product being developed.
10. Simplifying the art of identifying the incomplete work is the important factor for continuing the product development.
11. Only the most motivated & highly disciplined self-organizing teams can  innovate best designs and specifications for the product.
12. The team effectively adapts itself to ever-changing needs of the project & product requirements.

The real goal of any business is the Quality working software and the way to get there is all these things that Agile principles asks us to do, through a continual process of learning.

In the next article of Agile Framework and Methodologies series I will be discussing about finer details about SCRUM Methodologies.


AGILE Framework and Methodologies : Introduction to SCRUM


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.


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


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


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.


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.


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.


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.