Nigel Mossman an Agile Practitioner, Delivery Manager, Coach and Trainer who has been accredited by APMG International to run AgilePM and AgileDS training.  He is the  Lead Trainer  with IndigoBlue (Mastek UK Ltd) who are an APMG Accredited Training Organisation (ATO).

What is it?

An agile method targeted at those who are building Digital Services (or anything else for that matter) driven by data and a user centric approach to meeting the business outcome.

The government created it’s agile digital standard some years ago (detailed here: https://www.gov.uk/service-manual/agile-delivery).  During 2017 the Agile Business Consortium (previously the DSDM Consortium) started work on turning this into a generic Agile qualification in partnership with APMG.   AgileDS is not a straight lift and shift; a review of the material on the GDS website shows subtle but important differences between the AgileDS qualification and the GDS guides; some of these are highlighted in this article.

APMG will be known to many as the providers of courseware and exams for PRINCE2 –since 2014 for AgilePM the current DSDM version.  APMG offer a wide range of exams and courseware in business and technology areas, including DevOps.

AgileDS will be launched in the Autumn of 2018 (once the current public beta is completed) as an Agile Digital Services Standard for private and public sector organisations in the UK and internationally.  (Around 50% of AgilePM exams are taken by professionals outside the UK).

Is this the end of AgilePM/DSDM?

No – AgilePM/DSDM continues.  AgileDS is a new product aimed at a different market sector.

Who’s it for then?

Clearly public sector (including “not for profit”) organisations looking to Agile methods to improve the service to their clients.   While many of us have been practising Agile for many years (over 15 in my case), many of those in the public sector have little or no experience of Agile methods which highlights the need for the AgileDS standard and this course.

Scope in the private sector is less clear.  Where an organisation rejects SAFe because it is too complex and AgilePM/DSDM or Prince Agile  because they are too “old school” and pure Scrum because it is to simplistic, then AgileDS may well find a niche.

Organisations running “Digital Projects”  and finding that their existing Agile method is falling sort may find value in this method.  It could be argued that AgilePM might fit the bill, but it’s not targeted at the digital market nor does it start by considering the needs of intended users or data about user interactions.

Overview

The GDS material forms the core of AgileDS, however, it has been extended to include elements of AgilePM, SCRUM (a lot) and a little bit of SAFe (ironic as SAFe  pinches and reworks material from a variety of sources) and incorporates DevOps practices.

While, in theory, you could use AgileDS to build all manner of tech solutions, the method has been optimised for the digital world.  More than creating a web or e-ecommerce solution, it is about driving a whole service line/offering via digital systems.

Principles

AgileDS is underpinned by a set of principles, to misquote Groucho Marks “These are my principles, and if you don’t like them… choose another method”.

• Start with needs – Good service design starts with identifying user needs. Without a clear understanding of user needs it is unlikely that the right solution will be delivered.
• Do less – This is the standard Agile approach of promoting code reuse, only building for known requirements (but without inhibiting potential future work), optimising working practices etc. As the Agile Manifesto says “Simplicity—the art of maximizing the amount of work not done—is essential”.
• Design with data – Gather data and learn from real-world behaviour by looking at how existing services are used and letting this data drive decision-making is  preferable to guessing.
• Do the hard work to make it simple – The aim is to produce a simple, well-designed service that meets the needs of its users. The handbook suggests that this principle supports ending resistance to change because ‘It’s always been that way’.
• Then iterate again- Essentially incremental delivery.
• This is for everyone – Everything that is built should be as inclusive, legible and readable as possible
• Understand context – Good, effective services are built around people and how they
• use them.
• Build digital services, not websites – A service is more than web site, it’s about delivering an end to experience, for example – if you sell a car you can use a single DVLA website to inform the DVLA about the new owner and claim back any Road Fund Tax you are entitled to receive; clearly a website and set of web services and API’s are have been constructed to achieve this. No need to send the V5 back in the post.
• Be consistent, not uniform – Services should have a consistent design but not at the expense of innovation, responding to change or varying a service where certain aspects would work better if a different approach were employed.
• Make things open: it makes things better – Promote technical knowledge, share code, share experiences (including failures) so that all teams in the initiative being undertaken can learn. This principle encapsulates transparency but also requires management to create a safe and supportive environment for team.

Lifecycle

The lifecycle consists of 5 distinct phases:

• Discovery – understand who the users are, what the need is and technical options.  The project can be stopped for a variety of reasons including finding out that there is insufficient need or that there are no viable technical options.   Similar in scope (but longer at 4 to 8 weeks) than the Feasibility Phase in an AgilePM project.
• Alpha – Build a series of prototypes to show that the service is viable from a business and technical prospective, ideally by building prototype solutions that real people can use and learning can be gained from.  This forms the foundation of the Beta Phase where most of the development will take place.
• Beta – Splits into two phases, private and public. A project may use one or both.  A private beta restricts involvement to invited users but offers the advantage of being able to act quickly in response to feedback.  Public Beta makes the service available to all users and implies a level of maturity  to the service being developed.  In the GDS standard, entry to a Private Beta is granted after a Service Assessment has taken place, however, this is not referred to in the AgileDS material.
• Live – When no additional significant features remain the Service can enter the Live Phase.  The live phase retains a team to continue enhancing the service to reflect changing needs (the needs of users are continually researched and KPI’s for the service are constantly reviewed).
• Service Retirement. In digital world a service can be overtaken by market changes very quickly.  The Service Retirement phase determines how users needs will be met as the service is closed (this could be via migration to a new replacement service).

Strong Emphasis on User Research and Accessibility

At the core of the AgileDS framework is User Research.  The aim is to findout who the users are, when and where they want to transact and in the Discovery Phase how they are doing it (or not) today.  User Research continues through out the project and involves the whole team so that everybody understands the language and issues faced by users of the service.

Digital Services need to be accessible to all users; the needs of disabled users of a service must be considered from the start of the project and throughout the lifecycle and given the appropriate level of priority.

Requirements and Prioritisation

The AgileDS framework makes use of Stories and there is nothing new or different included.

However, AgileDs does suggest several prioritisation techniques that teams can use, including MoSCoW, Kano Method and Weighted Shortest Job First (WSJF).

WSJF has been lifted from SAFe although the AgileDS manual doesn’t provide much information on this.  The Kano Method categories requirements (e.g. Excitement, Performance) into a two-dimensional axis (“Satisfaction” and “Execution”).  This seems a complex technique for requirement categorisation; in my view it would be used alongside another prioritisation technique.  The method does feature in the exams so is one that APMG expect people to take up.

Roles

Roles within a Service Delivery Team are modelled on a set of themes.  An individual may hold a role that covers one theme or multiple themes.     Where multiple related services are being constructed an individual may contribute to multiple teams in the same or different themes.  As with AgilePM, the key is taking a pragmatic view of what makes sense over the Lifecyle of a project.  For example, in the Discovery phase which will have a small number of people involved somebody may have responsibilities in the Product Management and Business Analysis themes.

The themes for a  Service Delivery Team (governed by a steering and leadership function and supported by professionals providing specialists guidance) are:

• Service Ownership – Broadly has overall responsibility for the development of the service; there are similarities with the AgilePM Business Visionary Role.
• Delivery Management – as the name suggests
• Product Management – the GDS vanilla material suggests that a person covering this role has overall responsibility for backlog prioritisation, however, in AgileDS the role is restricted to the needs of internal users of the Service with overall prioritisation being a collaborative process led by the Delivery Manager.
• Business Analysis – as the name suggests.
• User Research – this theme is solely about understanding the needs of users. The actual user experience (i.e. enablement) forms part of the Service Design theme.
• Service Development – as implied the technical work associated with building the service.
• Technical Design – In AgilePM this would be the Technical Co-ordinator role.
• Service Assurance – essentially ensuring the service is fit for purpose. Persons engaged in this theme would cover traditional QA activities as well ensuring that the service meets internal and external standards.  Performance of the service is implied; however, the AgileDS handbook suggests that performance analysis would be covered by specialists (as part of Specialist Guidance referred to earlier).
• Service Design – Responsible for designing an engaging service via current and emergent technologies.
• Service Deployment – Responsible for deploying and managing the service in Operation, this includes DevOps if this is being practiced.

AgileDS groups roles into a themes with each theme having a set of responsibilities.  A team member may cover several themes in a project or may (where there are dependencies between Service Delivery Teams) take the same theme in another team.  This is seen as one way in which dependences between teams can be managed.

Scaling Up

AgileDS gives some basic guidance on scaling the core team as the project moves over the lifecycle.  In general teams are commended to be 7 +/- 2 and there is expectation that multiple teams might be needed to support a single project but little guidance is offered.

The method does set out a role for change co-ordination  (where multiple projects should be regarded as one larger initiative) a long with scaled up Service Ownership, Technical and Change Management leadership.

As with AgilePM,  a Business Sponsor role is included.  The  Business Sponsor is accountable for the Business Case and project budget, they need to be senior enough in the organisation to be able to make or bring parties together to quickly make decisions.

Planning

The two main planning products in AgileDS are the Roadmap and Delivery Plan.  The Roadmap is a visual representation of the direction and vision for the service over time.  The Delivery Plan is (which is in addition to the vanilla GDS standard) shows the planned activity for each sprint.

AgileDS recommends setting these out for the whole project (or subset of it) for a sensible timeline where as the GDS standard suggests a period of 6-12 months.

Sprint planning is per standard SCRUM, and interestingly this is the only firm planning horizon mandated in the AgileDS handbook.   AgilePM trainers will be pleased to learn that  Structured Timeboxes do not appear in this method.

Plans also need to include how/when Benefit Assessments will  be undertaken.   While AgileDS gives little guidance on how or when this should take place it is expected that all projects will, in the early part of project, determine what KPI’s might be captured to show how well the service is meeting the needs of its users and it’s operational performance.

AgileDS Products

AgilePM defines 14 products (including the solution being built).  AgileDS defines just 9, and none of these are the Solution being built!  Across the industry, “product” is a heavily overloaded term;  the handbook uses the term interchangeably between deployable deliverables and supporting artefacts.  Products in this context refer to a collection of supporting artefacts to help the Service Delivery Team manage the project and critically support their work,  openness and transparency.  The products are:

• Terms of Reference. A summary of the top-level business drivers, sufficient to justify the project being setup and starting the Discovery Phase.
• Business Case – First completed at the end of the Discovery Phase and concluded by the end of the Alpha phase to allow fully development to commence.
• Backlog – As per Scrum.
• Roadmap – Already discussed.
• Service Architecture Definition. A straight lift from AgilePM – This covers both business and technical aspects of the solution.
• Development Approach Definition – Another lift from AgilePM. This product describes the tools, practices etc that the Service Delivery Team will use to build the Service.  However, it also describes how Quality be assured.
• Management Approach Definition – Also lifted from AgilePM, this product describes how the project will be managed – how it will be planned and organised, how stakeholders will be engaged etc.
• Delivery Plan – described previously.
• Service Lifecycle Transition Report. At the point where a service is transitioned to live, describes the work delivered (and what has not been delivered), the benefits that are expected to accrue from this release, a double check that all of the necessary activities to release and make the service operational have been performed and any findings from a retrospective on delivery.    The wording seems to have been lifted from AgilePM’s Project Review Report; on that basis this product should be completed at any point in the lifecycle where a deployment is made to live operation.

Governance

AgileDS includes an explicit section on Governance,  a brief summary of how initiatives (projects) could be grouped where they complement each other but limits it’s self to summarising he GDS principles.  These are:

• Don’t slow down delivery
• Decisions when they’re needed, at the right level
• Do it with the right people
• Go see for yourself
• Only do it if it adds value
• Trust and verify

The last principle – “Trust and Verify” refers to those with Governance responsibilities trusting and empowering teams to do the work  while taking steps to verify that the information they are receiving is correct and that the project is as reported to them.  Clearly this must be achieved   without creating “command and control” regime as this would go against the “Making things open” principle.  Those with governance could enact trust and verify by via, “Go see for yourself” – e.g. attending end of sprint showcases and other opportunities to interact with the team as part of the natural sequence of daily work.

Scrum

As mentioned, Scrum forms the core of the work in Alpha, Beta and Live phases.  This is pretty much standard Scrum, although there are some subtle differences:

• AgileDS recommends a team size of 7+/-2, where as Scrum recommends teams sized between 3 and 9 persons.
• Standups are recommend to be 15 mins long with AgileDS suggesting a variation in format depending on size of team.
• In SCRUM the PO is ultimately responsible for accepting the completed work (the Business Ambassador would do this in AgilePM). The Product Manager accepts work in AgileDS, but given that the method only mandates their responsibility for internal users, it is ambiguous to as to who accepts work on behalf of external uses of the service.

MVP and MMP

Making full use of iterative development and incremental delivery, AgileDS recommends the use of MVP and MMP.   An MVP is defined as Minimal Viable Product but in a Digital Services setting several MVP’s can be combined to create a Minimal Marketable Product (MMP).  MVP’s are expected to do something of value; several may be needed as a project learns (pivots or preserves against it’s original strategy).  Their use is primarily in the Alpha and early Beta Phases to learn more about the solution space by getting feedback from real users.  The definition and delivery of the MMP is the point where real business value (outcomes) might be achieved.

Note: When using MoSCoW, the user Minimal Useable SubseT (MUST) is retained; making three terms to describe a minimal useable unit of delivery.  This might be OK when applying MoSCoW at the sprint level as away of defining the stories that must be completed in the Sprint.

Estimating

As in AgilePM, estimating is expected to be less certain at the start (e.g. during Discovery Phase) and early day estimating is expected so support the development of the business case and general viability of the project.  By the end of Alpha, a team may have a high level of confidence in their estimates and may be able to provide an accurate cost for the whole project.  If not, then estimates should be made to the next release and the project reviewed at that point.  The implication being that a project could be stopped if the likely cost exceeds the expected business benefit.

Quality

AgileDS expects quality planning to take place during Discovery and Alpha phases with execution predominately in the Beta and Live Phases.  Quality is considered from both the process and technical quality with much of the material reused from the AgilePM handbook (in a more succinct form).

The Definition of Done is recommended for use, when combined with the other management products lifted from AgilePM a powerful but lightweight set of documents can be established that will help teams manage process (i.e. ISO/internal Audit) and solution quality.

AgileDS outlines a set of generic testing concepts (largely taken from  AgilePM), including TDD, Integrated, Repeatable and Independent testing (nobody signs off their own work).  In addition, the Definition of Done makes an appearance as a recommended artefact.

DevOps

Forming part of the Service Deployment Theme, DevOps is given some specific responsibilities, ideally while embedded into the Service Delivery Team:

• Running the production systems (including deployment, automation, maintenance and troubleshooting)
• Helping the development team to build software that is easy to use from the perspective of technical operations
• Working with developers to optimise existing applications and to design new ones
• Encouraging everyone in the team to think about how new applications will be run and maintained
• Optimising existing applications
• Designing new applications

Conclusion

Having reviewed the content (and passed the exams to be allowed to run the course!) the AgileDS standard hints at too many areas without providing detail on practice.   Experienced Agile Practitioners will be able to adapt the method to a project or organisational setting.  Those attending a course will leave knowing what they should do in a digital context and being able to understand where their existing process are different; without a coach or agile practitioner to support them it is highly unlikely that they would be able to implement the method.    In contrast with AgilePM or SAFe, a person leaving a course and reviewing the supporting material could make at credible attempt at implementation.

One of the things that is missing in AgileDS and is found is SAFe is the emphasis on flow, i.e. optimising the whole development process to cut out waste which is ironic given the “Do Less” principle.

From a wider Agile prospective, what is new and useful is the emphasis on user research and data driven decisions, plus a simplified and incremental delivery framework (Discovery, Alpha, Beta, Live is a simple enough concept).   From a CIO prospective, the method is used  by government and there  are number of successful implementations making this a viable choice if other methods aren’t acceptable.

Would I build a project using this method – Yes – in the right project setting this method will help drive value.  More generically, does it help senior managers (and those implementing a solution) understand how Agile could work in a Digital Setting – Yes.

More information on exams and certification:

https://apmg-international.com/product/agileds

AgileDS® is a registered trademark of Agile Business Consortium Limited. All rights reserved.