Agile Digital Transformations

Don't want to read the whole article, just CLICK HERE to book your certification now!

So what is Agile Digital Services and how does it relate to you?

As the name implies this is aimed at anyone or any organisation that is providing a “digital service” – this is beyond websites, just to be clear right up front.

Many agile methods have made it into the private sector or corporate world quickly, however, the areas such as public or government sectors have struggled with this adoption. The cause of this has been a stop / start approach and a low level of adoption. Until that is, the UK government created something called the GDS or Government Digital Services, which effectively created a standard for agility within the government. It turned out to be quite good actually, so much so that APMG International along with Agile Business Consortium have turned this into a new certification.

So what? I’m in finance, we’re agile, do I need this?

In many organisations, to the uninformed, and there are many, the word agile is easily confused with SCRUM and SAFe? and in the more mature organisations they generally also have a flavour of AgilePM?, which is also an APMG certification, created by DSDM.

AgileDS? actually enhances all these and pulls them together in an easier and lighter way but still provides solid grounding auditability and control. Auditability and control is something which finance houses are beginning to realise, thanks to the Royal Commission in Australia, is actually quite critical even when delivering in agile ways.

Quick give me the executive overview of AgileDS?

AgileDS? is really guided by a core set of principles and thinking. It’s seems pretty simple to read, so read it aloud! The real journey is being able to take up the words and turn them into your daily actions and interactions with others.

Guided by Principles – and aligned to the original Agile Manifesto of course !

No 1: Start with needs – that means what the USER needs for a change

No 2: Do less – huh! I thought we were going to be more productive, well yes but we need to focus on getting there by minimising waste. That means, smart reuse of information, code and other resources

No 3: Design with data: this means start with research, not someone’s idea of what the data might look like, but actual data

No 4: Do the hard work to make it simple – this is a tough one, no one likes to work hard, we all like to produce lots of output showing just exactly how hard we’re all working, but this one relates to hard being that of simplifying the difficult stuff up front so that it’s easier to build on and create excellent outcomes

No 5: Iterate. Then iterate again – yes this is agile, means we don’t build a cathedral, we start with a few tents, then some huts, then a barn or two and we’ll get to the cathedral eventually, if there’s still value in getting there, it may diminish over time

No 6: This is for everyone – services need to be inclusive, that means it’s available to the all the right age groups in an appropriate way. So if it’s a service that needs to be used for ages 10 to 90, then it needs to be setup in such a way that they can all use it. This doesn’t mean a flashy new app or website, consider your grandmother sitting in her beach house, would she be able to use the app? What about someone with disabilities, like vision or hearing? We did say inclusive!

No 7: Understand the context - services are built around people. Currently mostly ogranisation build services around systems and tools. Let’s think about this for a second, you’ve designed the perfect app, but part of your user base doesn’t have access to the internet at the same bandwidth you have or worse they’re in need of doing this transaction via the phone!

No 8: Build digital services, NOT websites – exactly what it says on the box – you need a service that speaks to the real world and I’m afraid not all the real world stare into websites all day

No 9: Be consistent, not uniform – if you’re adding to an existing universe of services, don’t introduce a whole to new way of working and a glossary of terms that needs a training manual. Go back to principle No 1, do your research

No 10: Make things open: it makes things better – sharing is good, it’s smart and you get better outcomes much quicker that you could imagine

AgileDS? uses these across the lifecycle of digital delivery – here’s how

There are 5 phases, but I like to add an additional one to emphasise the point of this way of working. It’s not that I’ve invented one, and it’s clearly stated, but I see it as so critical that it must be called out.

My starting point on AgileDS? – User needs.

Then we have, Discovery, Alpha, Beta Private, Beta Public, Live phase and finally Service Retirement

Interestingly enough, it’s always the first and last phases that organisations really battle with getting done well. And I mean [User Needs, the research] followed closely by Discovery, skip a few and then Service Retirement. We’re not great at getting something new started and when it’s in full flight we’re not great at stopping it all and shutting it down.

