A Short Guide on How to Get Started With Agile Project Management

Agile has several advantages over Waterfall. Agile is more suitable for software development, but not all companies are ready to move from one to the other. Waterfall has served us well for a long time, and is still considered a good methodology by many companies who integrate it into their day-to-day work. Agile is a relatively new methodology in development. A couple of key differences between Agile and Waterfall are the methods used in each to control the development process, and the way each is used in the process of formation requirements.

In this article, I’ll tell you step by step how to smoothly move from Waterfall to Agile.

Select a Project

While selecting a project there are several important factors to consider, including:

• Length of Time
• Risks
• Stakeholder involvement

Length of Time 

The project length must be at least 4 weeks, with a maximum length of 12 weeks. This timeframe is optimal for your team to form their opinions and give feedback on the Agile process, as well as coming to an understanding of the methodology itself. 

Risks 

The project must be important, but not critical. There should be no pressure on the team from either deadlines or clients. Since this is a pilot project it is very important to concentrate on the implementation of the methodology, rather than fighting fires.

Stakeholder Involvement

It is important to involve as many participants as possible in the project - PM, designers, developers, testers, analysts, etc. Also, the project has to go through all the stages of development, from concept, to design, to analysis, and finally development. It is important to understand all aspects of the implemented methodology, and to get feedback from every participant on every step.

Choose a Team

This is the second most important element in your first experience with an Agile project. To complete the project succesfully, team members must have all the necessary skills to achieve the results. Also, the team should want to implement Agile into their work. A team of enthusiasts is one of the main contributing factors to successful integration.

One of the key Agile principles is individuals and interactions. A team that is organized and self-motivation is important, as are the interactions of its members with themselves and the customer.

Formation of Roles

The next step is the formation of roles in the team. Key roles in any Agile team are:

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

These roles are divided into two groups: Client Side and Technical.

The client side, namely the Product Owner and the BA, are responsible for the creation of requirements, and form them into user stores. The goal of the Product Owner is to provide “just enough” information to the development team, so they would be the last member of the team to begin work on the product.

Planning and Estimation

An early stage of planning is the “Road Map.” It is necessary to plan the task with an approximate indication of when each user story can be completed. Since this is your first Agile project accuracy is not what you should emphasize.

So, what should be included in the planning? Planning consists of parts which are divided into functional user stories, and each of the user stories involves a certain set of acceptance criteria.

User Story

A user story is an instrument of functional description, which answers a question. Someone has to do something to achieve something.

A user story is:

As a _________

I want to _________ 

So that_______

Acceptance Criteria

Acceptance criteria is an instrument used to describe specific functional requirements and show specific steps to achieve the result. Acceptance criteria are written in the Gherkin language. Initially, this was done to facilitate the creation of tests to the working product.

Scenario: Login

Given: I am on the Login page

And: Login field has a Valid data entered

And: Password field has a valid data entered

When: I click on “Login” button

Then: I am logged in as a user

And: My homepage opens

Estimation

Let's take a look at estimation. Functional parts are measured in a t-shirt size system: XS, S, M, L, XL. But the size of user stories is evaluated in comparison with other user stories. We are selecting a user story where we can determine exactly how long it would take to develop it. This user story is taken as a point and each following user story is evaluated in points compared to this one. It is the ratio of a larger task to a smaller one.

Sprint and Sprint Planning

Sprint Zero 

In this situation, the sprint zero is a necessary event, which will serve to solve all the problems and issues that may arise. From a vision of the project, order what is necessary for the product to prepare the team for Agile work, and determine the size of the sprints.

Sprint size is an important question for the pilot Agile project. It is really important to form the size of a sprint, so in the case of operation risks, the team has enough time to resolve any issues.

Sprint Planning

Once all the user stories are written and evaluated, and the release plan is completed, it’s time for the sprint planning. In planning, there are any number of new user stories which have been added, but never discussed. Further, all stories will be divided into tasks related to estimated acceptance criteria.

Evaluation and Success

 The key elements affecting the success of the sprint are: Stand Up, Communication and Measurement.

Daily Planning is a 15 minute exercise conducted by the team. Every day, the team should gather in the same place, and answer basic questions, like:

• What did I do yesterday?
• What will I do today?
• Do I have any problems or concerns?

Interaction

Teamwork and cooperation are two of the most important factors in Agile implementation. As stated in the Agile Manifesto: “Individuals and interactions over processes and tools.”

Sprint Review and Demo

At the end of every sprint you should hold a Sprint Review and Demo.

Sprint Review and Demo is an event at which the work during the sprint is discussed and the finished increment is shown to the customer. Another important aspect of the Review and Demo is collecting feedback from each of the participants on how the sprint went and the new challenges created by the process.

At the end of these two events, you should hold a Retrospective session. This event is held for the team and covers such things as:

• What was done well during the sprint?
• What could we improve upon?
• What will we improve in the next sprint?

Staging a Retrospective of the entire project and getting the team members' opinions about the new processes is one of the most important elements to help you with your decision(s).