Welcome to Amazing Applications -- the podcast for Power Platform and Dynamics 365 application builders who want to create amazing applications that everyone will love.

Hi, I'm your host, Microsoft MVP, Neil Benson. The goal of this show is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks and create amazing, agile Microsoft business applications.

Welcome back to the show. I’m grateful you’re listening. Thanks for being here.

You’ll find the show notes including a transcript and resources for this episode at customer dot comslash zero two nine (HTTP://customer.com/029).

In this episode, we’ve got a question from Gustaf Westerlund, CIO and founder at CRM-Konsulterna in Stockholm, Sweden.

I spent this week with Gus at the Microsoft MVP Summit, and got to admire his Covid-beard on several of our Teams sessions. With that beard, he’s no Julian Sharp, but Gus it feels like you’re one of the grandfathers of MVPs and I’m honoured to receive your question, Gus. Thanks for sending it. You sent it to me by email, so I’m going to ask Alexa to read it out. Alexa, please read Gustaf’s question:

“How can we get customers to really understand that an agile approach is best for them? Agile is built on trust. Trust that the developing partner will do their best. But if the customer has been burned many times before, this can be hard to gain. And half-hearted trust becomes half-hearted agile.”

Just before we start, I’d like to give a shout out to Veronica Kampf, COO at Gustaf’s company, CRM-Konsulterna who achieved her Professional Scrum Master certification with Scrum.org after taking my Scrum for Microsoft Business Apps online training course back in the early days of the course. Congratulations, Veronica, and thanks for being a valued member of the Customery Academy.

Let’s get back to answering Gustaf’s question about helping Microsoft customers understand and embrace an agile approach.

Know Scrum

First of all, I think you have to know Scrum and understand it before you can evangelise it.

I don’t think you can sell an agile approach, like Scrum, to a customer unless you have faith in it yourself. Don’t pitch Scrum to a sceptical customer unless you’ve got the confidence that comes from having a few successful Scrum projects. 

To win that first Scrum project, only pitch your Scrum approach to customers who ask for it, who are already convinced that Scrum is a good idea. You might need to hire a freelance scrum master to coach your team through that first project. But that’s OK. That’s what I did with Premier Medical Group in 2009. My customer was open to Scrum, but neither of us had experience, so I partnered with another Microsoft partner and we had a successful project. After that, we were able to run Scrum projects on our own.

Ensure your salespeople understand Scrum (whether you call them business development, account executives, or customer success). Lots of salespeople, and even a few marketing people, have been through my free Agile Foundations and even my paid Scrum for Microsoft Business Apps course so that they understand the approach their development teams use. I’d encourage them to join a few of your Scrum events too so that they can see how it works in practice.

Know Your Customer

Persuading a customer to adopt an agile approach falls somewhere in between sales and change management. It’s like sales because we’re selling a new approach in a competitive environment. We need to persuade customers that our proposition is the best option for them among the alternatives available.

It’s like change management because we’re asking a large number of people to adopt new ideas that challenge their status quo and alter their future behaviour with a belief that the future will be a better place for them.

In both cases, it’s immensely helpful to know whether your customer has heard of agile, has tried agile, loves agile, or is sceptical of agile. And when I say customer, when we’re selling our services to build a complex Power App or Dynamics 365 business application, our customer is often a group of people. Small customers will have two or three people evaluating your offer. Large customers might have dozens of people involved.

If you’re pitching to a small business, it’s feasible to ask and uncover the agile preconceptions or predisposition of all the contacts involved. If you’re pitching to a large enterprise, you might only get to ask a few of the buying contacts and have to make some assumptions about the rest of the people evaluating your offer.

Stereotypes can provide us with shortcuts here. I have a list of 10 benefits of an agile approach. I share 1 or 2 of them with end-users, subject matter experts, customer developers, IT decision-makers, procurement people, business decision-makers and financial decision-makers.

I’ll highlight the user satisfaction and sense of empowered collaboration to end-users. I’ll highlight the higher return on investment and more efficient allocation of capital to the finance director, and so on.

Know the Benefits

I’m going to summarise some of the benefits of an agile approach like Scrum. These are covered in part 4 of my free Agile Foundations for Microsoft Business Apps online course. 

Benefit #1: Better business software

I think that customers using Scrum build better business applications than customers using a traditional approach. Here’s why:

Instead of analysing all your requirements upfront, when you're using the Scrum framework your development team and users are building small increments every couple of weeks. There are two reasons that this results in more amazing applications: users learn more about the Power Platform or Dynamics 365 as the project progresses so they’re better able to describe their requirements as the application evolves. Whereas on a traditional project, they have to express all their requirements at the beginning having never used the software. The developers also get to design the features just in time to start development instead of doing all the design upfront, so they have more empathy for the users and a better understanding of what’s going to work in the customer’s environment.

Benefit #2: Early and Frequent Value 

With a traditional approach, none of your software is released until it's all ready for release. This is usually a ‘big bang’ release after all the development and testing is complete. Or maybe two or three slightly smaller bangs if the release is phased and the project doesn’t use up all its budget in phase 1. 

There’s no valuable software in the users’ hands until after months of analysis, design, development and testing.

With Scrum, your team is analysing, designing, developing, testing, and releasing software every week or two. You can be in production much, much sooner. That might not be possible with an enterprise project, for example, if you’re replacing a legacy ERP system but at least you can be in staging and have proven that your business app actually works.

Benefit #3: Faster return on investment and shorter payback period

An invisible drawback of a traditional approach is the time spent analysing and designing features that the developers might not have time to build before the timeline or budget begins to get squeezed. 

Because of the just-in-time approach to analysis and design, Scrum projects avoid this wasted effort which can reduce the overall costs by 30 to 40%.

As a result, the total investment is smaller. And as we saw in benefits 1 and 2, the software meets the business needs more closely and gets into the hands of our business users much earlier so the returns are higher.

Taking all these factors into account, agile business applications have a higher return on investment and a shorter payback period. Music to a CFO’s ears.

Benefit #4: Higher user satisfaction

Years ago, we’d have some requirements workshops with users at the start of the project. Once they had pretended to understand the requirements specification and signed it, we wouldn’t see them again until acceptance testing time. By then, it’s too late to address their feedback, and all their ideas get rolled into phase 2. It’s no wonder that users are so unhappy with business apps and the projects to deploy them.

Scrum teams have far more interaction with end-users than traditional project teams. Pandemic aside, Scrum teams are usually co-located with the users but at the very least we're demonstrating our progress and receiving feedback every couple of weeks. The developers’ priorities are managed by the customer’s product owner who represents the users and arranges the requirements according to their priorities. 

Teams using Scrum build better software, have more interaction with users and are more open and transparent during the development process. This generates higher user satisfaction with their Microsoft business application, and with YOU, the team who is building it.

Benefit #5: Greater transparency

Like Gus said in his question, agile is built on trust. This trust comes from Scrum teams’ open and honest stakeholder communications and the transparency our stakeholders have into our progress.

The product backlog, which describes all the work we’re planning to do, is available for anyone to review at any time. Our stakeholders can review our progress on building the application at sprint reviews and provide their feedback on what to work on next.

Scrum gives your project sponsor and governance committees more visibility into the project's progress which gives them greater confidence in the project team and Microsoft Business Apps.

Benefit #6: Efficient allocation of capital

In a Scrum project, the team requests the necessary funds to complete a few iterations of work. Allocating a small amount of capital to the project as it demonstrates a positive return is much more efficient than putting at risk a large allocation for a 'big bang' project.

Would you rather ask a CFO for a hundred thousand dollars for a short project to build a few valuable features and release them into production, or would you rather ask the CFO for a couple of hundred thousand dollars for a short project to document the requirements and system design?

Benefit #7: Lower risk

There are a host of reasons why agile approaches mitigate the risks of complex software development that afflict traditional approaches:

The empirical theory that underpins Scrum means that we learn from our experience by frequently inspecting and adapting our work. Traditional projects learn their lessons after the project is over in a post-implementation review. Consumer products are built using a repeatable process, but you can’t use a repeatable process to build complex business applications, you need to adapt your work as you gain feedback from your users.

We can use a technical practice called spikes to evaluate options and quickly demonstrate the viability of a design and value of a feature, which reduces the risk of designing a component that won’t work or that users won’t use.

Testing of all kinds -- functional testing, system testing, integration testing, security and per testing -- is run frequently during a Scrum project instead of being deferred to the end. Issues are detected earlier when they are cheaper to fix.

There are lots more ways that agile approaches mitigate risk, but those are my top 3.

Benefit #8: Your customer is in control

When we’re building a complex business application, we don’t know all the requirements upfront, but we do know the requirements will change. In a traditional project, the only time for raising requirements is during the analysis phase. After that, it gets really expensive and is governed by a change request procedure.

Contrast that with a Power Platform or Dynamics 365 project being delivered using Scrum. The Scrum team is regularly analysing the next set of requirements, just before designing and delivering them.

The customer’s product owner can change the order of the product backlog at any time in response to changing conditions. There is no protracted change request process or contractual renegotiation required. 

Of course, there are still potential impacts on scope, timelines or costs that need to be managed, but your customer is in control of those and can make informed decisions before making changes to the backlog.

Benefit #9: Working collaboratively together

Like all frameworks that follow the principles of agile software development, the Scrum framework values customer collaboration over contract negotiation. 

I find that agile Microsoft partners and customers work together as a single team focused on the customer’s product goal. Their agreement focuses on how the two parties will work together to create and release valuable, high-quality software.

Instead of a fixed-price statement of work that pits the partner against the customer to maximise their profits by delivering the fixed requirements for the least amount of effort, my experience is that Scrum teams create a much more collaborative relationship.

One of the benefits for customers and this is just my anecdotal observation, is that customer developers are much more welcome on Scrum teams. Helping to train a customer’s developer on a traditional project is usually pushed out into a separate deliverable after the project because otherwise the partner’s fixed-price margins are eroded by the knowledge transfer effort.

Benefit #10: More rewarding

Many of my customer’s stakeholders, developers and users I’ve worked with on Dynamics 365 and Power Platform projects using Scrum have reported that it’s been their “best project ever” and a highlight of their professional careers.

In my projects, users and developers work side-by-side towards the same goals. They forge close working relationships that foster mutual respect and understanding. So much understanding, in fact, that a lot of customer’s developers, stakeholders and users go on to do more and more Microsoft Business Applications projects. Maybe even jumping the fence into consulting.

Scrum encourages a sustainable pace. This means consistently delivering high-quality, production-ready features every few weeks. Scrum teams can often sustain their pace for several years without burn out that comes from traditional projects where there is intense pressure on budgets, timelines, and therefore on team members, during the testing and deployment phases.

Gustaf, those are my three tips:

Know Scrum - get your business development team members trained as well as your delivery team because they’re the people your customers will meet first.

Know Your Customer - if you can, find out their preconceptions and adjust your message either based on their predisposition or their role

Know the Benefits - some of the benefits are : better software, earlier value, higher ROI and shorter payback, higher user satisfaction, greater transparency, more efficient capital allocation, lower risk, more customer control over scope, more collaborative way of working and greater professional rewards. Cherry-pick whichever of those benefits you think will resonate with whoever you’re talking to. 

·       There are a few more tips such as
 Having strong collateral -- presentations and sales proposal content -- that describes CRM-Konsulterna’s agile approach and outcomes. 

·       Work with your legal counsel to structure your services agreement and statement of work to align with your agile approach too.

·       Only sell the sizzle. Don’t try and sell the sausage. What I mean is that, where possible, sell a short discovery exercise to formulate the product goal and initial product backlog and deliver a few sprints to build some valuable features and deploy them into production. 

·       If you can, avoid trying to sell the entire project to meet all the customer’s stated requirements. If you pitch to implement all the requirements, you’ll likely look more expensive than another partner who’s probably planning to pitch low and pepper the customer with expensive change requests later. There's a huge demand for the illusion of certainty and a lot of Microsoft customers are willing to peddle in it. Don’t be one of them.

Maybe we can dive deeper into the proposal and pitch factors in another episode, but that’s all we got time for on this episode.

Remember, I dive into those top 10 benefits in lesson 4 of my Agile Foundations for Microsoft Business Apps course. It’s a one-hour free mini-course. You can enrol at customer dot com slash foundations (HTTP://customery.com/foundations).

And you can get show notes, include a transcript of this episode, at customer dot com slash zero two nine (HTTP://customery.com/029)

Until next time, keep sprinting.