What I like about AgileDS? is that these are critical items in the lifecycle that need to be dealt with in a sensible fashion.

What else does AgileDS? bring?

Key items that often don’t get explored and adopted deeply enough in many organisations.

Accessibility – which frankly is good User Research. The point of this task is to understand who it is that your creation is serving. Instead of providing a service in a way that works for you and your team exclusively. The point that this research is making is this: the user needs to determine how best your creation looks, and then you figure out how best to meet that need with what you have at your disposal.

Requirements, Estimation and Prioritisation – several courses on their own actually, but they’re incorporated into the thinking here which is an excellent start and it’s not all covered in real serious detail within the course, but it doesn’t need to be. The point I’m making, is that it’s been highlighted at all levels to have visibility across. Unlike some of the previous APMG courses in this portfolio, AgileDS? doesn’t only focus on MoSCoW, but also raises methods such as Kano, WSJF [Weighted Shortest Job First, which has been leveraged out of the SAFe? method]. AgileDS? doesn’t cover WSJF in depth, but then it doesn’t profess to make you a SAFe? expert either [attend the SAFe? course is what it implies], it does provide enough coverage for you to understand how these might be used. For example the Kano Method introduces the two dimensions of Satisfaction and Execution and explains how to plot your observations across the five distinct categories of, Excitement, Performance, Basic, Indifferent and Reverse against these two dimensions visually. This is a nice simple way to work and appeals to many business folk.

That brings me to governance and roles. Without adequate governance structures in place with clear enough roles, it’ll all fall apart anyway. By this I intend to mean any organisation, not just an AgileDS? one.

Clearly ensuing that you have these boundaries setup and agreed, even at a small scale is critical.

Having clear roles and governance in place ensures that planning and control are dealt with effectively. One of the big grievances or misconceptions from organisations that have attempted digital delivery, and failed, is down to some notions that control and planning are a lessor important item. Without clear guidance on governance, most deliveries will eventually end up in a less than effect outcome and this applies to digital & agility too!

Let’s pause for a minute and look at the roles and responsibilities. AgileDS? immediately talks about the Individual and Collective Responsibility. It brings some reasonable reality into the situation, why? Because it specifically mentions that sometimes responsibilities are shared by two or more people. This is a great leap from the implied message that some of the other courses and methods deliver, almost leaving one with a sense of “there can only be one of X who is the responsible one…”

AgileDS? themes these responsibilities into nice groupings such as: Delivery Management, Service Ownership, Product Management, Business Analysis, Service Development, User Research, Technical Design, Service Assurance, Service Deployment & Service Design. In other words, real ITIL? aligned and corporate or government style groups through their description.

The AgileDS? engagement model calls for continuous, open and honest communication daily and the availability of the progress of the work to be transparent at all times.

AgileDS? talks to scale

AgileDS? attempts to also provide some guidance on scaling agile within an organisation. Now I need to point out that many agile methods claim to be able to scale and many agilists out there claim to know how to scale agile. But here’s the thing, it’s very very difficult to make it work effectively. It requires almost monumental effort to get the right support from senior leadership to set the tone in a large organisation. It is even harder to make it stick because leaders move often. It’s also tough when you’re dealing with many coaches and scrum masters and other agile folk who all feel they have found a way to true enlightenment. The message becomes confusing sometimes.

Why have I added that paragraph? Well, what AgileDS? provides is some basic guidance and sets up some thinking, but it doesn’t have “the plan to scale” all nicely laid out.

AgileDS? does do a few things however that I do like.

Calls out that “people” are at the heart of success

The people require 4 elements:

-         Empowerment

-         Stability

-         Skills

-         Size

That’s the magic right there, you get these right and then things will become simpler.

AgileDS? recommends that you manage these 4 elements through a risk management and resolution process. Which I personally think is excellent as it addresses and covers this through a) governance & b) transparency

AgileDS? makes special space for DevOps

Recognising the importance of DevOps in the digital delivery and agile world is crucial, I see AgileDS? as the next level of maturing organisations that embrace and understand the world of DevOps.

