Agile Scrum – The Cool Kid on the Block

[Chris Pearson]

Disclaimer: The ideas, thoughts, and opinions in this post reflect my own views and do not necessarily represent the views of my employer, Accenture.

By now, if you haven't heard of agile development and its most common flavor, 'scrum' it's quite possible you may be a time traveler from the past...or have recently been awakened from a cryo-freezer (it's a thing...look it up if you dare).

For years now, scrum development has been the coolest kid on the block that everyone is trying to be best friends with. This framework for development has become so popular across companies' development teams that it has gotten to the point if you're not using it, a stigma exists that you're doing something wrong.

Let me try to be a voice of reason in a scrum addicted world.

We've all heard the phrase, "There's a time and place for everything." And the non-millennials probably recognize the phrase, "Don't throw the baby out with the bathwater." These are what comes to mind when I think of agile scrum development.

There's a difference between ServiceNow Phase 1 projects and steady state maintenance. It's ok to have different development approaches to each situation. Although I still have a lot of issues with scrum that I'll get into soon enough, where it does make more sense to use between these two situations is during the steady state maintenance of the ServiceNow platform.

Once you are live on the platform, you will find yourself with a 'wish list' of items the business had hoped could have made it into the Phase 1 project. This is your initial backlog of items when you go live. Inevitably, you will also have a list of defects in your backlog which your user base will report to your development team via whatever intake method you've put in place. A backlog of smaller, compartmentalized enhancements and defects along with an endless amount of future repeating sprint cycles is more suited to an agile approach to software development, dare I say even scrum.

In this situation, you will have the appropriate time (many sprints of a static team size and time to practice sizing stories by assigning points in a consistent manner) to arrive on a predictable, stable capacity your dev team is capable of delivering in a single sprint. Team capacity is one of the most important lynchpins of scrum development. Without proper capacity, you are unable to accurately plan your sprints and will be constantly under-filling or over-filling your 'bucket of work'. If you have the proper people assigned to the many different roles in order to make scrum development function (and that's a big if), it is possible to get into a rhythm of requirement gathering, backlog grooming, story sizing, sprint planning, development, testing, user acceptance testing, and code deployment activities. It can work. I've seen it happen, but it's rare to come across this in its pure form.

Where scrum doesn't fit is during an initial deployment of ServiceNow...what we in the biz call a Phase 1. My biggest problem I suppose simply comes down to people, teams and companies just not being honest with themselves. Because nobody wants to step out onto that now flimsy limb and say, "We are not going to use agile scrum development for our Phase 1" due to the inevitable backlash that would ensue, we instead state that all development will follow the industry's best practice of agile scrum development and push forward.

I've actually started to lose count these days, but I can easily say I've helped over 30 companies deploy ServiceNow or enhance the platform with custom applications or by activating/configuring additional modules on the platform. Not a single project has ever used agile scrum development in its purest form, although almost all of them claimed to. Just because someone says the word 'agile' or 'scrum' at some point during the project does not mean you're following that particular development methodology.

I know I'm paddling upstream here. I get it. The big companies all have their published deployment frameworks, and they all are scrum-based. It just turns out they're doing it wrong, or at a minimum pretending to be agile because they feel they have to. This is what I think should be said at the start of a Phase 1 project: "We're going to use a unique approach to software development where we take the best principles from agile and scrum but don't get hung up on the details of either methodology which just don't fit when deploying ServiceNow for the first time for a customer." Would that sell? Would you get crickets back from your customers and confused faces? I'm not sure...probably. And that's mostly why we all continue to pretend to use scrum on Phase 1's.

So what does this brave new world look like you ask? How should we set up our Phase 1 project teams and how should their workload flow from concepts and requirements to finished product? Those are the topics of multiple future blog posts. Until then my friends.