Can we talk about Agile for a moment?

[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. 

Full disclosure...I don't love SCRUM or Agile in their purist form. If you're reading this and you're an Agile zealot, I'm sorry, but we'll have to agree to disagree.  

These styles of application development just don't work very well when developing on the ServiceNow platform. 

Here's the biggest issue as I see things. With SCRUM and Agile, we have stories which are kept purposefully small in an effort to chop up the work into bite sized pieces. And we have a separate testing team waiting to testing each story upon its completion. Testers want to work (and should) in the TEST environment (not DEV). So...many development teams create a single update set per story, and as soon as they've completed that story they complete the update set and promote it to the TEST environment. If they don't immediately promote each update set to the TEST environment, the testing team is sitting around without much to do for multiple days each sprint...that's not good for anyone.

That might work for a while. You could get lucky for many sprints doing things that way, but eventually you'll create a scenario where someone's code gets clobbered by someone else's code. 

If two stories require 'touching' the same object in ServiceNow and they are not developed and promoted in the correct order, when you promote these two update sets to TEST you will trigger a preview problem where the version of the object you're committing is older than the existing object in the TEST environment.

Question: Will each of your developers (of all skill levels) know how to handle that situation properly, or will they blindly plow through those preview problems and accept the version in their update set because they 'know' that's the right version of this object? This blind acceptance of preview problems is something I see a lot of when working with customers. Researching and fixing these types of problems is also not something the average junior admin/developer can usually handle very well. 

Wouldn't it be nice to just not experience those types of preview problems? If you put your Agile trophy down and back away just a step or two, you can accomplish this reality. And, you might even reduce your cost of ownership in the meantime. 

Imagine a world where we don't immediately promote code as soon as each story has been completed. Instead, we slice our sprint cycles up into phases. We have a Development phase, a Testing phase, and a Production Readiness phase. 

• Development Phase (approx. 75% of your sprint duration) 
  • During this phase, developers are heads down working on the stories in the sprint. 
  • An update set is created for each individual story 
  • As stories are finished, the update sets are added to a Batch update set in DEV 
  • At the end of this phase, the single Batched update set is promoted to TEST (all potential collisions are therefore avoided) 
• Testing Phase (approx. 20% of your sprint duration) 
  • Your same development team (not a separate testing team #costSavings!) test each of the stories completed from the Development Phase in the TEST environment. 
  • No developer is allowed to test their own work, ensuring two sets of eyes on each solution 
  • Defects are raised, new update sets are created in DEV and batched together as needed to promote bug fixes as-needed during the Testing Phase until all defects are resolved. 
  • The initial Batch of code is then batched together will all bug-fix batches in the TEST environment 
• Production Readiness Phase (approx. 5% of your sprint duration) 
  • This phase could differ depending on how many instances of ServiceNow are in your stack. If you have a 'UAT' or 'Pre-Prod' instance in your stack, you deploy your newly batched update set from TEST to the UAT instance as a dry-run before the production deployment. 
  • If your process dictates that end users perform a light UAT (User Acceptance Testing) of each release, they can shake out the new code during this phase as well.  
  • At the end of this dry-run and/or UAT, you now have a single, batched update set to promote to production. Where all potential collisions are automatically handled by the batching process. 

The above development process is not compatible with the purist forms of SCRUM or Agile, but in my opinion it is the optimal way to run a ServiceNow Dev Shop.