Success Secret 1#
Embrace Agile and use it correctly; don't use it as an excuse for not doing things e.g. documentation. Documentation should be produced of requirements, design and acceptance criteria, process documentation etc.
Success Secret #2
Ensure teams are co-located either physically or via IT systems and the Product Owner is part of the team. A collaboration environment which allows all team members to see requirements, development tasks, test plans and results, documentation etc all in one place is essential to success.
Success Secret #3
The team and Product Owner must be empowered to make decisions. It is all about getting decisions made quickly. Try and fail fast is the key to success.
Question 4 - Budget holders are nervous and using Agile because seemingly the budget is unconstrained. How do you manage this concern?
The prioritisation of requirements at the beginning of the project is key here. Once a budget holder is educated as to how the requirements are identified and prioritised then those concerns are often ameliorated.
The MoSCow approach allows the business to see that the most business critical requirements are delivered first and at a second level of prioritisation, the highest risk features are delivered early. If they highest priority and highest risk features are delivered first then at that stage generally the contingency and resource is available to deliver without impacting the overall project.
That last thing that any business wants to see is high priority features delivered at the end of the project when the budget is getting thin.
Another key approach here to reassure the business is focusing the testing of the platform from a requirements perspective, directly linking the testing of the system to the defined business requirements. It is all well and good providing and running test scripts that focus on the underlying technical configuration, that will prove that the code works, but does it prove that the business requirement has been met?
Question 3 - How do you avoid an Agile project being open ended? Surely if the requirements are defined as you go along there is a risk that you will never finish?
All projects tend to have a defined budget and a limited amount of resource. Generally the business case for a project will have already defined the high level features of an application and these will be defined and scoped at a very early stage using the MoSCoW (Must Should Could Would) methodology.
In a project with constrained resource and budget the emphasis will be to deliver all of the Musts, and then focus in order on the Should haves, the Could haves and the Would like to haves. The benefit of using Agile is that you are much more likely to get more of the features at the lower priority end of the spectrum that if you were using a waterfall methodology.
The product owners do need to take responsibility though for communicating at each incremental release what is and isn’t included. It is human nature that the requirements that you have identified are more important than other people’s and the absence of someone’s pet requirement can be emotional.
However a project cannot be open ended and in general, unless budgets are unlimited, not all of the Would like to haves will be delivered.
,A great article on https://www.edureka.co/blog/devops-tutorial showing the plethora of tools required to make DevOps a reality, got us thinking about how much simpler it is for ServiceNow users using AutotestPro.
19 tools required VS just 2
ServiceNow's Automated Test Framework module (ATF) was introduced in the Istanbul version of ServiceNow as part of the platform.
Many people came to our stand at NowForum London confused as to the pros and cons of each tool and ask us to explain what the differences are. There are many many differences but the fundamental one and the easiest to explain quickly, is that ATF does automated testing, whereas AutotestPro enables full life-cycle DevOps automation, including automated testing (and from a business scenario/user story perspective).
There are many other differences between the two tools, for example the underlying technology used, but too many to go into in detail, in a short blog article such as this.
Still confused and need more guidance? Contact us and ask for our test automation experts to take you through all the differences in detail.
Absolutely not and this is the biggest misconception that people have with Agile. It is true that Agile promotes conversations and collaboration over documentation but documentation and, more specifically, traceability is key. The difference here is that the documentation is done using a completely different approach to the traditional cycle of requirements capture, high level design, low level design and user documentation.
One of the key principles in Agile is using user stories which are direct pointers to a conversation.
So when you hear people say "no documentation" it is an interpretation of a different process. With an Agile approach you don't spend a lot of time writing design documentation and getting sign off from the business. Your requirements are all defined as acceptance criteria (AC) in user stories agreed at the time with the product owner.
A key principle here therefore is to make sure that user stories up to date with any decisions made and there is an audit trail to those decisions and decision makers. It is a challenge to try and track down a change or what a feature should be doing if the Acceptance Criteria is not kept up-to-date.
This is another area where ServiceNow excels. Use the system that you are developing to track the user stories being implemented.
To release features you still need user guides and manuals and any configuration that needs to be recorded centrally. So as a definition of done for a delivered feature it should always include a guide or manual. Herein lies a challenge in keeping those guides up to date.
The approach we have taken is to create the user guides as the testing is being done. Automation is key here, if the testing is automated then generating automated user guides is a logical step forward so that the user guide is automatically fully in line with the currently released version. This is one of the first features that we developed because we saw the link between Agile development and the need for constantly updated user guides, this is something very few people do successfully.
AutotestPro kicks off NowForum London by announcing that Paul Cash, co-founder of Partners in IT and former Managing Director of Fruition Partners UK, is joining AutotestPro on the next stage of their journey.
Paul Cash said "I'm delighted and excited to be involved with Autotestpro as a strategic advisor. Over the past two years the company has developed an innovative and powerful framework to enable Automated Testing and DevOps within the ServiceNow platform."
Paul Chorley, Managing Director of AutotestPro said, "We are are absolutely delighted to have someone of Paul's caliber join the team. His experience and knowledge of the ServiceNow market will be invaluable in helping us help more ServiceNow customers transform their use of ServiceNow with our solution."
Agile software development is not new, the principles have been around for many years but changes in the platforms being used and the need for quicker return on investment means that it has become core to the deployment of services in many businesses. There are however challenges that implementing an Agile approach has, some of which are about understanding the business requirements as much as the challenges that innovative working practices provide.
Over the next 10 weeks we will publish common questions about Agile/SCRUM and our expert Agile expert Lesley Dempsey, Technical Design Authority at AutotestPro, will provide answers and insights on each.
What is Agile?
There are multiple methodologies that can be used to implement Agile but there are some key priciples that come from the overall approach. The following is from commonly available sources.
Individuals and Interactions more than processes and tools - Self-organisation and motivation are important. It is better to have a good team of developers who communicate and collaborate well, rather than a team of experts each operating in isolation. Communication is a fundamental concept.
Working Software more than comprehensive documentation - Working software is more useful than presenting documents to clients in meetings. It is better to comment the code and to keep external documentation light, rather than heavy documents that take a lot of effort and quickly become outdated.
Customer Collaboration more than contract negotiation - Requirements cannot be fully collected at the beginning of the software development cycle, so it is better to directly involve customers and users so that detailed requirements can be progressively elaborated and adapted based on feedback.
Responding to Change more than following a plan - Agile software development methods are focused on quick responses to change and continuous development.
Question 1 - What is the biggest challenge of using Agile with ServiceNow development?
There isn’t one related to development!
ServiceNow is an ideal platform to develop using an Agile methodology , the way that ServiceNow is architected makes it the perfect approach.
Specifically that way that ServiceNow uses update sets to deploy functionality means that it is easier and has greater accountability to deploy to staging and live environments with full roll back facilities if anything needs to be backed out.
If there are challenges that exist then these are around embracing Agile and automation. In our experience many companies are restricted by having the confidence to roll out the features and updates at the end of sprints. Some of this comes from the inability to test the system in a quick efficient manner.
If you can automate more of the stages of the Agile lifecycle then the features will be rolled out quicker. In this specific context we have considered automated testing as a core step. Testing takes a lot of time, especially regression testing, and it should be aligned with the requirements that are originally collected.
More and more customers are telling us they want to shift testing left. I’ve just come off a chat session from our website where we had just this conversation with a consultant working for a large ServiceNow partner.
‘The problem’, he said, ‘is that the tests can only really be created AFTER the functionality has been created’.
Our chat agent response...
‘Yes that is normally the case, but not with our AutotestPro. We are big advocates of TDD and ATDD, so the business scenario can be created in advance, in the form user actions that are flagged as 'new requirements'. When these user actions are flagged as such, they even automatically create development tasks. Once these development tasks have been completed, the developer turns of the 'new requirement' flag and it becomes an actual test which can be run automatically in the test engine’.
Shift left testing is only achievable if you have a solution which allows you to effectively define ‘requirements’ as ‘future tests’. Test Driven Development (TDD) is not new, but solutions which enable this are few and far between.
Even rarer are solutions which combine TDD with Continuous Integration Testing and Continuous Delivery (CI/CD).
Everything we do at AutotestPro, is driven by the desire to see the delighted expressions on our customers faces, when we show them how we automate the impossible in ServiceNow.
For the second year running, AutotestPro are proud sponsors of NowForum London on the 12th October 2017 at Excel in London, UK.
Last year we were incredibly busy at the stand all day and the event team resorted to dismantling stands around us while we were still giving demos at 6pm! So apologies in advance if we are busy again this year when you visit our stand. Please enjoy a Lindt chocolate while you wait and one of our team will speak to you as soon as we possibly can.
We have a bigger team to man the stand this year and they all love talking to ServiceNow users learning about the challenges you have and how we might help you.
We look forward to seeing you there at this fantastic ServiceNow event.