How else would your organisation be able to keep up the digital delivery and cloud works that are emerging around it and still be able to deliver effective services to your clients, who after all are the reason you exist!

AgileDS? planning!

How sensible is it that AgileDS? calls out the following with regards to planning.

“Planning to Sensible Horizons at the Right Level of Detail”

Then it goes on to show the two realities.

·        The roadmap & delivery plan which is effectively the top down planning

·        The Sprint planning which is the bottom up planning.

Many have heard me refer to the old way of planning as “Dark Room” planning, this is where some key folk, go into a dark room [well closed anyway] and emerge some time later with “the” plan. Then they wonder why execution tends to be a bit tricky, why? Because they did not include the right people in the planning session. AgileDS? very clearly calls out that you need to be inclusive and transparent for success with regards to planning, replanning and measuring progress.

Does that mean we just do MVP (Minimum Viable Product)?

No, AgileDS? very clearly uses the phases to do what completely should make sense to your ogranisation and users/customers. And that thing is the use of MVP (Minimum Viable Product) along with MMP (Minimum Marketable Product) – what a great way to ensure the stakeholders, digital developing teams and leaders in the organisation understand what it is that they’re targeting.

Using this method improves quality outcomes, allows for emerging information and learning which in turns delivers a great digital service experience to your customers.

Not templates, but products

AgileDS? in a similar way to AgilePM? also refers to a product set to capture and document your change. Many organisation have change frameworks and most of these refer to the outputs as templates. One might say that these are the same, but there is more behind a product than a template. It’s the intent the product carries and the method or interaction that is required to gather the information that populates the product that is actually more important almost than the product itself.

The product set is simple and yet effective.

a.      Terms of reference – top level business summary

b.      Business case – a more concise description outlining the need

c.      Backlog – as you would guess, a list of all the requirements

d.      Roadmap – the high level plan

e.      Service architecture definition – the solution in both business and tech

f.       Development approach definition – how this will be delivered

g.      Management approach definition – how it will be managed

h.      Delivery plan – again, it does what it says, how you will deliver this change

i.        Service lifecycle transition report – describes what you put into production

AgileDS? Governance

Nice and simple, but effective.

Also has principles which are great!

a.      Don’t slow down delivery

b.      Decision at the right level, when they need to made

c.      Governance with the right people

d.      Go and see for yourself [I totally support and think it is critical to do this!]

e.      Governance that actually adds value, not just for the sake of it

f.       Trust & Verify [guess what? You can’t learn to trust until you can verify, but not micromanagement!!]

AgileDS? refers to Scrum, quite a lot actually, so these governance principles will be easily applied to teams, if they are using Scrum, since it’s been designed that way.

Ending off...

AgileDS? works well for me based on my experience in the industry, it combines much thinking and assists with opening many avenues to smarter outcomes. I’ve sat the exams, been interviewed and asked many questions about this new certification and hence decided to try and summarise that here I this article.

What I think people are going to appreciate and like about this course is the way it brings it together for teams who are new to digital delivery and agility. This includes what I call business agility, but it makes allowances and real space for technical teams at the same time. And even more so your friendly PMO’s will like the way it works.

I recommend you check out further information about how to book on a course and get certified. CLICK HERE

Agile Digital Services – AgileDS?

AgileDS? and AgileDS? are trademarks and registered trademarks of the Agile Business Consortium Limited, APMG International and APM Group and swirls are trademarks and registered trademarks of the APMG International Group. FACT? is a registered ATO via APMG and is an Australian Registered and owned business ABN 65532230548

A brand new certification available in the Australia Market

Greg Collocott - Enterprise Business Agility Coach, Trainer, Event Speaker, Consultant and Student. Greg has been accredited by AMPG International to run AgileDS? and AgilePM? Training. His company FACT – Fast Agile Coaching Training is accredited by APMG International as an ATO – Accredited Training Organisation. Greg is the Lead Trainer at this organisation and works with other accredited trainers and ATO’s to produce the best value training on the market.