Business

Agile, Kanban, and Scrum – why you need to personalize them for best results

Adrian Kasprzak, Apr 16, 2019

6 min read

During the last few years, agile has become a buzzword in the project management world. And you know how it goes with buzzwords: everyone talks about them, but very few people actually know how to implement them for the best results.

In this article, I wanted to take a closer look at the agile methodology and two most popular agile techniques, Kanban and Scrum, to show you when implementing them is a good idea and why you should never treat the rules that come with these techniques as fixed and unalterable.

I believe that personalizing agile workflows is the best thing teams can do to make the most of this incredibly productive methodology.

But first, what exactly is agile?

At its core, agile is a specific philosophy about how teams can develop software in the best possible way. It's an approach to project management that puts specific values over others to prioritize incremental, feedback-driven changes in software development.

Here's why agile became so popular:

Until recently, the most widespread method for developing software was the so-called waterfall method. Teams were spending a massive amount of time and effort upfront to gather resources and plan development with critical decisions based on assumptions.

At some point, it became clear that this method wasn't working. It was highly regulated, restrictive, and simply too slow for a world where the pace of business was continually accelerating.

The waterfall method relied on predictability. And what software developers wanted was more flexibility and the opportunity to act on feedback from real users.

In 2001, 17 people came together to create what they called an alternative to documentation driven, heavyweight software development process. They outlined their beliefs on how software projects should be managed and called it the Agile Manifesto.

Here are the four fundamental values that all agile projects should aspire to:

  • individuals and interactions over processes and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan

Note: All the Agile Manifesto did was presenting a set of methods, values, and principles. It didn't say how a team can achieve them. That came later with the emergence of different agile techniques.

Let's take a closer look at two of them.

What is Scrum?

While agile is a set of methods based on the principles and values that were part of the Agile Manifesto, Scrum is a framework used by development teams to implement agile. Following the agile principles, it fosters collaboration, self-organization, and cross-functionality of teams.

Scrum quickly became successful and spread throughout the product development world. Today, the vast majority of software development teams know Scrum and follow it.

Scrum comes in handy for any sort of complicated project. It works best when the team needs to produce a concrete product which can be anything from a piece of software to website copy. Scrum is there to help organize the team and get more work done in less time, ensuring that applying changes is easier and less costly than in other variants.

What about Kanban?

Kanban is another agile technique that promotes continuous delivery while keeping the work on the project simple and without overburdening the team.

The central idea behind Kanban is the so-called Kanban board. This board helps teams to visualize their workflows and tasks. It's is usually composed of several columns marked as backlog, to do, in progress, and done. By moving tasks from one column to another, team members can signal what they're working on. Also, all team members can see the items they're are working on in the context of each other to get the bigger picture view of the project.

Kanban keeps things clear and straightforward once projects become more complicated. Project managers don't need to reach out to individual team members for updates because all the work being done is displayed on the board. One glance at the Kanban board is enough to know how many tasks are left for the project to reach its completion.

When it doesn't make sense to use agile

All of the above might sound just great. But let's be clear: not every project will benefit from agile.

Agile is all about moving quickly and staying nimble. It means that not everything is spelled out or carefully planned beforehand. That's why before introducing agile to your team, it's a good idea to know whether your environment can handle that kind of change.

Ask yourself these questions:

  • Are you open to starting a project without knowing what the result will be?
  • Are you willing to introduce a simple version of your product like an MVP for your users to test?
  • What is your attitude towards risk?
  • How flexible is your team?
  • What's your company hierarchy like?
  • Can your culture accommodate agile?
  • How do you measure the progress and success of your projects?

Agile project management is about constant work in refining the process and improving the product. To make the most of agile, you need to be prepared to leave ideas easily and chase those that promise the best results.

If that matches how your company culture defines progress and success, agile is a good fit. Think carefully when answering these questions to learn whether your team and organization are ready to take on the agile approach.

Here's how to make agile work

To make sure that agile brings you the best results, the first thing you need to do is implement a workflow and see how your team responds to it.

Remember that the Agile Manifesto never said that is a Scrum sprint needs to last two weeks. For some teams, it might make sense to have a shorter or longer sprint. The same goes for the daily standup meetings. While some teams can benefit a lot from meeting every day, for others a weekly meeting is more than enough.

That's why when formalizing your agile workflow, it's essential to remember that it's not rigid and can be changed to match the requirements of your organization, team, or project.

Agile can be personalized. In fact, rigidity is something that goes directly against the agile principles that embrace flexibility in order to stay nimble and responsive to change. What's the point of introducing agile if it makes the life of your team members difficult?

To keep your agile projects on course, you need proper project management tools that will address the three most common issues that crop up in agile:

  • Communication – you need to make sure that everyone is on the same page about the state of your project. Task lists, user feedback, and assignments need to be shared easily with everyone.
  • Reporting and metrics – progress reports, time tracking, quality assurance, and the big picture view at progress are all essential to agile. The right agile project management tool will deliver these features.
  • Project assessment – your tool needs to include functionality that allows identifying and dealing with obstacles or bottlenecks in your process. You should also be able to evaluate the performance of your team and ensure that your project budget is under control.

Use agile smartly

Agile has become widespread for a reason. It helps software development teams deliver quality products within the scope of today's economy where market changes happen fast, and user feedback is a crucial determinant of success.

However, that doesn't mean your organization should introduce agile with strict adherence to the rules offered by techniques like Scrum or Kanban. Allowing your team to ease into agile and find its unique path is the best agile practice known to project managers. So keep the agile principles close, but let your team decide how to translate them into their daily practice.

Are you looking for a team of agile software developers who know how to build products quickly and iteratively?

Get in touch with us; we are experienced in delivering quality software development services using the agile methodology.