Demands on business has changed a lot. For many of us, gone are the days where the idea of ‘Plan the work, then work the plan’ saw us through.  If you want to build a product that stays in line with customer demands, then you have to rethink how the team responds to customer feedback. That’s why many teams embrace an Agile mindset. 

But what does that mean? 

 The need for an Agile approach

Traditionally business like to work the way we always have worked. After all, it worked for our fathers and grandfathers, didn’t it? 

But as times and demands on business change, so does the need to embrace uncertainty. And that is asking for a different mindset. 

It’s become increasingly common for projects to drastically change direction mid-way. When you want to build a bridge, you plan, you calculate, you draw and then you execute. Not when you build a website. In this case you determine the goal and play around ideas, you start building, you test, you get feedback and you go back to the drawing board to rethink, rework and fine-tune until you get it right. 

In the case of the website, it’s impossible to predict all the moving pieces in advance. And it demands a very different approach to the building of the bridge. Teams learn the project while they work it. And the different phases of a project don’t happen sequentially. Uncertainty is the common denominator.  By nature, instead of the planning stage being the key factor in financial success, it’s working the balance between flexibility and cost that comes with last-minute changes that becomes the goal.

With a shift towards more and more specialist workers, managers need to evolve too. Managers are no longer the Master knowledge-holders that keep the team in line with a directive management style. When managing a specialist team, your collective team knows more than you do. As a result, the need for a more collective decision making presents. Managers and their teams move away from the directive management style towards a supportive management style. 

 The Agile Manifesto

Enter the Agile Manifesto. 

The manifesto was born out of the need for a different approach for software development projects, exactly as we described above. But it equally applies to a whole range of other industries that demand flexibility. 

The Agile Manifesto is a set of statements and principles that help you embrace an Agile mindset. It is a guide about rethinking how the team works. While statements are designed to show the big picture, the principles are a lot more actionable. 

Without wanting to go into too much detail, the Manifesto describes how the team embraces change, collaboration and continually chases improvement.

The Projects start with the clients description on how the product will be used and what problem it will solve. This clearly outlines what the customer’s expectations of the project are. A project is then broken down into several stages of planning, executing, and evaluating. The aim for continuous improvement leads to an end result that could well end up quite different from what was the original idea was, as long as it fits the customer’s needs.  

Scrum

The developers of Scrum were part of the key group that put together the Agile Manifesto. But it’s important to understand that the Manifesto doesn’t prescribe Scrum. While Agile is a mindset, Scrum is a way to embrace that mindset. A bit like Fitness is a mindset and Aerobics the way to embrace the mindset. 

Scrum is by no means the only Agile framework, but because of its popularity, a lot of the Scrum language became the default language of Agile Teams, no matter the adopted framework. 

Kanban

Aside from Scrum, Kanban is another popular Agile framework. Many Agile Teams like to use a Kanban board to display their work. However, as we mentioned in an earlier blog, Kanban is about a lot more than the board. Kanban embraces Lean Thinking, which basically talks about respect for people and continuous improvement. You guessed it, a lot of the Agile mindset is a restatement of Lean Thinking. 

The Kanban board is a way for the Agile Team to organise their work in a way that helps them create the greatest value. It means that work should flow through the board in a very particular way. 

Kanban vs. Scrum.

So which one is better? 

There is no easy answer to this. Both Scrum and Kanban aim to improve delivery in a fast-paced and efficient way.  In both methods, you break down large, complex projects into manageable chunks. You visualise the workflow in a way which keeps the entire team in the loop.

But as much as there are similarities, each method is also fundamentally different from the other. For this reason, many teams do a lot of testing and investigating before settling on one or the other.  

Here are  some of the most eye-catching differences. 

• Roles: Scrum requires particular roles and responsibilities; Kanban doesn’t. 
• Sprints: The Scrum process uses ‘Sprints’. In other words, you toolbox your work or that of your team into 2 or 4-week periods. Kanban does not have a set timeframe. Instead, Kanban limits the amount of work, which is managed by priority of items on the Kanban Board.
• Meetings: A Scrum project team is expected to meet every day to discuss progress completed in the last 24 hours, progress expected in the next 24 hours, and any new problems that have cropped up. Also, each Sprint should end with a review meeting called a Retrospective. 

 The winner is…? 

Long story short, there is no right or wrong decision, it all depends on your team, your project, and your expectations.

Generally speaking, Scrum has a more pre-described structure and clearly defined roles. As a result, Team Accountability is considered better in Scrum. It’s a very transparent framework. The downside is it’s not always easy to implement. 

Scrum’s weakness is The Kanban Method’s strength and vice versa. Kanban is less structured and one of the simplest Agile Frameworks to implement (Note: there are more frameworks beyond Scrum and Kanban). Kanban allows existing processes and hierarchical structures to remain in place without requiring a major business overhaul. This is very appealing to many companies. 

And then there are the Teams who pick and choose. The whole Agile idea is that it should uphold the Agile Manifesto, but how you do that is up to you. 

After all, Truth is what works. 

A few weeks ago we added the Kanban Board to our ProWorkflow Tool so you can embrace the Agile Methodology while using ProWorkflow. We love it and we hope you do too!