Agile Project Management: What You Need to Know

A Brief History of Getting Stuff Done

In the 20th century, founders had an exact product vision, and based on that, they built an entire product. They formulated a business plan, and within a couple of years, the product was launched. The next step was finding customers.

Founders in the 21st century have a similar workflow; however, in contrast, they realised that building an MVP (i.e. Minimum Viable Product) first and continuous iteration is a better solution. After the launch, data - which helps better understand the user/customer needs - is collected and analysed. The product is iterated based on this information, and the process starts over again.

One major thing that has changed today is the initial first step; which is, identifying customer needs. This is then followed by building an MVP. As a result, the chance of failure is far lower than before.

But how do business owners build a “good” MVP?

This is where project management comes in. Currently there are two major types of project management: traditional project management (Waterfall) and agile project management. Firstly, it is important to understand that one is not better than the other. Secondly, in business life, these two can mix; once in a while boundaries can overlap.

Traditional Waterfall project management is built in phases. Dependencies are high between these phases. In cases where there is a blocker, the whole process stops until the problem has been solved. The project team can move on to the next phase only after the previous phase has been completed. Usually the scope of the project is pre-defined and fixed; however, time, cost and quality can change during the project. The physical design of the product is critical; changing it is not an option. The desired outcome of the product is well-defined at the beginning of the process. Large-scale projects usually require traditional project management.

Agile project management facilitates the continuous iteration of design and development. Unlike traditional project management, design, development and testing are concurrent activities. At the same time, quality, time and cost are fixed. The goal is to release an MVP and to continuously iterate it according to the needs of users.

After understanding the major differences between traditional and agile project management, let’s dig deeper into the agile project management process.

Agile Development Process Overview

Every project starts with a kick-off meeting. The main goal of the meeting is to deeply understand the purpose of the project. This is followed by creating a product backlog - a list of the desired features of the product. The project is broken down into two-week-long sprints which are finalised with demo meetings. But let’s not jump too far ahead of ourselves!

After the kick-off meeting, a sprint plan is organised in which the scope and the goal of the sprint is decided by the team. Theoretically, user stories should be broken down into tasks during the sprint planning; but in reality - here at Cheppers - user stories are created by the UX/UI design team before the UI is designed. By the time development comes into the picture, the UI design will perfectly reflect both the MVP’s features and users’ desires. In practice, an early estimation meeting is held to assess the total number of hours needed to build the MVP, (which is based on the UI design). The early estimation meeting is held before the kick-off.

During sprint planning meetings, tasks from earlier estimations are prioritised. According to the goal and capacity of the sprint, a sprint backlog is created. The sprint backlog is created based on the capacity of the sprint. The sprint backlog is a kind of to-do list for the team; it contains all the tasks that need to be finished by the end of the sprint. To determine the capacity of the sprint, the following questions should be answered:

• What are the number of ideal hours in the team’s work day?
• How many days in the sprint will each team member be available?
• What percentage of time will that person dedicate to this team?

After creating the sprint backlog, all dependencies between tasks should be identified by our team. During this meeting, some rules should be introduced as well, such as: the time of the daily stand-up; testing; code-review process; and, the acceptance criteria.

The sprint itself is a timeboxed working period with an exact end goal.

The daily stand-up is a short, maximum 15 minute long meeting. The meeting is held every day before the team starts working. With the help of the task board/Kanban board, every team member answers the following three questions:

• What did you do since the last stand-up?
• What are you doing until the next stand-up?
• Are there any blockers that are stopping you getting on with the work?

It is important to remember that the daily stand-up is a status meeting and not a place for actual problem solving. It is more efficient to arrange an alternate time to discuss solutions to problems.

A demo is created at the end of each sprint, and after that, a sprint review and retrospective meeting is held. The client is invited to the demo where a basic version of the developed features/screens is presented on a staging site. The work that the team has completed in the sprint is demonstrated, and the progress is evaluated by comparing it to the previously set sprint goal. The importance of the demo is that further improvements are identified. It also allows the client to give feedback.

The goal of the retrospective meeting is to have a dedicated meeting in which the team reflects on teamwork. Each team member answers the following questions:

• What went really well?
• What could have been improved?
• How would you improve your teamwork next time (Actions)?
• What identified actions should be built into the next sprints?

After the above has been completed, the cycle starts over again. The cycle does not cease until all tasks in the project’s backlog have been completed.

How it happens at Cheppers?

As I mentioned it earlier, in reality sometimes waterfall and agile mix together. At Cheppers the workflows are not clearly agile. Sometimes we have projects with a strict deadline, fixed budget, and fixed scope, which practically kills agility.

Even though sometimes our workflows are not clearly agile, we are keen on having agile ceremonies, such as stand-ups, retrospectives, sprints, sprint plannings, and demos.

We use the Easy Redmine project management software to manage all the tasks related to the projects at the same place. Recently, we introduced a physical kanban, that we use on the daily stand-ups so that each day we can track the advancement of the project.

Demos are an important part of our life at Cheppers. The demo is about showing the client what we have developed so far. The clients also give us feedback, we discuss what to change in the next sprint. We love demos because the earlier we realize the change required by the client the more efficient we can solve the problem. Usually, we try to prepare for the demo with an in-house demo, where we discuss what to say, what to show in which order. To have everything in mind someone from the team is assigned to write a demo script/scenario, which helps being prepared and organized on the demo.

In reality, sometimes it is hard to have people understand why project management is required for development, not to mention the importance of meetings and ceremonies. Usually, people believe, that development is only about developers sitting in front of the laptop and code. In contrast, without plannings, daily stand-ups, meetings, ceremonies and project management people don’t communicate and don’t plan, which result in chaos, having tasks done twice. Without clear plans, no one knows where to start, where to finish, or even what is one’s duty, what tasks depend on each other, so that some developer has to wait for one-another. These ceremonies help the efficiency of the development, which at the end of the day affects the client’s budget.