Pattern Domains

A big NO to frameworks and methodologies from me!

I am not a great fan of “frameworks” or “methodologies” I find they are often based on a fixed mindset and typically restrict the ability for data teams to iterate those methodologies to craft their own Way of Working.

But when coaching data teams on the patterns they can use to craft their own WOW, they often ask to see the “big picture” to see how it all hangs together.

Over the decade I have had multiple attempts at trying to create this big picture, and never really created anything that provided clarity, or more importantly something that I didn’t hate.

Part of this was because I was taking an “un-agile data” stance, I was trying to create one diagram to rule them all. And that resulted in too many moving parts, too many objects on the page, too many stories trying to be told at once.

It resulted in complexity not simplicity.

As I was drafting my first Agile Data Guide, the “Green Book” I got feedback that the content about the Information Product Canvas pattern template was great, but the guide needed to have a chapter that explained the context of where the Canvas fitted in the “big picture”.

I spent a large portion of the time it took me to draft that guide on breaking the big picture down into smaller chunks, and then writing simple content that described the context for each chunk.

And then of course I tried to put all those chunk together on one page again and show how they related, I succumbed yet again to complexity.

So after another set of iterations I have ended up with a small number of diagrams that describe in isolation the parts I think provide an overview and context for the core of the Agile Data Way of Working patterns and pattern templates.

As I find, iterate and publish patterns and patterns templates, I now map them to one or many of these diagrams, I map to see where they fit, or if I am still missing something that is important to the “Big Picture”

These diagrams are there not to provide the answer, because the answer always depends on the problems you want to solve, the context of both your data team and your organisation. You use these patterns to find your own answers.

These diagrams provide the context of the patterns and patterns templates in the Agile Data Way of Working.

I think of them as blueprints.

Crafted over two decades of experimentation and refinement, these resulting blueprints equip data teams with a set of patterns and pattern templates to tackle complexity, deliver value faster, reduce waste, and have more fun while doing their data work.

These pattern and pattern templates offer proven solutions to recurring challenges, creating a shared language and a practical toolkit for delivering valuable information products and data solutions.

The Agile Data Way of Working is not a rigid methodology, it’s an approach that empowers data teams to craft their own approach. Like a set of LEGO blocks, it invites them to identify, assemble, and adapt a way of working to suit their unique team and organisational context.

Every Agile Data patterns is designed with one goal in mind, to make data delivery not just faster and more effective, but also more engaging and rewarding for data teams and stakeholders alike.

The What

A Way of Working describes how data teams will collaborate and work together.

The Agile Data Way of Working adopts patterns from the AGILE, PRODUCT and DATA domains and applies them to the specific challenges data teams have when managing complex data in complex organisations.

Patterns is a widely used concept to describe good solutions to recurring problems using a common language.

Adopt the patterns that will work in your organisation and your teams context, ignore the ones that won’t.

Patterns and Pattern Domains

Patterns is a widely used concept to describe good solutions to recurring problems using a common language.

The Agile Data Way of Working takes proven patterns from multiple domains, adapts these patterns to the Data Domain, and applies them to address recurring data challenges using a shared language.

By leveraging patterns and practices from diverse domains, data teams can craft their own Way of Working which not only resolves common data issues but also enables them to collaborate and adapt to change faster. This cross-disciplinary approach allows data teams to continuously refine their processes, delivering value quicker while having more fun.

Patterns Templates

Pattern Templates are tangible output’s or artefacts created as a result of applying a pattern to a common problem.

Templates can be in the form of checklists, code snippets, design blueprints, templates, diagrams, or canvas such as the INFORMATION PRODUCT CANVAS.

Adopting a specific pattern to solve a common problem, may result in the completion of one or multiple pattern templates.

Information Value Stream

An Information Value Stream describes the repeatable steps data teams follow to get the data work done and deliver valuable Information Products to their stakeholders.

Starting from capturing a stakeholder’s problem, to identifying valuable and viable solutions, prioritising the data work to be done, to the collection of raw data, transforming it into actionable information, and ultimately delivering targeted outcomes and tangible value for the organisation.

Information Factory

An Information Factory is focused on automating as many steps of the Information Value Stream as practically possible, streamlining the process for efficiency and productivity.

Think of it as the equivalent of an automated manufacturing factory, but for data.

A modular data system simplifies the identification and resolution of data breakages, ensures the accurate application of data for its intended purpose, and provides the quick identification and access to critical elements such as calculated metrics.

An Information Factory automates the process of collecting raw data, manufacturing it into valuable information products, and delivering it to the customers who need it, removing the need for human involvement.