I was invited to a meeting with a customer last week that appeared in my calendar as "Agile and ServiceNow".
The meeting started and I prepared myself to go through the main features in our Scrum application to be told…
"We've seen the new features in Berlin, we don't want to talk about that"
The customer wanted to know how to apply Agile principles to building their ServiceNow instance and how could the development environment we provide best be used.
It is an interesting topic - in the Application Development team at ServiceNow we follow 2 different development processes: Code that goes into our product that is shipped to customers and code that we write for our own internal use.
With the latter we use exactly the same functionality as customers have access to - Update sets, Business Rules, Scripts Includes, UI pages and so on.
I have some ideas on Agile development practices for teams developing on ServiceNow but I think this subject is expansive. My colleagues in development might add to the topic with additional blog posts and I know our customers have a lot of experience they could share too.
The big ideas in this blog post
- Prototype before you start developing
- Teams should adopt Acceptance Test Driven Development (ATDD) to minimise the code written
- Update sets should be independent of each other and planned ahead of time
- Update set hygiene is critical
- Testing is probably quite important
Agile Principles
Before we talk about development practices we should quickly cover the approach and philosophy that development teams wanting to become more Agile should adopt.
Teams should take an iterative approach to building features and the ServiceNow platform supports this quite nicely.
ServiceNow allows teams to make small incremental improvements easily and transition those from development environments into production.
Rather than attempting to capture all requirements into detailed design documents before starting work on a feature requirements should be captured and ranked by priority.
Detailed analysis and development can begin on the highest priority features, where lower priority features can remain loosely defined.
A team working on ServiceNow can apply all of the common agile principles to their work
Development practices: Prototyping and defining acceptance criteria
Development outside of the ServiceNow environment normally involves editing code in files on your local system (for example Java files) that are committed to a code repository such as Git, Subversion or CVS.
Developing in ServiceNow involves writing code in your browser that is saved to your instance in an Update Set. The code you write (in Javascript) lives in an XML document that is run by users of your system.
So - whereas code hygiene of your codebase in a traditional development team is critical, so is the hygiene and maintenance of your update sets.
Update Sets are a good method of moving code but, like any code base, can get out of control too easily. Look what happens when you create a new table and a field on a new form.
You can see that one small customisation has resulted in 5 individual code artifacts - this isn't a negative thing, it's a feature of ServiceNow that allows a lot of flexibility, but once you start adding UI Policies, ACLs, Client Scripts and Business Rules that update set is going to be quite busy.
Therefore - knowing what you want to build before you start is invaluable.
In our Scrum teams we develop features for our internal teams in the same way our customers do. prototype a lot of work and throw a lot of concepts away. I'd recommend that teams prototype either on a different instance altogether or at least in a throwaway Update Set.
Your "production" update set should be treated with the same respect you'd give your Git/Subversion/CVS repository.
Another winning strategy is to seriously consider your acceptance criteria before starting development. In the ServiceNow Scrum app we have a method for defining what the business requires from the feature you are about to write.
Writing Acceptance Tests before starting development means that the development team will take a "minimal" approach to features, therefore keeping the update set cleaner. I'd recommend adopting ATDD (Acceptance Test Driven Development) as a methodology for ensuring you write just enough code to satisfy your users
Lastly - every Update Set row (or sys_update_xml record) has a Comments field. When we develop in update sets we pause at regular intervals, after writing a couple of business rules, and find the sys_update_xml record and fill in the comments. This means, when development is complete we look at the update set with a suspicious view on all rows that are uncommented. "How did this sneak into the update set? Do we need it?"
It's possible to group all of your Update Set entries grouped by type to ensure that your hygiene is up to scratch.
Point your browser to https://<< your_instance>>.service-now.com/sys_update_xml_list.do and group by the Type field to see what is lurking in your Update Set.
Plan update sets ahead of time
Using an Agile methodology probably means that you are taking an iterative approach to development. You'll work on a feature to a point where it is minimally releasable, deploy it to production and get valuable feedback from users in order to identify improvements.
Having the flexibility to deploy features in this way takes some prior planning. It is possible to move entries between Update Sets but that's ugly and prone to problems.
It's much better to take an end-to-end approach to your development and consider the transition phase from the moment you create the Update Set.
There is a great book I'm reading through at the moment called Disciplined Agile Delivery which takes methodologies such as ATDD and Scrum and provides an end-to-end process. It defines three distinct phases that a enhancement or feature goes through.
- Inception
- Construction
- Transition
At the beginning of your development effort think about how independently releasable is the feature is that you are building. Can you release this separately from another feature that is currently being worked on.
Occasionally we have a problem where we build a feature and demonstrate it to our internal stakeholders and then the transition into production takes a long time and gets confusing. Maybe you should create a change request at the beginning of development that the update set is named after and can follow the feature all the way to production.
I'd recommend planning your Update Sets so that the features are independently releasable. Also consider the entire effort involved in moving your code into production and create Change Requests early. Tie your Update Sets to those changes to track work from Inception to Transition
In summary
I should talk about testing in your effort to become more Agile in your ServiceNow development but lets leave that to another blog post.
It's worth talking about whats missing from ServiceNow today in order to have a complete set of Agile development capabilities.
Whats missing?
- Code fragments and a rich revision history
Adding code to an existing Business Rule or Script Include (or any code object) doesn't provide you with a "diff" like fragment of code. When reviewing changes you end up reviewing the whole body of code again which would be annoying for Agilistas - Unit testing
Although ATDD is a good discipline to use to ensure code meets requirements it is hard to test individual methods or Business Rules in isolation.
Someone once told me testing a system through the UI only is like trying to diagnose a problem with the plumbing in your house by peering through the shower nozzle - Easily reverting to a known state
It isn't particularly easy to revert your development environment to a known state with Update Sets. Users of code versioning systems will be familiar with throwing work away and reverting to a previous days commit. Not so easy with Update Sets
Having said all of that being Agile with your ServiceNow development is possible - and recommended!
11 Comments
