Be Agile. How to transfer from the Waterfall.

Agile has several advantages over Waterfall. It is more suitable for software development, however not all companies are ready to move to another method. Waterfall has served us well for years and is still considered to be a good methodology, popular in many companies. Agile is a relatively new, but stands out with its method of controlling the development process and in the usage of formation requirements.

If you have decided to try Agile, I will now guide you through smooth transition from Waterfall to Agile losslessly.

Step 1. Choosing a right project

There are several important criteria to analyse while qualifying a project:

• Project’s size
• Risks connected to a project
• Stakeholders involvement

Size

A project should last for at least 4 weeks. This amount of time is optimal to gather feedback data and understand the methodology itself. Optimal project length is 12 weeks.

Risks

A project must be should be important to the company, but not critical. There should be no time and client pressure. During a first pilot project it is necessary to concentrate on the implementation of the methodology rather than fighting fires.

Stakeholder involvement

It is important to involve as many company employees into a project as possible: project managers, designers, developers, testers, analysts. A project has go through all development stages: concept planning, design, analysis, development. It is important to have a clear vision of every methodology aspect and receive feedback from all the participants throughout the whole process.

Step 2. Team recruitment

First project experience is another important aspect. We have to approach this issue responsibly, gathering all necessary skills in one enthusiastic team. It is important to collaborate with agile backers, otherwise we would spend too much time on arguing. A team of true enthusiasts would lead to successful integration. Individuals and interactions are the key to agile approach: self-organization and motivation are important, so are interactions.

Step 3. Roles formation

The next step is to divide roles in our team. The key ones would be: 

• Product Owner
• Scrum Master or Agile PM
• Development team
• Business Analyst or Customer (Not really part of the team but the important part of the process).

These roles are divided into two groups: technical specialists and customer communication. The customer service side represented by a product owner and a business analyst are responsible for requirements setting and form them into user stories. A product owner has to provide "just enough" information to a development team, and the working process can be started.

Step 4. Planning and estimation

A road map preparation is a first step of a project itself. It is necessary to plan each task, indicating when each user story can be completed approximately. Since this is your first Agile project accuracy is not what you should emphasize.

What should be included into planning then? A project is divided into segments, which consist of functional user stories. Every user story involves a certain set of acceptance criteria. Each of these parts is a certain "Definition of Done".

A user story is an instrument of functional description to answer a question: someone has to do something to achieve something.

A user story is according to the abovementioned scheme would look as follows:

As a _________ I want to _________ So that_______ .

Acceptance criteria are an instrument to describe specific functional requirements and show certain  steps to achieve an expected result. It is common to write them using Gherkin language. 

Initially such a method was used to facilitate tests planning in future, when the project starts working.

Scenario: Login

Given: I am on the Log in page

And: Login is valid

And: Password is valid

When: I click on “Login” button

Then: I am logged in as a user

And: My homepage opens

Let's take a look on estimation. Functional parts are measured in T-Shirt-like size system. XS, S, M, L, XL. Sizes of user stories are evaluated respectively in comparison with other user stories. We are selecting a story, which is clear enough to let us determine how long it would take to develop it precisely. This user story is regarded as a benchmark and each following user story is evaluated by being compared to this basic one. The whole evaluation system represents a ratio of a larger task and a small one.

Step 5. Sprints and sprints planning

Sprint 0

In such a situation, the sprint 0 is a key event, which will serve to solve all the problems and issues that may arise in future: how to form a vision of the project, order what is necessary for the product to prepare the team to Agile work, determine the size of sprints.

Sprint size is an important issue to solve for an agile project pilot. It is important to define a sprint size, so that in the case of operation risks our team would have enough time to restore.

Sprint planning

Since all the User Stories are written, evaluated, release plan is already defined, now comes the time for sprint planning. On this stage every new user story, which has been added but never yet  been evaluated, is reviewed. Afterwards, all the stories would be divided into tasks.

Velocity

Velocity is an average quantity of story points a team is able to deliver within a sprint. During the first sprint velocity value is obviously not yet known. A team decides, which tasks it would deliver for sure and. Sprint backlog is fixed and never changed.

Step 6. Sprint evaluation and success definition

The key elements which have an impact on sprint success are stand-up, Interaction and Modifications.

Everyday stand-up is a 15-minute long meeting, taking place at the same location, serves to answer the following questions:

• What did I do yesterday?
• What will I do today?
• Do I have any other problems at the moment?

Interaction is one of the main success factors, which depends on the teamwork level and interactions between every team member and others. According to the Agile Manifesto, “People and process interdependence are more important than processes and tools”,

Sprint Review and Demo

Every sprint should be finished with the following stages: a review and a demo.

These event are dedicated to discuss the results of work and a finished product is being shown to a customer. Feedback is received and new tasks are defined in case it is necessary. 

A retrospective takes place afterwards. It is aimed to show the following aspects to a project team:

• What have we done well?
• What could be improved?
• What would be improved in the next sprint?

What’s next? When all sprints are over and the product is finished, a retrospective and a team’s opinion on a result would define a further steps. Like how to use agile in other projects. First try might not be perfect, but it's important to make sure that it's good enough.