Is Agile Development viable for Business Central customizations?

 by Steve Endow

To the Agile Advocates (tm) who will immediately protest "Of course it is!" before reading on, I ask:  

Hear me out.

Reference:  What is Agile?

Reference:  What is Agile Development?

Reference:  Manifesto for Agile Software Development

Book:  Agile Project Management for Dummies 3rd Edition

Book:  Agile Estimating and Planning

Book:  Scrum: The Art of Doing Twice the Work in Half the Time

Disclaimer:  I'm not an Agile expert.  I'm someone who has tried to learn about Agile (on several occasions) and tried to understand if and how some Agile practices might be used in the projects I work on.  I'm asking lots of questions, for which I'm having a difficult time finding answers on my own through part time self-study.

"Agile Development". It sounds cool. It sounds compelling. If you've ever suffered on a long, complex project that was over budget and seemed like it would never end, you'll likely appreciate some of the benefits that Agile claims to offer.  You'll read the Principles behind the Agile Manifesto and say, "Yes, please!"

It definitely appeals to me.

But then there is the reality that I personally work in.  Over the last 26 years, I have done consulting and development work mostly for "mid-market" customers in the US.  Based on my years of experience, admittedly with organizations and teams that didn't have "best practices", I'm having a difficult time trying to map Agile practices to the mid-market ERP projects that I typically encounter.

My inquiry is not about whether Agile is good or bad.  I'm trying to understand if Agile is a good fit, or even a viable option, for my customers and my projects.

Context:  Project Size and Scope

The mid-market projects I've worked on over the years have been thousands of dollars or tens of thousands of dollars in consulting fees.  I think I worked on one large project that was probably well over $100,000, but that was very unusual for me.  So keep in mind that I'm used to delivering solutions to customers that usually cost under $30,000.  Quick.  Complete.  Inexpensive.

More context:  None of my customers have dedicated internal project managers.  Very few of them have an internal ERP administrator.  And even fewer have an internal developer.  Also, my current team only has one dedicated developer, one technical project manager, and one functional project manager, so my organization is small as well.

For contrast, I had a conversation recently with someone who explained that she won't even consider a consulting project under $6 million.  Six.  Million.  Dollars.  That number rolled off her tongue with a confidence and self-assuredness that amazed me.  A customer "only" wants to spend $4 million?  Nope, not worth her time.  I was speechless for several seconds as my brain tried to confirm the words I heard.  Let's be clear that those are NOT the projects I work on.

Question:  Is there a minimum project budget required for Agile Development to be viable?  

Related Question:  Is there a minimum project team size or staffing level required for an Agile Development project to be practical?

I have several challenges trying to understand if, and how, Agile Development might be used with my projects, but I'll just mention 2 challenges for now, as those are two that I've investigated.

Challenge #1:  Proposals and Estimates and Timelines

My mid-market customers want 3 answers before approving a project.

1. What exactly am I going to get at the end of the project?

2. How much is this going to cost me?

3. When will the project be done?

I started reading Agile Estimating and Planning, but although the book has English words and sentences in it, it felt to me like it was written in a different language.  My impression is that it is based on an entire foundation of Agile concepts that will require months of studying and learning for me to grasp the larger philosophy, terminology, practices, and communication techniques of Agile to even be minimally competent with Agile Estimating.

I could be completely wrong due to my lack of knowledge and experience with Agile Estimating, but it seems like I would also have a very difficult time proposing an Agile Estimate to one of my customers.  Unless I'm directly and briefly answering the 3 questions above, they would also think I'm speaking a different language.

Question:  Is Agile Estimating viable for a customer who has never been involved with an Agile project and never heard of Agile Estimating?

Question:  If a customer wants answers to the 3 questions above before approving a project, does that immediately rule out Agile Estimating?

Related question:  If I'm unable to use Agile Estimating on a project, does that automatically and completely rule out Agile Development for the project?  Or are there options for "sort-of-partial-Agile Development" practices on the project?  (see Challenge #2)

Challenge #2:  Iteration and Integration is Costly (for my customers)

For a moment, let's just assume that my projects aren't suited for an Agile Estimate, and a full blown Agile Development methodology is not appropriate for my projects or my customers.  No problem.

Even though the project isn't "full Agile", I can still use some simple Agile tools and practices, right?

For example, Business Central development projects can use:

1. Automated Testing and Acceptance Test Driven Development

2. Azure DevOps Pipelines for build automation

3. Continuous Deployment using Business Central Automation APIs 

Given that these tools are available, I thought, "Awesome! Let's do some iterative development and crank out releases!"  

Let's be "agile"!  Let's push beta releases!  Let's push minimum viable product and get early feedback!  

Technically, the tools listed above worked well.  We produced prototypes and alpha releases and beta releases.  We were able to quickly iterate.  We were able to quickly fix bugs and add features and crank out new, tested releases with a click of a button using Azure DevOps.

But after several months of trying to provide rapid releases to customers, I came to a realization.

My customers are unable to keep up with a rapid release pace.  They simply do not have the time and attention to look at new releases every week or every two weeks, and perhaps not even once a month.  

Our application consultants are also challenged to keep up.  They are very busy with dozens of tasks aside from customizations, and in most cases, a new deployment requires a call with the customer to get logged in and upload a new PTE or install a new AppSource release.  And then the customer needs to set aside time to review the changes, bug fixes, or new features.

We have not yet had a customer where we could use automation APIs to automatically install or update an extension.  Even if we were able to achieve Continuous Deployment, the problem I'm seeing isn't a technical one, so I don't know that Continuous Deployment would help our projects be much more Agile.

In one case, we've released a new version of a PTE and installed it in the customer's environment, and a month later realized that the customer still hadn't used or even reviewed the new release.  I assume they've been busy.  I'm guessing they've had other priorities.  Maybe there was a communication issue--and I'll take the blame for forgetting to follow up, as I'm also busy.  But that lack of follow up happened to provide a valuable lesson:  I learned that the customer still hadn't looked at a new release after a full month.

In another case, we released a new version of an app for Business Central v19, but then realized the customer's environment was still on v18.5.  We then had to fix the BC upgrade issue, and now we're still waiting to schedule another call to get the new version installed.  Weeks have passed.  Again, the customer is busy.  A deployment call takes time.  Reviewing the new release takes time.  Etc. Etc. Etc.

So even if we are able to technically deliver incremental releases as quickly as every week, I'm seeing some clear signals that my customers are simply unable to consume them at that pace.  

Given this, is there really any value in pursuing Agile Development for my typical customer?

Is It Really "Agile" At This Point?

If I have a project that does not use Agile Estimating, and if the project does not use iterative development with multiple or rapid releases...is that a fundamentally non-Agile project?

If I have a waterfall estimate plus a big-bang "Go Live" and a mad scramble of bug fixes and enhancements immediately after go live, I'm assuming that's non-Agile, even if we are using Automated Testing, Continuous Integration, and Continuous Deployment.

It's Good to Know We Can

Although our current customers may not be comfortable with an Agile Estimate, and may not have the capacity for an Agile project or rapid release cycles, I think it's good to know we seem to have the capability to iterate and deliver quickly if we ever need to.  And that we can at least use the technical tools to support rapid development, testing, and deployment, even if it isn't technically "Agile".

Maybe I'll never work on a project that uses Agile Estimation or full Agile Development, but I'm still planning on using Automated Testing and DevOps Pipelines for all of our development projects.  That makes our lives easier, regardless of the release pace.

Steve Endow is a Microsoft MVP in Los Angeles.  He works with Dynamics 365 Business Central.

You can also find him on these platforms:  https://links.steveendow.com/