Agile vs Waterfall?

Agile and Waterfall are two different methods used in managing a project. Both the methods have their own pros and cons and choosing one model is based on many project-centric factors.

The Waterfall model is a progressive design process which in the software development industry goes through stages such as Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance and steadily moves downwards similar to a waterfall flowing down. After one stage is completed it moves to another and every stage has its own goals. This model is based on the standard workflow process which is followed in manufacturing and construction industries.

The benefit of using this model is that a project is divided into separate compartments which in turn decrease the dependency on individuals of a team. Any team member who leaves the project during the transition stages would not affect the execution of the project. This method also requires concrete documentation.

The cons of this method is that it is inflexible. In this method it is not possible to go back to a previous stage to alter the design in anyway. Hence it is very important to collect the requirements at the initial stage. This method is based on the logic that once we spend considerable amount of time in gathering the comprehensive requirements at the start of the project helps in saving time and effort later on.

• Agile Method
  On the other hand Agile method is incremental approach. The team works on small modules and then responds to user’s altered requirements rather than following a pre-determined plan. The design is simple and changes can be made as work progresses.

When compared to Waterfall method, here the testing and responding to user change requirements can happen during the same time in the course of the project. Here interactions among stakeholders is prioritized as compared to tools and processes.

This method became popular in 1990s after the many found the drawbacks of traditional Waterfall methods.

Conclusion

As you can see both the methods have their own advantages. Though Agile was developed to combat the disadvantages found in Waterfall method, Waterfall method still is considered in environments which is stable

Agile is considered to be a lightweight approach. The team focuses on smaller areas of work and hence overhead becomes less. The cost of the project also becomes less. Agile is more suitable when the user requirements are not clear and where the business environment is not stable. Also successful implementation of Agile requires skilled developers and also stakeholders who know what they exactly want.

To Know More Please Visit www.scrumstudy.com

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Less overheads
• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

To Know More Please Visit www.scrumstudy.com

Release Planning Sessions in SCRUM

Release Planning Sessions are conducted to develop a Release Plan. The plan defines when various sets of usable functionality or products will be delivered to the customer. In Scrum, the major objective of a Release Planning Meeting is to enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing so that they can align with the expectations of the Product Owner and relevant stakeholders (primarily the project sponsor).

Many organizations have a strategy regarding release of products. Some organizations prefer continuous deployment, where there is a release after creation of specified usable functionality. Other organizations prefer phased deployment, where releases are made at predefined intervals. Depending on the organization’s strategy, Release Planning Sessions in projects may be driven by functionality, in which the objective is to deliver a release once a predetermined set of functionality has been developed; or the planning may be driven by date, in which the release happens on a predefined date.

Since Scrum framework promotes information based, iterative decision making over the detailed upfront planning practiced in traditional waterfall style project management, Release Planning Sessions need not produce a detailed Release Plan for the entire project. The Release Plan can be updated continually as relevant information is available.

To know more please visit www.scrumstudy.com

All About Prioritized Program Backlog

The Prioritized Program Backlog plays a very similar role at the program level as the Prioritized Product Backlog does on project level. It identifies the requirements for the program and their priorities.

The items in the Prioritized Portfolio Backlog provide inputs to the various Prioritized Program Backlogs and, through Prioritized Program Backlogs, to Prioritized Product Backlogs of individual projects. As described for Prioritized Program Backlogs only minimal, if any, refinement of User Stories is done at this level, because the refinement is done in the projects and their specific Prioritized Product Backlogs.

There are a few differences, though:

The creation of the respective deliverables and their acceptance is done in the projects of the program. The done or acceptance criteria for each Product Backlog Item / User story may be defined on the program level.  Projects have to adhere to them but can add their own criteria.

The length of a Sprint is project specific and, generally, varies from project to project in a program. In addition, the velocity of different teams is, normally, not the same. Therefore, it is not necessary to have very granular User Stories at the program level. The refinement of User Stories at the program level goes only far enough to ensure that the respective story is clearly understood and tangible acceptance criteria for the program can be defined.

To know more, Please visit www.scrumstudy.com

What is Servant Leadership?

The preferred leadership style for Scrum projects is Servant Leadership. This term was first described by Robert K. Greenleaf in an essay entitled The Servant as Leader. Below is an excerpt where he explains the concept:






















The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature….

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived? (Greenleaf 1970, 6)

Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

1.  Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
2.  Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
3.  Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
4.  Awareness—Awareness and particularly self-awareness is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.
5.  Persuasion—Servant leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, servant leaders practice persuasion.
6.  Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good servant leaders.
7.  Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
8.  Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
9.  Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).
10.  Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have the above traits.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com

What is Servant Leadership?

The preferred leadership style for Scrum projects is Servant Leadership. This term was first described by Robert K. Greenleaf in an essay entitled The Servant as Leader. Below is an excerpt where he explains the concept:

The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature….

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived? (Greenleaf 1970, 6)

Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

1.  Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
2.  Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
3.  Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
4.  Awareness—Awareness and particularly self-awareness is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.
5.  Persuasion—Servant leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, servant leaders practice persuasion.
6.  Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good servant leaders.
7.  Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
8.  Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
9.  Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).
10.  Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have the above traits.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com
Follow us on twitter - @SCRUMstudy_

Determining Size of a Scrum Team

It is important for the Scrum Team to possess all the essential skills required to carry out the work of the project. It is also necessary to have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done.

The optimum size for a Scrum Team is six to ten members—large enough to ensure adequate skill sets, but small enough to collaborate easily. A key benefit of a six to ten member team is that communication and management are typically simple and require minimal effort.

However, there may also be drawbacks. One major drawback is that smaller teams are more significantly impacted by the loss of a team member than larger teams, even for a short period of time. To address this problem, it may be possible for team members to have expert knowledge and skills outside their own specific role. However, this may be difficult and depends on the type of project, industry, and size of the organization. It is also recommended to have back-up persons to replace any person who may have to leave the Scrum Team.

In situations where the Scrum Team size exceeds ten people, multiple Scrum Teams can be formed to work on the project. Large or complex projects are often implemented as part of a program or portfolio. The Scrum framework can also be applied to manage even programs and portfolios. The logical approach of the guidelines and principles in this framework can be used to manage projects of any size, spanning geographies and organizations. Large projects may have multiple Scrum Teams working in parallel making it necessary to synchronize and facilitate the flow of information and enhance communication.

To know more, please visit www.scrumstudy.com