Scrum is a great approach for implementing most Microsoft Business Applications. But it’s not the most appropriate approach for every situation, and I often get asked: “When should we use Scrum and when is a different approach a better option?” Let’s try and answer that in this article.

In case you’re new to Scrum and wondering what it is, let’s give you a quick overview.

Scrum is a framework for developing, delivering, and sustaining complex products.

Although it has its roots in agile software development, Scrum can be used for managing any complex work with a small team.

To determine whether Scrum an appropriate approach for your Microsoft Business Application, there are two things we need to consider.

1. Product or Project?

The first of those aspects is: is your Microsoft Business Application a project or a product?

If you’re a Microsoft customer anticipating that your business application is something that can be implemented in a couple of weeks or months, then you’re treating it like a project. Scrum is still a useful framework for managing a business applications project, but you’ll miss on some of the benefits of Scrum unless you treat your application like a product that continually needs to be updated, enhanced and supported over a long lifetime.

Here you can see a comparison of the effort of managing a business applications project with its spike around month 15 when the application is released into production then the effort tails off when the project team hands the system over to support. When you’re managing your business app like a product, your level of effort looks more like the blue line. There are three bumps in effort when the app is released into production, and the team size slowly diminishes over time.

After considering whether you want to run your application as a project or a product, next it’s time to consider the complexity.

2. Application Complexity (Stacey Model)

This is a Ralph Stacey Complexity Model that illustrates four types of work – simple, complicated, complex and chaotic – depending on how close or far from agreement the requirements are and how close to or far from certainty the technical solution is.

Simple

Simple work is well-defined and easy to solve with well-known technology.

A Power App for yourself, your family or a small team fit into this category.

Templated Dynamics 365 Business Central projects also fall into this category.

Projects to implement these types of apps don’t justify Scrum. Your project team is likely to be 3 or fewer and take a few days or weeks to complete.

This type of work benefits from repeatable, best practices and is well suited to a waterfall approach. You might benefit from some agile tools such as a Kanban board to track your tasks. But trying to applying all of the Scrum framework is overkill.

Complicated

Complicated work faces a moderate level of unknown requirements and uncertain technology.

Power Apps and Dynamics 365 apps for a group or department, a departmental Power BI app, an app factory developing a large portfolio of Power Apps, or an ERP upgrade or migration could fall into this category.

Complicated apps take a few months for a small team to deploy.

This type of work often benefits from an empirical approach, like Scrum, where we learn as we proceed and can handle ambiguity and change.

Complex

Complex work faces unknown or divergent requirements and high degrees of technical uncertainty.

Almost all Dynamics 365 apps and any enterprise-wide Power Apps or Power BI deployments fall into this category.

Larger Dynamics 365 Business Central and almost all Dynamics 365 Finance & Operations apps do too.

Complex apps will often involve one or more teams and take many months to deploy in several releases.

Scrum is very well suited to complex work because of its inspect-adapt and act approach with frequent opportunities to develop small increments and seek feedback from our stakeholders.

Chaos

Work that is beset by extreme levels of requirements ambiguity or technical novelty is chaotic, and projects in this category are best avoided rather than tackled at all.

Developing a vaccine in response to a viral pandemic is an example of chaotic work.

Cynefin Model

The Cynefin complexity model is another way of looking at your application and determining its complexity and the approach to use.

When to Use Scrum?

Using either Stacey or Cynefin models, when should we use Scrum?

I recommend you don’t use Scrum and choose an alternative approach when you’re dealing with simple apps or trying to tame chaos.

I recommend Scrum when you’re building complicated or complex apps with moderate to high levels of requirements ambiguity or disagreement, and your solution is uncertain or unknown.

Other Factors Affecting Choice of Approach

Let’s take a quick look at some other factors that teams commonly consider when choosing to use Scrum.

Here are some adverse factors that might make Scrum a less than ideal approach.

Inexperienced scrum master

I know some Microsoft partners who have taken a scrum course and used Scrum on a project without an experienced scrum master; they practised scrum with low-risk clients on small, low-risk projects, but I still think that was a high-risk decision. Hire a contract scrum master if you haven’t got one.

Fixed scope

Even in 2020, some clients still ask for fixed-price because they want to shift all the risk onto their systems integrator. But they are unable to fix the scope, so the project dies by a thousand change requests and there’s rarely a win-win outcome for both the Microsoft customer and partner.

Time-zone dispersed

Scrum requires close collaboration between the product owner and all the members of the development team. That’s almost impossible to achieve when there’s more than 2 hours difference between any of the team.

Upfront analysis and/or design

50 years of software development has shown that upfront analysis and design is a fallacy. Some regulated industries such as pharmaceuticals require design by the regulator but even then, emergent design is a better option.

Stakeholder disengagement

Scrum requires frequent reviews and feedback from your stakeholders. If they insist on upfront workshops and don’t want to hear from you again until acceptance testing, then that’s a bad omen for Scrum. Probably a bad omen for any approach in fact.

Inexperienced customer and/or development team

I know some Microsoft partners don’t want to pitch Scrum to a customer that they believe probably prefers a traditional approach or has no Scrum experience. I’ve pitched Scrum in lots of situations like this and won. Almost every organisation today is already on an agile journey or is crying out for someone to lead them on that journey. They need a strong scrum master to coach them through their first steps. So does almost every developer.

Time-zone co-located

Time zone co-located but geographically distributed teams work really well in Scrum. I ran several projects this way in Southern California where no one wanted to commute through LA traffic, and today I run my Scrum teams this way because, even though there’s no traffic, we’re not allowed to leave the house!

Finally, here are favourable factors affecting Scrum as your implementation approach:

Fixed price or fixed time

If your customer has a specific budget or release timeline, then we can plan our sprints up to those constraints. They need to be flexible on the scope, but they’re in control of the scope by prioritising our work every sprint to maximise the value we deliver together.

Physically co-located

Physically co-located in the same office space is still my personal preference, especially if you’re all in the same city.

Emergent design

Just-in-time analysis and emergent design can be difficult concepts for some customers, especially old-school architects, to become comfortable with, but it’s undeniable that the best time to design a feature is as late as possible in the project when we’ve learned as much as we can about the requirement and how to work together as a team.

Engaged stakeholders

Engaged stakeholders who are frequently available is a hallmark of a successful scrum project. That means a senior business representative with decision-making authority dedicated to the team in the product owner role.