So you’re about to manage a complex project? There’s a whole bunch of work that needs to be done, but don’t panic! As a project manager, you will be responsible for planning, monitoring, managing the budget, executing, verifying the quality and releasing the final project on time. Thankfully, there are many project management methodologies that can make your (and your team’s too) work easier and much more efficient!
In this article, I would like to concentrate on the two most popular Agile methodologies – Scrum and Kanban – which have taken the software development world by storm in recent years. These days, you will hardly find a software house that doesn’t adopt these two frameworks for project management. What are they all about? Read on and learn everything you need to know about Scrum and Kanban!
What exactly is Agile methodology in project management?
Today companies no longer work on a single project without testing it at all stages of the development process. It just doesn’t pay off! Why not?
Just imagine: your whole team works for several months on, let’s say, developing a mobile app, which you only test and evaluate at the very end once the entire work of your backend and frontend developers, designers and copywriters is already finished. What if only then you realise that your product no longer responds to market requirements and user needs? You’d then need to introduce subsequent iterations of the whole project, which consumes much time, money and energy.
Agile methodology is thus a great solution that significantly improves the workflow and easy implementation of changes at every stage. The key principle behind Agile is to break down one “big” and complex project into several smaller items (or features) and release them one after another. Here, both development and testing are two concurrent activities, making it easier to continuously validate the project and introduce all the necessary improvements.
What’s interesting is that while for many years Agile prevailed in IT and software development companies, this methodology turned out to be so effective that it is nowadays used in many other fields such as marketing, sales, HR or operations. According to the State of Agile Report prepared by Verison One, in 2020 95% of technology companies and software houses were practising various Agile methods.
Scrum framework: why is it so awesome?
Many people tend to mix up two concepts that, although they seem to be quite similar, are not synonymous – these are Agile and Scrum. In a nutshell, Agile is an umbrella term that indicates all the methods and approaches specified in the Agile Manifesto, while Scrum is in fact one of those methods. It’s as simple as that!
What is Scrum and when can it be used?
Scrum is a project management framework, applied mainly to building complex products where the development process takes at least several months. It relies, above all, on transparency, ongoing communication between all team members and collective responsibility. This strategy facilitates delivering the final version of the project that satisfies the needs of the target audience and responds to current market demands.
Even though Scrum has become a leading framework especially in recent years, it’s actually nothing new. Let’s go back to 1986 when the Harvard Business Review published the article The New Product Development Game. There, the authors described a management approach employed by companies like Honda or Canon that led to their success. Then, in 1993, these concepts inspired Jeff Sutherland and the Easel Corporation team to establish a team-based process called Scrum.
Roles & responsibilities in a Scrum Team
In a Scrum team, all roles are clearly defined from the very beginning and usually don’t change throughout the entire project. As a rule, this framework has 3 fundamental roles: Product Owner, Scrum Master and Development Team.
Scrum Master
A Scrum Master is a kind of (but not entirely) team leader who makes sure that everything is done the right way and the development process runs smoothly. The main responsibilities of a Scrum Master are:
- coaching the team members so that everyone works more efficiently to deliver new features of the digital product
- planning all the tasks for the next sprints (below, I will tell you more about sprints in Scrum) and maintaining the product backlog
- educating stakeholders and all team members on the importance of Scrum principles for project management
- evaluating whether all tasks are carried out according to the plan
- trying to eliminate all obstacles that hinder the realisation of the tasks in a given sprint.
It’s extremely important that a Scrum Master always works closely with a Product Owner. Together they plan subsequent sprints, evaluate the quality of completed tasks, set a direction for the team and determine whether the project requires introducing changes. Simply put, the Scrum Master does their best to help the Development Team be successful and deliver all features on time.
Product Owner
A Product Owner is responsible for delivering the final version of the product that can generate actual business profits. Therefore, in the whole Scrum team, it is the Product Owner who sets the priorities and has the most decisive role. What’s important here is that the product backlog is managed by the Product Owner, who determines which product features should be developed as a priority, as they have the greatest business value.
These are the main responsibilities of a Product Owner:
- managing the product backlog
- contacting stakeholders
- defining the main goal of each sprint
- planning the release of new features
- evaluating the work of the Development Team and cancelling the sprint when necessary
Development Team
Without a Development Team, Scrum wouldn’t be possible as they do the actual work and complete all tasks scheduled for particular sprints.
Typically, the Development Team consists of people with expertise in a particular field, such as iOS, machine learning, backend or frontend development. They all join forces to deliver high-quality features of a digital product. You should keep in mind, however, that although the term “development team” usually refers to engineers, this is not always accurate. Marketers, designers, analysts, testers, copywriters or sales specialists may also bring some value and be part of a Scrum team.
One of the things to consider when building a Development Team is the number of its members. Even here Scrum specifies some ground rules! It is said that such a team must consist of 3 to 9 people and they should have the skills required to deliver all the features. Of course, it all depends on the complexity of the project and the client’s needs; sometimes 4 or 5 developers are completely enough to build a digital product.
But what exactly is the Development Team’s role in Scrum? Basically, it should:
- build all product features according to the Product Owner’s instructions
- determine how many items to build in a given sprint
- manage the workload efficiently so that all tasks are completed by the end of the sprint
- make all relevant decisions jointly
- have a ‘we’ attitude – the team makes all the decisions, solves problems together and each person feels responsible for other colleagues
Scrum development process in a nutshell
You already know what Scrum is and who forms a Scrum team, so now it’s time to understand what the development process in this methodology looks like and how to do it right.
In the Scrum process, every step counts and brings real value to your team. Here are the major stages you shouldn’t skip:
- Product Backlog: A list of all items that need to be built in the following sprints. It’s managed by a Product Owner together with a Scrum Master who know exactly when each feature or item should be released.
- Sprint Planning Meeting: The main purpose of this meeting is to define what each member of the Development Team will do in the next sprint. It’s always organised before the sprint starts so that everyone can assess whether they can complete all the tasks before the deadline. Make sure that every team member fully grasps the main goal of the sprint.
- Sprint Backlog: These are the selected tasks taken from the Product Backlog that the team has chosen to perform in a given Sprint.
- Sprint: This is where all the magic happens. Sprint is a short period, which usually takes 1-4 weeks when the Development Team works on completing all the tasks assigned during the Spring Planning Meeting.
- Daily Scrums (also called Standup): Extra short meetings held every day at the same time, during which everyone reports on their work progress in 1-2 sentences: they talk about what has been completed, and what still needs to be done.
- Sprint Review: When the sprint is over, everyone has the chance to present what they have completed to other teammates and even stakeholders, who quite often attend Sprint Reviews.
- Sprint Retrospective: Now it’s time for the last meeting that ends the whole Sprint cycle. If any team member has some suggestions or ideas on what could be improved for the following sprint, they can do it during the Sprint Retrospective meeting.
For the Scrum process, it’s essential to make sure that each Scrum cycle has the same structure: it starts with a Sprint Planning Meeting, then everyone gets down to work and completes tasks set for the sprint, and at the very end every team member shows what they have accomplished.
There is one more thing I want you to remember: Scrum has a very strict change philosophy. What does this mean in practice? Scrum team members shouldn’t change tasks or the main goals during the sprint. If they fail to deliver the planned outcomes, it should be a lesson for the future to better estimate the time needed to complete items.
A few words about Kanban
Now that you’ve learned what Scrum is and how to build a digital product with it, it’s time to focus a bit more on the second Agile methodology. I’m sure you’re already familiar with it – even if you don’t realise it yet!
What is Kanban and when can it be applied?
The term Kanban comes from Japanese and it can simply be translated as “visual signal”. That’s basically what this methodology is all about. In Kanban, each element has its visual representation – a card which team members put on whiteboards and change its status (such as ‘to do’, ‘doing’ or ‘done’).
This approach can be easily applied by any industry but is most often chosen by software development teams involved in complex and time-consuming projects. And for good reason – Kanban facilitates real-time communication and makes the work of all teammates fully transparent.
Interestingly, Kanban is in fact a much older methodology than Scrum. Its beginnings date back to the 1940s when Toyota introduced a system of separate cards placed on whiteboards in its factories that workers could switch at any time. As a result, this strategy made their work much smoother and sped up communication between teams.
Who is who in a Kanban team?
When discussing Scrum, I described the exact roles, responsibilities and competencies of each team member (Scrum Master, Product Owner and developers). Here, things are much different. Kanban doesn’t define who has more power or responsibilities, as practically all team members are equal and they join forces and skill sets collectively.
Moreover, Kanban doesn’t specify how many people can work together on a project, so any team structure is acceptable. However, if you want to improve the workflow, you may want to consider building a cross-development team. Thanks to this solution, team members with different areas of expertise can share their knowledge and give feedback at each stage of product development. This way, there will be no need to consult other teams at all!
What is a Kanban board and how to create it?
The Kanban board is the heart and soul of this methodology. It’s a project management tool created to visualise the progress of each task in real time. If you’re wondering whether your teammates have already started working on an important feature, or maybe they’ve already finished it, just check the board and now you know!
This example shows exactly what Kanban is and how it visualises work:
So the general concept behind Kanban boards is pretty simple: you have several labelled columns and on each of them you place visual cards. These can be stickies or tickets. On each of these cards, you write down the name of the project you are currently involved in or the specific work item you are building. Then all you need to do is allocate a particular card to a specific column so that the rest of your team is updated and knows exactly what you’re working on now.
The example you can see above shows typical column categories, which are:
- ‘to do’
- ‘in progress’
- ‘testing’
- ‘done’
Note, however, that you can describe your workflow more broadly and add additional columns – their choice will depend on the project you’re managing.
If you want your team to succeed, there is one more thing you need to be aware of – you should define limits for items your team can work on at the same time. This is why Kanban additionally recommends setting Work In Progress (WIT) Limits. How to put it into practice? You need to specify how many cards can stay in a column (e.g. ‘In progress’) at the same time. If your team reaches this limit, they simply can’t add more cards. Setting these boundaries is always a great solution to deal with work overload.
Scrum vs. Kanban: which framework wins this battle?
Well, the answer to that question is actually not that simple. These two Agile strategies share some similar principles but the practices they employ are two completely different things. While Kanban is more fluid and favours continuous change and regular feedback, Scrum is much more strict and organised.
Here are the main differences between these two project management frameworks:
So, which of these Agile frameworks will you choose to manage your projects? Or would you like the experts to do it for you? Feel free to contact us – by introducing various Agile methodologies, we have delivered over 150 ready-to-use successful products!
Top AI innovations delivered monthly!
The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest. You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.
