According to Project Management Institute, 71% of businesses use Agile practices for their projects in some way. As it is a flexible methodology, different people interpret and apply Agile in different ways. For many people, the idea of Agile became a kind of ritual over projects: people read the manifesto, divide into teams of 3 to 9 people, paste cards on the board, and meet daily telling their teammates about what they did yesterday… Still, Agile popularity does not generate dozens of successful projects. Why? This happens because Agile project management is pointless if the project team doesn’t understand its essence and application in their day-to-day operations.
In this blog post, we’re going to walk you through the basics of Agile project management and explain how you can incorporate its practices into your team’s workflow.
Background
Agile is an iterative approach to project management that lets you easily adapt to changing project requirements, and bring the maximum value to your customers. Agile principles and ideas are outlined in the Agile Manifesto.
Agile Framework is a set of the different practices and approaches based on the Agile philosophy stated in the Agile Manifesto. The most common agile frameworks are Extreme Programming (XP), Scrum, Kanban.
XP (Extreme Programming) offers practices that help minimize development costs, predict results as accurately as possible, promptly address changes in customer requirements, and train developers on-the-job. It focuses on optimizing technical aspects of product development.
The most widespread XP practices include:
- Pair Programming
- Test-Driven Development
- Continuous Integration
- The Planning Game
- Small Releases
- On-site Customer
While XP is only used in software development, Kanban and Scrum due to their adaptability can be applied in different areas of activity.
The core idea of Kanban is the ability to put the necessary features into production at any point in time and get them done as fast as possible. This is achieved by visualizing the entire business process on a Kanban board. The Kanban board is divided into several columns that signify a particular process stage. This board helps to detect and eliminate the bottlenecks at any stage of production. Kanban can be applied in different areas, from IT projects to industrial production.
Scrum is the most popular Agile framework on the market and is based on iterative deliveries of the product. And, as a matter of fact, it appeared to be a perfect fit for our Flowlu team’s needs. If you’re new to Scrum, it can be incredibly tricky. It seems so easy to grasp Scrum values but at the same time, it requires tremendous effort to put it into practice. In our case, it took about six months to implement Scrum, and almost a year to bring the expected results.
Who Uses Scrum
Scrum was originally born and applied only to the IT industry, but today its practices can be found in many projects. Usually, such projects include dealing with a high degree of uncertainty and turbulence. Today, Scrum is employed in marketing, educational projects, HR, media, legal industries and accounting, and more. It is believed that Scrum is especially effective for long, constantly evolving projects.
Scrum Team
The Scrum team is self-led and cross-functional. Its size ranges from 3–9 people. Scrum requires striking a balance between process and outcome. This is achieved when the project is managed simultaneously by the Scrum Master and the Product Owner. It is the presence of these two leaders that propels product development and team progress. However, if you’re a small team, these two roles can be played by the same person.
Scrum is a term borrowed from rugby, where a scrum is an ordered formation of players.
The Product Owner represents the interests of the stakeholders. This person knows the needs of the customer and end users like no one else. It is the product owner who gathers user stories and prioritizes them. The Product Owner is a key role and makes major decisions, so this person should have a high level of competence and responsibility.
The Scrum Master coordinates the teamwork, ensures its compliance with Scrum principles, tracks project progress, helps overcome difficulties, organizes standups and monitors deadlines.
If you combine these two roles, it is important to understand that one of the most important things is to find the right balance. The roles of Product Owner and Scrum Master imply an inevitable conflict of interest. It can be tough to adopt a stance between wanting to add more features to the current sprint (to increase the value of product delivery) and adhering to Scrum principles. Changes to the current sprint should only be made in case they are critical.
If one person can’t achieve such a balance, it is recommended to delegate the role of Scrum Master to another team member or a person not involved in the project.
Scrum Software
If you lead a small, simple project, you can use a physical board and sticky notes. To lead complex projects, you need specific software. At the initial stage of implementing Scrum, we used JIRA, which provides 100% coverage of our needs. But this software was extremely difficult to set up and learn. Therefore, within a couple of weeks, we released our own app to manage Agile projects. Ever since, our team has been using Flowlu for handling development projects. We’ve been constantly expanding its capabilities, focusing on our own needs and demands of our users.
Scrum Key Components
Scrum allows our team to deliver new features every four weeks and quickly fix flaws in the product, easily making adjustments to the roadmap. Let’s explore what Scrum tools and practices our team uses daily and what you can incorporate into your team’s work.
1. Backlog
Product Backlog is a prioritized list of user stories or work requests. User Stories are user wishes for the product written in the natural, real-life language. They usually identify what is needed, who needs it and what for. For example, as an accountant of a construction company I need a summary table of estimated costs and revenues to keep track of cash flow gaps. Such structure of the user story helps teams understand and implement needs more accurately.
Epics are user stories that cannot be completed in a single iteration and should be broken down into a set of tasks. An epic can be closed over several iterations.
The product owner should regularly review and re-prioritize user stories. In our experience, the importance of user stories can change dramatically over several sprints.
2. Sprint
In Scrum, projects are split into more manageable units or iterations — sprints. Each sprint begins with the planning phase and ends with a product demonstration and retrospective. It includes the most valuable stories and tasks, as well as critical bugs. Once the sprint has started, it is not recommended to change the sequence of tasks, as they are already prioritized.
Sprint is usually between 2–4 weeks long. The duration depends on the product type and the team’s capabilities. For example, a four-week sprint is the best match for software development teams and a one-week sprint might be a fit for content marketing projects.
Due to a strict deadline, the team gets used to working at the same pace, which has a positive effect on the result.
Sprint Planning
This is one of the most important stages of the entire iteration. It is during the planning that the team gets into the task essence and evaluates each issue. There are many ways to effectively assess the scope of work in Scrum. For example, our team uses poker planning.
This technique allows us to objectively assess each task in a sprint. Each team member evaluates the task using a physical card. Then, the team members reveal their cards all at the same time. When the scores match or differ slightly, a consensus is reached and the final score is accepted. Such a process is repeated for each task. In case of a significant difference in scores, each extreme score is sorted out collectively.
How should the stories be estimated? That’s up to you. You can use days, hours, abstract points, or story points. When using abstract values, it’s important to convert one unit to something measurable over time. We use story points, where one story point equals four hours of work.
Sprint Performance
To visualize the progress of sprint tasks, we use a board divided into specific work steps, e.g., To Do, In Progress, Done, Accepted. It instantly reveals what has already been completed and what has not yet been started. The task burndown chart helps to identify the teamwork pace, determine roadblocks and take timely action.
If there is a major problem, the sprint should be optimized, and the tasks — decomposed. You need to exclude the least important tasks from the sprint. But remember to include them in the next iteration and fully implement them.
3. Scrum Meetings
Daily 15-minute standups can benefit any team, even though all participants sit in the same office space and talk to each other throughout the day. At first, these brief standups seemed like nonsense, but after holding a few meetings, everyone starts to gain a clearer understanding of how the entire team achieves the goal, what challenges arise, and how they will be solved.
At such daily meetings, each team member stands up to talk about the previous day’s results, promises what will be accomplished today, and shares his/her obstacles. It allows every team member to stay on track.
Besides, such standups help to motivate the team members: each participant strives every day to achieve some result, otherwise he/she will have nothing to say at the next standup.
4. Sprint Demo and Retrospectives
Each sprint ends with a two-stage review — demonstration of the finished product and a retrospective. Both of them are conducted on the last day of the sprint.
During the retrospective, the teammates discuss what was done well and what can be improved in the next sprint. The retrospective duration may depend on how long the sprint lasted. For a one-week sprint, the meeting is about 45 minutes, for a two-week sprint it is 1.5 hours, etc. But mostly the length depends on the complications that arose during the sprint to eliminate them in the next one.
Conclusion
Agile is a set of principles aimed at continuous product improvement and easy adaptability to changing priorities. Scrum is one of those project management approaches that can only be understood by actually doing it. But once you implement it, it allows you to maximize your team productivity, boost collaboration, ensure quicker product delivery and better client satisfaction.