Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Wednesday, 5 November 2014

What Are The Core Principles And Features Of Agile?

Main Features Of Agile

Many IT products development companies and software businesses experiment with Agile frameworks and processes such as Scrum and XP to improve upon their development process and avail higher investment returns. In many ways, Agile has become synonymous with software development and is rapidly emerging as the number one choice in terms of project development frameworks. Many project managers prefer Agile in lieu of other project development methodologies. The reasons are many. Certain features of Agile remain common to all Agile offshoots such as Scrum, XP, Kanban, etc.

It is worth knowing what the core tenets of Agile are:

scrum tool | scrum

An overview of Agile development method


Twelve core principles define the Agile process:

  1. The topmost priority is to satisfy the customer requirements through the delivery of early and quick product releases – deliver valuable software on a consistent basis.
  2. Working releases of product features should be delivered frequently, ranging from a week to ten days, up to a maximum of one month.
  3. Progress should be measured of the basis of working software delivered to the client. Software is more important than its documentation.
  4. Changes should be welcomed, and incorporated into the product development cycle – even late during the development phase. The team should learn from the “inspect” and “adapt” principles and conѳtantly try to improve its working.
  5. The client and end users should work together through collaboration and collaborative processes … Read more>>>

Friday, 31 October 2014

What Is A Sprint Planning Meeting Agenda?

The sprint planning meeting agenda

In a Scrum project, the Sprint planning meeting agenda is one of the most important activities undertaken by the team. The product owner plays an important part in the agenda. In Scrum, out of the many important duties carried out by a PO, a very important one is to create the product backlog based upon the vision of the stakeholders, and subsequently maintain or “groom” it with the help of team members (preferably). However, once the backlog is created and all required product backlog items are properly defined in it, it becomes necessary to “prepare” for the next step in the Agile product development cycle – plan and develop effective sprints so shippable user stories are delivered at the end of sprint cycles. Offering consistent development over successive sprint iterations is an inherent feature of Agile Scrum. In a sprint planning agenda, the objective of a sprint meeting is to prepare productive sprints so the team can develop meaningful stories.

So, what does a sprint planning meeting actually consist of? In practice, the meeting is conducted in two parts – the first part is dominated by the product owner while in the second part the development team actually prepares tasks from user stories taken up for development in the sprint backlog.

scrum tool | sprint planning meeting

First part of sprint planning

The product owner is the most “conversant” person as far as user stories are concerned since he or she actually “creates” the product backlog. The stories need to be explained to the team members. During the first part of the Scrum sprint planning meeting, the PO selects some of the most important product backlog items from the top of the backlog, and creates a “sprint backlog” by transferring the selected stories into it. So, the sprint backlog is a subset of the main backlog, and contains a “chunk” of stories which carry high business values. The PO explains how the development of a particular story should be carried out by the development team. The acceptance criteria is explained and the team is briefed regarding what it should do to ensure their “development” is shippable i.e. the stories are bug free and satisfy the benchmarks or acceptance criteria linked with each story. The PO also answers any doubts or queries put up by the team.

The first part is attended by the entire team – the product owner, scrum master, and the development team members. It is not necessary for the stakeholders and project owners to attend the sprint planning meeting, but if they desire to do so, they can attend the meeting as “passive” invitees, and not disturb the proceedings with their suggestions or even try to get “involved” in the meeting.

Second part of sprint planning

User stories form the base of all development activity in Scrum. The entire product is developed by creating shippable stories, which are later integrated to “form” the complete product. During the second part of the Scrum planning meeting, the team starts discussing how it will ... Read more>>>

Wednesday, 29 October 2014

How to Understand The Agile Manifesto

The Agile manifesto

The popularity of Agile frameworks, especially XP and Scrum, is increasing by the day, and more and more organizations are deciding in favor of using these frameworks to execute their projects. Agile proposes many advantages – frequent and reliable product increments, delivering product features having high business values, and above all – delivery of shippable product features even while the development process is underway. However, a major issue with Agile, and all Agile based frameworks is that the framework has to be properly understood and later implemented in the project. Moreover, the implementation should be carried out keeping Agile principles in mind. More than often, businesses fail to benefit from Agile simply because the management has not understood the basic principles behind the framework, or has failed to implement those principles in a proper manner.

Importance of the Agile manifesto

Since it was developed in 2001, thousands of individuals including project managers, software professionals, and C level executives have endorsed the Agile manifesto. Hundreds of books and references have been written to discuss what the guide has to say, and how it should be interpreted. The manifesto has drastically changed the way in which organizations and individuals develop software projects. The manifesto packs a lot of punch for its 68 words which have been written by 17 software professionals over a two days meet at a ski resort.

The principles of Agile are stated in the official guide written by Ken Schwaber and Jeff Sutherland. The guide functions as a bible for all Agile groups and Agile professionals. People refer to the guide when in doubt, or when they wish to clarify a particular point during Agile framework implementation. For individuals interested in Agile, it is very important to understand the guide and interpret what it has to say.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to 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.

We
To start with, the manifesto states “We” i.e. it emphasis that Agile is not a solo endeavour. It involves group activity and people have to collaborate while working, at every level, and at every instant. Development teams, project teams, and organization have to work jointly as a composite unit, and rely upon each other for completing work.

are uncovering
Here, the guide suggests that Agile does not offer one-size-fits-all type of solutions. Agile cannot be standardized and implemented in a project. People involved with Agile processes have to put in efforts, and strive to seek answers through discussions and collaborations. Answers have to be discovered through experimentation, and the “adapt” and “inspect” principles which are so dear to Agile. It is important to explore new ideas and eliminate those activities which are counterproductive or not effective.

better ways of developing software
Nobody is perfect. Also, no framework or methodology can be perfect. Instead of concentrating upon perfection, the Agile team ought to concentrate more upon improving the current work process and finding better ways of doing things. Small improvements, gradual but consistent, should be incorporated in the process to make it more efficient and result oriented.

by doing it
The bottom line – build the software and deliver it. The best way of finding out whether something works or not is to build it and try it out. Failures should be seen as learning lessons, and the team should learn from them. Better methods of working originate from experimentation and the learning process. Rather than spending undue time thinking over whether something will work properly or not, it is better to do it, and learn from the results availed through the implementation.   

Agile | Scrum
Source: http://agilemanifesto.org/

and helping others do it.
Agile is all about sharing. People have to share their ideas and experiences with each other. It is not required to make a mistake and learn from it – one can learn from the mistakes made by others. Knowledge should be shared and opinions sought for. Senior team members should try to foster a healthy working environment, and act as mentors for those new to Agile.

Through this work we have come to value:
The manifesto was envisioned and drafted by 17 seasoned professionals closely involved with various project development methodologies and processes. They represent the core market requirements. Through their experiences and knowledge, the manifesto was designed to target what clients really desire in a project, and how the team should function to satisfy those requirements in the best possible manner by delivering time bound projects having high business values. Agile principles should be taken seriously and valued by all concerned.

Individuals and interactions over processes and tools
Bob Martin has correctly described Agile as "a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work." The Agile team should primarily focus upon working together while developing the project, and ensure that ... read more>>>