WHY ISN’T YOUR DATA TRANSFORMATION PROGRAM TRANSFORMING ANYTHING?

It’s a familiar tale — you’ve embarked on a journey to transform the way your company uses data, but all you have to show for it is a lot of very ambitious documentation and hundreds of progress update meetings where time feels like it’s standing still.

Why isn’t your in-progress data transformation program producing tangible results? Here are three common reasons why your efforts might be failing to deliver:

1. Your approach isn’t incremental.

We recently wrote about data maturity models and how they can actually hinder data transformation if you don’t apply them correctly. To summarize, organizations tend to focus too much on the brass ring (reaching some proverbial data maturity nirvana) and not enough on the details (getting more value from data along the way).

Often, the goal is a total overhaul of how data is used from the top to bottom of the business, delivering unimaginable value to everyone, everywhere — an ambitious transformation that will take years to achieve. Even if you’ve had a few updates and helpful process changes along the way, most of the value remains locked behind the “project completion” door.

What does that mean for those who are trying to get some incremental improvement and use data more effectively in the near term? It means they have to just sit tight and wait for the big reveal — otherwise, they’ll be doing work that’s not aligned with the broader strategy.

It’s important to consider the folks in your organization who use data to complete everyday tasks, and how you can make their jobs easier, not harder, during the data transformation process.

2. Technical debt is handcuffing you.

Individual innovation can be a huge asset for an organization. You want people to take initiative, solve problems, and make it happen. But when it comes to managing data, all that individual problem solving can add up to huge technical debt, and make organization-wide data transformation efforts feel insurmountable.

When everyone has their own unique, siloed quick fixes and band-aid solutions, there’s no more unifying structure left to transform — so where do you even start? Think of the chaos you’d unleash by pulling at even one loose thread; mission-critical systems that were crudely patched together would come tumbling down.

As an additional challenge, there will always be responsibilities and processes that can’t be switched off while things are fine tuned. For example, if you’re using your existing data systems to calculate monthly commissions, that presents a huge barrier to making any meaningful changes — you can’t stop paying out commissions until changes are implemented, and it would be risky to just cross your fingers and hope that brand new systems produce accurate results in time for you to cut checks.

Getting out from under technical debt isn’t impossible — it just requires a lot of effort. It’s also infinitely easier to achieve with the right combination of planning, skill, and resources, which is why many companies partner with firms that specialize in tackling technical debt.

It’s also important to remember that tech debt isn’t something you can escape completely, but a challenge that needs to be continually addressed. Good solution design assumes that today’s new solution is tomorrow’s tech debt, everything is eventually deprecated, and all solutions incur maintenance and upkeep. Finding the balance between standardization and innovation is important, as too much of either can be stifling.

3. You don’t have the right people.

Pulling off a successful data transformation project takes a lot of skill sets (strategic planning, project management, change management, ETL development, data science, etc.), and it’s highly unlikely that you’re going to find a single person who can do them all well. It’s also unrealistic to expect your current staff to sustain day-to-day operations and magically find the time to make changes. In 99% of cases, you’ll need outside help.

Trying to build an in-house team is difficult, especially in the midst of a data analytics talent shortage. Planning and recruiting for a team can take anywhere from six months to a year, plus the time it takes to get everyone up and running. If your organizational culture (or even just a particular decision maker) is change-resistant, this process can take even longer — and feel like pulling teeth.

Technical leaders often have to spend a large amount of time jockeying for resources and pitching projects. You may have to argue and advocate for three months to hire one person that was needed to solve a problem three months ago. By the time you get a decision, you’re going through the same cycle with a different problem.

It’s easy to see how years can go by with little to no progress.

This is another situation where it can be helpful to work with a data transformation partner, which gives you access to highly skilled, experienced people, without the pressure or long timeline of trying to build an in-house team.

Conclusion

Our general advice for data transformation can be summed up in two words: don’t wait. Every day you remain stalled out, you acquire more technical debt, and your problems get more complex. You lose more business, you gain less on your competition, and your company loses value.

If you need to see real outcomes from a data transformation project, focus on incremental improvements, and find a partner who can help you overcome the challenges we’ve outlined here.

Above all, remember that data transformation isn’t a “project” that begins and ends. It’s a decision to become a data-oriented organization — and it takes continuous effort and agility.

Not seeing results from your data transformation initiatives? Discover how to improve your data infrastructure and decision making during our upcoming Data Maturity workshop on December 15th at 11:30am Pacific Time.

A QUICK AND DIRTY GUIDE
TO DATA MATURITY

You’re probably familiar with the concept of data maturity — a measurement of how well an organization uses its data — and the maturity models that go along with it.

Understanding your current level of data maturity is the first step toward improving it. But the way you interpret and apply data maturity models might actually be hindering your success.

It’s tempting to look at a maturity model as a straightforward tiered system — your organization exists in one category, and your goal is to move up to the most mature category. But particularly for larger organizations, things aren’t so clear-cut. It’s common for different departments or business units to be at different maturity levels. Additionally, too many organizations get caught up in the long-term goal of data maturity and miss out on opportunities to create value at every maturity level.

In this article, we’ll go over the four categories we use to assess data maturity, give examples of challenges that arise in each category, and offer recommendations for driving more value at that level.

Before we get started, here’s a summary of each category for context:

Note: As you consider where you fall, it’s important to be realistic — think about where you are right now, not where you hope to be after completing a particular project. It’s also helpful to remember that it’s rare for an entire organization to exist within a single category. In most cases, different departments and teams will have different maturity levels.

Siloed

What it looks like:
Point-in-time data is manually exported from various applications and pulled into spreadsheets on an ad hoc basis. Team members compile and analyze data in their own individual workspaces (e.g. a spreadsheet only you have access to, or a platform that’s only used by one particular team).

Finding data requires some exploration — team members are not always sure where to look or who to ask for the data they need. They often end up emailing or asking around until they find someone who has what they’re looking for.

Example of a challenge:
You’re planning to hire people for a new team, and want to use a data-driven recruiting approach. You need access to key data about past recruiting efforts, like cost per hire, time to fill, recruiting yield ratios, and first-year attrition, so you send an email to HR requesting the information. HR then needs to take the time to locate and compile the data into a spreadsheet and send it to you.

Because you don’t have immediate access to the data you need, the recruiting process is already slowed down, and it will take longer to get your new team filled.

How to drive more value:
The importance of business process management can’t be overstated. For a process that will undoubtedly need to be repeated in the future (like looking at recruiting data), it’s important to start out with a deep, thorough understanding of the process itself. The first step to creating a repeatable environment is understanding what you want to repeat and why — then you can work on implementing more efficient processes.

Standardized

What it looks like:
Your organization has standard, scheduled operational reporting. You don’t have to go on an expedition every time you need data, because you know that you can find it in the most recent report (however, you’re still manually pulling data from that report). Even if you’re creating useful insights, they tend to stay with you — they’re not shared with other teams or business units.

Example of a challenge:
Each week, everyone in your department receives an email with an automated report that covers POS data. Most of the time, you don’t find anything in the report that’s actionable for you, so you sometimes don’t even open it.

When you do read it, you have to comb through tons of data to find anything relevant and manually extract it, which is time-consuming and inefficient. You complete analyses that are important to you within your own workspace, and the results aren’t usually shared outside of your immediate department.

How to drive more value:
Once you know where to find your data, determine what makes it actionable and relevant — and who needs to see it. As a starting point, ask yourself the following questions:

Enterprised

What it looks like:
When a particular threshold that’s relevant to your job is met, you automatically receive the relevant information. Rather than getting a standardized report that may or may not contain information you care about, you get notified only when there is data pertinent to a decision you need to make or action you need to take — whether that data is related to a budget milestone, warehouse stock, page views, or something else.

Sources of data are aggregated, so when you need insights, you don’t have to manually combine and analyze data. However, the reporting is still fundamentally historical and often comes too late to help you make informed decisions.

Example of a challenge:
You’re responsible for mapping out an upcoming seasonal campaign and need sales data to inform your plan. Each week, you receive an automatic report containing data that helps you shape the campaign, but you have no way of looking forward in time — you’re stuck with a decision-making process that is reactive, not proactive.

How to drive more value:
With the right timing, data can be leveraged to achieve better outcomes (and predict possible future outcomes). Don’t just think about what data you need and where to find it — think about when it will have the biggest impact on decision-making, and how it can help you course correct before things get off track.

Actualized

What it looks like:
Your data is set up to model and predict future outcomes, perhaps using AI tools like predictive analytics and decision algorithms. Analysts and data scientists are an integral part of the business vision, and insights are created by the company (not requested by specific business leaders).

For many companies in this realm, the data model is inextricably linked with the product or service they provide. For example, platforms like Netflix and Spotify are rooted in predictive data analytics and the ability to make personalized recommendations to customers.

Very few companies reach this level of data maturity — and the reality is, not every company needs to. It takes continuous investment to maintain an Actualized data system and depending on the products and/or services you provide, it might not deliver enough ROI to justify spending the resources and effort.

Example of a challenge:
Your organization is experiencing a slight decrease in customer retention. You already have access to real-time data and analytics that help you understand the problem, but you want to leverage that data in new ways in order to make more informed decisions.

How to drive more value:
Being an Actualized organization doesn’t mean you’ve crossed the data maturity finish line — in fact, there is no finish line.

Only the most advanced companies make it to this level, which means competition is stiff. And considering the incredibly fast pace of data technology, companies that don’t continuously innovate will be left behind.

At this stage, optimization is key. Consider how data can better drive decisions and open up new opportunities for your organization. In the case of the challenge above, building new algorithms for churn models could help guide decision-making and reveal more actionable data.

Conclusion

Identifying your current data maturity level and setting goals for improvement is all well and good, but without taking steps to get more value from your data at your current level, your long-term progress may stall out.

Rather than thinking of data maturity models as rigid paths with set destinations, use them as way-finding tools. Once you understand where you are, you can move forward — no matter what “forward” looks like for your organization.

Regardless of your maturity level, we can help you get more value from your data. Discover how to improve your data infrastructure and decision-making with our Data Maturity Assessment.

SURVEYING THE DATA LANDSCAPE IN 2022

In the past, data wasn’t necessarily important to every person within a company. It was used primarily by analysts, accountants, and other specialists.

But in 2022, companies are learning that becoming a data-driven organization means incorporating data into every aspect of their business — from talent management to customer engagement and beyond — and continuously optimizing how they use data with new innovations and process improvements.

What does being data-driven look like in action? Here’s an example: a west coast retail automotive company employing over 7,000 people across 9 states came to us with the goal of implementing a mixture of data science and machine learning to identify, implement, and improve safety, employee satisfaction, customer satisfaction, and profit margin. The client asked us to work with multiple teams within manufacturing, HR, marketing, and technology innovation to build out the desired capability.

To help this company reach their goals, we provided high-level strategic insight for new initiatives, built out proof of concepts, made recommendations for innovative methodologies, designed machine learning algorithms, helped them redefine company-wide KPIs, and trained their staff on new processes.

As a result, executives are better able to make key strategic decisions and further company goals based on data-driven insights, and the entire organization’s data literacy has improved.

A shifting mindset

A few years ago, the goal for many companies was “fixing” their data processes (a reactive way of looking at data management), with a focus that was often confined to specific departments. In 2022, most organizations are approaching data management differently. They’re aiming to be far more proactive — and to stay competitive, they have to be.

It’s less about simply “cleaning up” messy data, and more about creating meaningful, long-lasting, company-wide change that will continue to drive value and inform decision making in the future. In other words, it’s all about becoming data driven across the board.

Here’s an infographic that breaks down this change in mindset and some common challenges that are forcing companies to rethink the way they approach data:

Approaching data reactively and in silos is a way of the past. To keep up with the intense pace of change, constant innovation, and evolving customer expectations in 2022, a proactive, holistic, organization-wide strategy is required.

This change is positive on multiple levels. It’s not just good for staying competitive — it’s also a way to ensure that each of the common challenges described above (talent optimization, business insights, technical debt, etc.) get addressed so you can reap the benefits of becoming a data-driven organization.

That said, embarking on a large data transformation project can sometimes feel impossible, especially if you can’t promise ROI until months (or years) down the road. At The Gunter Group, we believe in taking a different, more iterative approach that enables organizations to realize immediate value while still keeping their larger goals — and the overall data landscape — in mind.

Ready to reframe the way your organization thinks about data? Talk to the experts at The Gunter Group.

What is tech debt?

Technical debt is often defined as the cost incurred when you repeatedly choose short-term solutions rather than doing the (larger, more expensive) work of tackling the big-picture causes of your problems.

But let’s look at the issue through a different lens: what is the nature of technical debt?

Because new solutions are built and deployed every day, all organizations incur tech debt, to some degree, with every system and process implementation decision they make. Even if you implement a new, innovative solution today, there will be a better one available tomorrow. In this scenario, you will still incur tech debt — just less than an organization that makes no updates.

Too many organizations think of tech debt as a problem that can be permanently solved. In reality, it’s a constant that’s renewed continuously by change and growth, and trying to “solve” it completely is a futile pursuit.

While you can’t make tech debt vanish into thin air, you can certainly make it more manageable. If you focus on managing its impacts in an ongoing way, you can deflate its looming, monstrous reputation and get to work on making meaningful improvements in the here and now.

Is tech debt destroying your data-driven dreams?

Analytics bottlenecks are a common issue related to tech debt. Silos slow down the analytics process; if only one person knows where a spreadsheet is and how to extract meaningful data from it, they become the bottleneck.

With each short-term fix and siloed process, data becomes harder to manage, access, and analyze. In turn, drawing insights from that data requires more time and effort, the insights become less timely and less reliable, and informed decision making becomes more challenging.

In other words, tech debt has a way of draining value from data — and the longer you let that debt accrue, the more value you’re losing. Using a prioritized approach to managing tech debt can help you cover more ground right out of the gate, so you don’t lose any more value than you have to.

One way to apply this prioritized approach is with backlog grooming, the periodic process of reviewing and prioritizing backlog tasks (and removing unnecessary or outdated tasks).

How do you prioritize what areas to address?

There is a lot of information available on how to tackle tech debt. Unfortunately, most of it is theoretical. While the abstract stuff can be valuable, if you’re looking for a practical way forward, you need to bring your considerations back down to earth and fold in the business perspective to create a technical debt prioritization plan.

You probably have a lot of tools at your disposal, internally and externally, and resources to leverage. Take a look at what you need to have happen — not theoretically (e.g. eliminating all technical debt by some point in the future) — but actually.

For example, The Gunter Group recently worked with a retail automotive company that was struggling with data debt. It was impacting every area of their business, including employee satisfaction, customer satisfaction, and profit margin. They needed a new approach, but with such a vast problem, it was difficult for them to know where to start.

We worked with multiple teams within the company, including manufacturing, HR, marketing, and technology innovation to create a prioritization plan. High priority initiatives included redefining company-wide KPIs, designing and implementing machine learning algorithms, and improving data literacy across departments.

Though they still have a long way to go on their data maturity journey, this company was able to start making changes where it mattered most, rather than remaining paralyzed by the challenge ahead.

How we work with clients to tackle tech debt

Remediating data-related tech debt requires far more than just technical skills — it requires asking the right questions, gaining a holistic understanding of your organization’s business goals (as well as how they may vary across different departments), and creating a dialogue to explore possible solutions.

Each of these components requires a tremendous amount of time, which internal teams rarely have. In most cases, managing ongoing operational struggles takes priority over transformation, and team members don’t have the capacity to focus all their energy on addressing tech debt. Meanwhile, recruiting new team members is a time-consuming, resource-intensive process, and thanks to the tech talent shortage, it’s more challenging than ever.

Turning to outside help can get the data transformation ball rolling without overwhelming internal teams or opening a can of recruitment worms.

At The Gunter Group, we leverage a multidisciplinary approach (technology, people, strategy, and execution) that enables us to see the long-term big picture while solving the highest-priority problems in the short term.

Combined with our extensive technical capabilities, this approach allows our clients to chip away at their technical debt and reclaim the value of their data as quickly as possible — without the burden of hiring a new team.

Conclusion

Think about a meaningful, specific problem you’re facing right now that’s rooted in technical debt, and what you would be able to accomplish if this problem was being managed proactively.

If you set your sights on eliminating tech debt across your entire organization, you’ll likely get caught up in a complex tangle of issues — and that one major problem that’s holding you back now will still be holding you back in six months.

To accelerate your progress, identify your most pressing issues, and reach out to expert help if you need it. With the right strategy and the right partner, you can mitigate tech debt and use your data to its fullest potential.

Is technical debt slowing you down? Discover how to improve your data infrastructure and decision making with workshops hosted by The Gunter Group.

REAL WORK. REAL RESULTS.
PRAGMATIC AGILE IN PRACTICE

We recently published a series of articles on the topic of pragmatic Agile and how its approach and methods can impact organizations of all sizes. As a way to highlight pragmatic Agile in real life practice, we wanted to provide an example of how one of our consultants utilized pragmatic Agile while supporting a client.

Senior Consultant Rob Anteau, has been working with Agile and waterfall teams for decades. Even before joining TGG, he developed a similar perspective to the implementation of Agile. Below is a recent example of an impactful Agile adoption Rob oversaw at one of our clients.

Rob was a project manager leading an effort to modernize a software platform used by the client. The project was sponsored by “traditional IT” and many leaders dismissed Agile concepts in their initial plans, nor was that even part of their culture. Rob challenged this. 

First, Rob left the Agile vocab and dogma at the door. The company culture wasn’t hospitable to the new terminology, so he didn’t push it. Rob started with a two week time-box with a planning session. The team got on board, finding freedom in the admission that they didn’t know everything at the beginning of the project. 

Next, Rob introduced a retrospective, tailored specifically to his team. He framed it as a chance for the team to learn from their mistakes and to capitalize on strengths. He led by example, demonstrating what active engagement looked like. 

This all required some heavy lifting on Rob’s part. He still had to create the 650 line project plan, and constantly translated the iterative work of his team into a report for leadership. He served as a lead blocker, allowing his team to iterate while he kept management informed. In the end, all parties were happy with the new setup.

Rob knew that elements of Agile would be helpful for his team, and understood he didn’t need to get there in one day. He took his time, gradually introducing elements and demonstrating their value. He didn’t need to act like the smartest guy in the room; rather, through servant leadership he demonstrated and cultivated the Agile mindset. As a result, his team experienced a mindset-shift, finding comfort in the idea that their work didn’t need to be perfect to be valuable. They came to see “good enough for now” as, well… good. 

This was pragmatic Agile in practice. Whether our clients need support for a wholesale digital Agile transformation or just a little help along the way, we’re excited to partner with them to meet their goals.

More about Rob Anteau:
Rob is a technical program leader who is adept at developing and executing programs utilizing agile and waterfall methodologies across multiple industries, from healthcare to the public sector. With a background in IT infrastructure, cloud migrations, network operations, and cyber security projects, Rob uses his technical expertise and business acumen to bring stakeholders together to ensure quality and timely delivery. He places importance on communication and being adaptable to a variety of environments. Understanding that there is no one-size-fits-all solution in technology, Rob is committed to delivering a final product that is aligned with client objectives. Rob holds a B.A. in Industrial and Organizational Psychology from Vrije Universiteit as well as the following certifications; SAFe 5 Agilist, Scrum Master, ITIL, ISTQB, Prince2, Six Sigma Green Belt, and TMap. Rob is a fan of the maker movement and in particular enjoys electronics projects. His other passion is anything VW related; he owns a 1978 Westfalia.

TECHNOLOGY PRACTICE Q&A WITH MATT JAMISON

At The Gunter Group we categorize our work into four practice areas: Technology, Execution, People, and Strategy, with client engagements often stretching across multiple service categories.

Our Technology Practice focuses on understanding clients’ technology needs and challenges, and crafting pragmatic action plans.

In this Q&A we explore our Technology Practice in greater detail with Matt Jamison, Principal Consultant and Technology Practice Service Leader.

Tell us a little bit about the nature of work TGG focuses on within the Technology Practice:

Our Technology service line stands out in that it’s an extension of our management and business consulting work. We’re always engaging with our clients from a business lens, utilizing processes and people, and adding a technical depth and expertise to our client partnerships.

What is the most rewarding aspect of supporting clients in TGG’s Technology Practice?

Meeting our clients where they are, understanding their needs and challenges, and crafting a pragmatic action plan. This means evaluating their tech stack, teams, and asking, “What can we do in the next 6 weeks and 6 months?” With this approach we can start helping and start delivering value right away and not just toward a project’s end.

Tell us about a recent engagement supporting a client initiative:

A national education services provider planned and started a digital transformation initiative. We helped them step back and assess their readiness to execute their digital transformation strategy. Additionally, our team made a series of digital program structure and agile product delivery recommendations that we are helping drive forward.  

What are recent trends you see impacting organizations in the Technology space?

COVID has substantially increased consumer expectation for a robust digital experience for many companies. People are much more willing to engage in a digital experience now because it became a reality during the pandemic. And this aligns perfectly with our Technology Service offering. Consumers are demanding a great digital experience and we’re able to help because that transformation is built from everything TGG does.

What do you anticipate impacting businesses over the next 3-5 years in this area?

Expectations of digital experiences are going to be high. Whoever is doing this experience well right now, will likely be doing it well in 3-5 years. Ones that aren’t doing this well or didn’t do it in the past, might not be here in 3-5 years and expanding and creating a digital experience is expensive. Instead of buying property for storefronts, you’re investing in technology costs and data centers — and this will be just as true in the future as it is now.

Tell us about one of your favorite projects your team has worked on:

A global athletic wear company started their digital transformation back in the mid-2000s mostly focused on North America. Now we’re helping expand their global footprint because they sell so many products outside of the United States. This leads to interesting questions to answer, involving how to make technology scalable and reliable. It’s even more interesting because we can use prior learnings to inform new strategic ideas.

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect and a Certified SAFe 5 Agilist. Outside of work, Matt enjoys the outdoors and all things bike-related.

WHAT IS AGILE ENTERPRISE ARCHITECTURE?
(AND WHY SHOULD YOU CARE)

In light of the work and results we have delivered to our clients over the past year, today we are introducing a new blog series focused on the impact of successful and strategic Enterprise Architecture.

Being successful in the current business landscape demands agility, a deep focus on customer value, and the ability to build and deliver adaptive strategies. 

If you haven’t considered the way these trends are affecting enterprise architecture (EA), you’re already behind. 

In this article, we’ll explore a new paradigm: agile enterprise architecture. But before we explain the value of this approach, it’s critical to get on the same page about a few core concepts. 

What is enterprise architecture?

Essentially, enterprise architecture is the practice of understanding and documenting components of an enterprise — and the relationships between these components — in order to improve strategic planning and decision making. 

The practice of enterprise architecture encompasses discovery (what does the enterprise have now and what will they need in the future?), design (what’s the best way for the enterprise to achieve its goals?), implementation (how do we put this plan into action?), and documentation (how do we synthesize this information in a useful way?). 

Enterprise architecture is usually focused on information technology and the relationship between IT and business goals. One major goal of EA is to reduce technology debt, a term used to describe the ongoing costs associated with hastily chosen IT solutions (as opposed to those considered in the context of a long-term plan). 

What is agile?

The agile methodology is an approach to the development of products or systems that emphasizes adaptation, evolution, and flexibility. 

The first use of the agile methodology was in software development. However, the spirit of agile — as described in The Agile Manifesto — can be applied to many different practice areas, including enterprise architecture. Frameworks like SAFe® provide guidance for applying these principles to different parts of the business. 

To boil it down to one key element, an agile approach values responding to change over following a plan, delivering incremental value throughout the entire improvement process. In other words, it is an iterative, ride-along approach rather than a prescriptive, point-in-time approach. Value is created along the journey, instead of being solely located at some distant destination. 

The trouble with traditional enterprise architecture

What does EA look like in reality?

Most often, enterprise architecture is the responsibility of one individual or a small team within an organization, or an additional role added to the many on an already overburdened leader. They conduct point-in-time exercises and apply EA “best practices,” which are typically academic in nature rather than drawn from contextualized real-world experience. 

The outcome of these exercises is usually a monolithic document that’s difficult to apply to day-to-day decision making. This document purports to “solve” the enterprise’s technology problems, but too often ignores the fact that every solution has a lifecycle, and that the usefulness of solutions changes over time. 

Because traditional enterprise architecture plans don’t flex and adapt, the technology solutions proposed by the EA team tend to become disconnected from the strategic pulse of the business. These legacy approaches structurally ignore the fact that what you know now is almost invariably going to be significantly different than what you’ll know later on. 

As a result, despite being expected to own the long-term technology strategy for the enterprise, EA teams often slide down the slippery slope towards being perennial meeting floaters, sitting on the sidelines of decisions rather than contributing real value.

What is agile enterprise architecture?

Agile enterprise architecture is a new approach to EA developed by The Gunter Group. Agile EA applies the principles of the agile methodology to enterprise architecture in order to improve business outcomes.

Agile EA focuses on iteration and continuous improvement. In this approach, the job of an enterprise architect is not just to deliver a roadmap — it’s to ride along with the roadmap, continuously closing the gap between the plan and reality as it unfolds. 

In addition, a major goal of agile EA is to create a set of architectural patterns that help define business problems and orchestrate their solutions. Agile EA decenters specific technology recommendations in favor of methods and frameworks for finding the right solution in any situation. 

To put it another way, an agile enterprise architect understands that “owning” the long-term technology plan for an organization is not a sustainable responsibility. Instead, agile EA focuses on enabling internal teams to generate their own solutions to complex problems in alignment with broader strategic goals. 

Agile EA dispenses with outdated and ineffective elements of traditional enterprise architecture practices. Whereas traditional EA is academic, agile EA is pragmatic. Whereas traditional EA is prescriptive, agile EA is adaptive. Whereas traditional EA often becomes decoupled from business strategy, agile EA is solely focused on the ways technology enables business outcomes. 

Ultimately, successfully practicing agile enterprise architecture ensures the organization has the technology runway it needs to achieve its strategic goals. 

Enterprise architecture as a service (EAaaS)

One manifestation of agile enterprise architecture is enterprise architecture as a service (EAaaS). As opposed to project-based consultants who are rarely around long enough to see the execution of their proposed roadmaps, EAaaS provides ongoing support in a scalable subscription format. 

EAaaS can augment or transform in-house EA teams. There are several advantages to this approach, including:

Through enterprise architecture as a service, The Gunter Group has the ability to transform an ineffective, impractical enterprise architecture function into an agile driver of positive change. 

A new era in enterprise architecture

We believe that agile enterprise architecture — which is best realized through EAaaS — represents a dramatic improvement over the status quo. 

More than that, however, we view the shift to this approach as a necessary component of a successful enterprise. 

The old models and best practices of enterprise architecture were developed in a different era. They were not built to handle the strain of the rapid growth and change made necessary by the pace of and competition in the modern landscape.

However, by treating your EA capability as a strategic enabler rather than a tactical function, you will unlock business agility, customer value, and long-term success. 

Agility is the hallmark of today’s most successful businesses — and you simply cannot have an agile enterprise without agile enterprise architecture. 

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

THREE KEYS TO SUCCESSFUL ENTERPRISE ARCHITECTURE IMPLEMENTATION

Over the last year we have supported clients spanning a variety of industries. Some of our most impactful client engagements have been in the area of Enterprise Architecture.  

As a way to further support our clients, we hosted a special Idea Exchange focused solely on the process of transforming Enterprise Architecture and increasing value to organizations with a more agile approach.

In that Idea Exchange we discussed three keys to improving Enterprise Architecture:

1. The quality of Enterprise Architecture should be determined by the outcome it enables.

Successful outcomes result from leadership teams and stakeholders clearly aligning upfront on the problem or opportunity. Identifying the desired outcome can be supported through an upfront planning process which asks questions such as:

2. Evolving roadmaps = useful roadmaps.

An agile enterprise architect can leverage the “perfect” roadmap as inspiration to identify a good solution which enables short-term benefits and sets the business up to realize the perfect solution.

For example, a five-year roadmap that started two years ago is not valid anymore and COVID-19 is a dramatic example as to why. 

Additionally, new technology and capabilities that can help your business operate more effectively will come to market, which were not part of your original roadmap. For this reason, it is important to regularly review and update roadmaps incrementally.

3. Changing direction is an essential activity.

Agile methodology is not only about making it okay to change direction, it is about encouraging and supporting this behavior. Identify your “North Star” but recognize over time the path to your “North Star” will change. 

A critical part of the agile mindset in Enterprise Architecture is that it can be preferable to have assumptions, even if some of the assumptions prove to be wrong as progress and developments are made.

Institutional acceptance of this creates the healthiest, most productive, most agile Enterprise Architecture process. The team should be inspired and supported to change direction when it makes sense and explore preto-typing and interim testing as part of their evolving problem solving processes.  

In closing we have been inspired and motivated by the proliferation and maturation of agile practices in recent years. Unfortunately, Enterprise Architecture has lagged behind in its own progression and application. While some see this misalignment and move on, we see it as an opportunity to help organizations effectively transform their architectural activities and support clients in an effort to successfully drive innovation across their technology ecosystem.

AGILE & THE BATTLE FOR BETTER BUSINESS

Agile is a solved problem, in the tech world. In software development environments, it’s now a staple. You would struggle to find a single development team or technology project that isn’t using an agile framework to plan and execute their work. The idea has long passed from experimental to adoption; it has saturated the market.

Little proof is needed for this claim of complete saturation. Just look at the list of certification-ready agile methods: SAFe, Scrum, Crystal, DSDM, Feature-Driven Dev, ASD, Lean Software Dev, Disciplined Agile, RAD. Beyond the certifications you’ll find (often decades old) schools of thought around Wagile, eXtreme Programming, and others. When you can certify yourself in a handful of different frameworks around the same concept, then it’s safe to say that the school of thought is here to stay.

Outside of tech, though, the potential of agile is still largely unrealized. Waterfall methodology is still the dominant approach to project and product management. At the Gunter Group, we feel this is a missed opportunity. The practice and benefits of agile should no longer be the sole domain of nerds. 

The Coming Revolution

Agile has revolutionized development, or rather, agile is the response to development’s demand for revolution. Waterfall was the child of the uniquely meandering progress of early software projects. Early development borrowed from manufacturing, aerospace, and defense methodologies of the time, and depended on long runways for delivery (and even occasionally relied on physical manufacturing processes).

However, as software leapt forward, the waterfall methods of old failed to serve the split-second pivots required by the go-to-market environment of modern technology. Software development demanded a new kind of organization, one as iterative and quickly-changing as the 1’s and 0’s upon which it was built. From this need, agile was born.

It is a mistake, however, to limit agile to the tech environs of its birth. There is nothing about agile that is necessarily specific to software development. We repeat: there is nothing about agile that is specific to software development. It is a framework that has application well beyond its homeland.

A renaissance is before us. Agile has yet to have as meteoric an effect on the broader business world as it has in all-things-tech, but this change is on the horizon. In this article, we will explore several simple means for the application of agile in non-tech environments.

This article is for agile practitioners. It is also for anyone else who works in a world of projects and output-oriented teams. That means everyone. Yes, you read that right: everyone. (Even construction has room for agile. There are certainly limits to the application, as failing fast in that landscape could be catastrophic. Construction is a mature industry with many unique frameworks for success, but the concepts of agile are still applicable in creative ways. Design iteration, proposing and awarding subcontractors, and daily standups with subs might be areas for immediate agile-inspired growth).

Tried and true in the tech-focused backbone of our ever-changing world, the revolution of iterative, cross-functional, self-forming teams will ripple through organizations and markets of all kinds. The thoughts below are intended to give you a leg-up in this revolution, to find yourself ahead of the curve in the battle for better business.

The Business Cycle & Agile: An On-Again, Off-Again Relationship

Agile has a place in the business cycle, but only one place. The picture below illustrates this (a notable exception to this limitation can be found in the SAFe framework, which has made progress in utilizing agile in a broader business context). Agile is often embraced by a development team or manufacturing process, but everything upstream and downstream from these teams still think of their work in terms of waterfall. As the landmark book The Lean Startup explains in detail, this often results in products reaching the market after months or years of investment without validation that the product is even needed.

This can be fixed. At TGG, we have seen successes and failures with clients attempting to embrace agile methods. There is no one right or wrong way to embrace agile, but we have seen some general activities or mindsets prevail over others.

Below is a list of high-level considerations you should keep in mind if you are interested in adopting agile in your non-tech team:

Don’t Do Agile for Agile’s Sake: It can be easy for a leader to say, “It works for the Unicorns so it should work for us.” As a result, agile or lean Centers of Excellence sprout up in organizations that are not ready or willing to embrace these methods. Agile only works when a team understands why they are doing it and are engaged in the method in a way that adds value. It is all about developing business agility and driving value to the customer—not just about “doing” agile.  

Find the WHY (Value Added): People are more willing to change when they understand why a particular change will benefit them. This is universally true, and is a fundamental concept that drives all successful change efforts. When accompanying a team that is new to agile, break the component parts down into WHYs that demonstrate the value added by an agile element. More on this below.

Use a Light Touch: For teams that have been thinking in terms of waterfall timelines and years-long delivery plans, agile is not intuitive. This is even harder for teams that don’t operate in a project environment, such as operations, finance, or HR. It is uncomfortable for someone new to agile to imagine releasing their work before it is “completely done.” For these people, adopting agile represents a culture change. Use a light touch, and embrace change management best practices. Educate on the value of embracing agile ceremonies and artifacts (see Point #2), and give them time to adjust to a new work culture.

Think About Slicing Small: You might think that the key difference between waterfall and agile is the speed of the work. However, this doesn’t quite capture the power of agile methods. Agile teams don’t work faster—they work smaller. Sprints are only successful when a team can break their work into smaller chunks that can be accomplished, reviewed, and delivered to customers in a matter of weeks. When looking to adopt agile in your non-tech team, this can be one of the hardest yet most rewarding mindsets to shift. Ask yourself the question: “What can we complete this month and deliver to our consumers?” 

Start with Standups and Retrospectives: When in doubt, the easiest place to start with agile adoption is with standups and retrospectives. Gather your team together so everyone can give a 30 second status update and share any blockers. Encourage recognitions, because they actually do boost engagement. Periodically bring everyone together to reflect on the way they work, and encourage them to think creatively about small changes they can make to boost productivity or morale. These rituals are baked into agile systems but are often overlooked in the recipes of other structures. They are ceremonies that are simple to implement (their WHYs are easy to understand), and they immediately add value to your team.

Find the WHY: Representing the Value Added by Elements of Agile

In tech, it is easy to take agile for granted. There is little need to investigate why that is the case. Dev teams embrace the frameworks without the need to justify why. Tech simply trusts the efficacy of the model.

Non-tech environments are more skeptical, however. Business units accept the place of agile in their organization’s tech division, because the quality and turnaround of their tech solutions are desirable outcomes. But a chasm exists, an us versus them void between tech and business, in which each realm agrees to the ways of the other without cross-pollination. “Agile works for IT,” says the non-IT department, “but we will carry on as we always have.” 

When making the crossover from tech to non-tech, asking WHY is essential. When making the case for an agile adoption in a non-tech environment, it is not enough to know THAT agile works; you also have to understand WHY it works. 

The core concept of this article is this: by breaking down the framework into a series of WHYs, you are able to build a business case for its adoption.

In Search of WHY

Before diving into case studies, we’ll pause to give a couple brief examples of how to find WHYs. First, we’ll give an example of finding a WHY, and then we’ll observe an organization that has used this WHY thinking approach to maximize the benefit of agile enterprise-wide.

We’ll start with an example of a WHY. Any agilist knows of two basic roles that tend to show up in any agile framework: the Scrum Master and the Product Owner. But why are these roles so valuable? In short, they capture a tension that exists in every project: throughput versus quality. 

The Product Owner represents the customer. He or she is ultimately accountable for the product that hits the market. They massage the backlog, prioritize features, and vouch for the throughput and objectives of the customer. The Scrum Master, on the other hand, is a servant to the team. He or she is responsible for maximizing the value of the team’s work by removing impediments and maintaining focus. 

In every project, there is a tension between speed and quality, and often these elements are at odds. Teams have to choose between the speed or quality of their throughput. The roles of the Product Owner and Scrum Master capture this tension, striking a balance that delivers a timely, quality product. 

Here’s the WHY: agile purposefully creates this tension. The Product Owner advocates for the deliverable; the Scrum Master advocates for the team. There is no consensus without dissent, and the dissent built into the agile framework ensures a consensus between the competing demands of immediacy and quality. 

You’ll notice, in this example, that the WHY is subtle. It simply looks at two roles and understands the purpose for each of them, both individually and together. But their purpose, the WHY, is powerful. Maintaining the tension between throughput and quality ensures that an agile team continuously delivers a product that is valuable. 

There are many examples of organizations finding the WHYs, but a fantastic example can be found in the way Spotify approaches an agile culture. Spotify, a tech company, started from the assumption that agile adds value. But they also embraced a key mindset: rules are a good start, but let’s break them when needed. This led Spotify to match its needs (autonomous squads, short term goals, and an enterprise-wide holistic product strategy) to the WHYs of agile (throughput vs quality, flexibility, consistency, autonomy, alignment) to create a truly unique structure of tribes, squads, chapters, and guilds.

These unique, overlapping structures don’t conform to any particular agile method, but point to the WHYs of agile as necessary predecessors. The result: a nimble organization and healthy culture that keeps pace with the ruthless, fast-paced competition of streaming music solutions.

Agile in Business: Case Studies

So far, we have discussed the concept of embracing agile elements in non-tech teams. Let’s look at a few examples of this concept in action.

The Lean Startup – Laundry Services in India

A current popular expression of these concepts can be found in the book, The Lean Startup by Eric Ries. Over the course of 300 pages, Ries walks the reader through a home-grown approach to agile adoption grounded in decades of direct and indirect (consulting) experience with entrepreneurs and startups.

Core principles of The Lean Startup include small slicing vision into minimum prototypes, testing those prototypes early and often, validating assumptions, and promoting a culture of constant adaptation and growth. These agile-adjacent methods are all implemented without any of the typical agile ceremonies or artifacts.

There are dozens of case studies in the book that demonstrate the WHYs in action. One example comes from a laundry service launched in India: Village Laundry Service (VLS). In 2009, VLS was poised to launch a low-cost modest-return laundry service in a virtually untapped market in India.

The company, however, paused to create small-scale experiments to validate product assumptions and zero-in on specific customer needs. They embraced a model of iterative testing and adaptation that allowed them to target a rollout that was specifically tailored to customer needs. This meant that, once scaled, VLS was sure that they were mass-producing a product that customers would actually buy.

National Insurance Provider – Accounting Team “Scrum”

An insurance provider engaged us to assist with an ERP implementation that would replace the general ledger that accounted for tens of billions of dollars in managed assets and revenues. In the organization, there was a Lean Center of Excellence that had been advocating for agile ceremonies across the organization for several years. However, the accounting department had not yet adopted any of these elements. Early in the project, the team decided to organize themselves into a scrum team, with all the usual ceremonies and artifacts.

Initially, the transition was difficult. The team consisted of financial analysts and operations managers, and no one had project experience (let alone a knowledge of scrum). The “scrum team” was also larger than recommended, with more than 15 people.

Over time, the team used the ceremonies to break down their activities into a series of WHYs. Daily standups helped illuminate blockers and inefficiencies, and sprint retrospectives allowed the team to reflect on what was working and what wasn’t. Before long, the team developed a rhythm to their work and were able to break out the scope into smaller slices that more efficiently made use of their resources. Additionally, they were able to quickly track and validate decisions made about the product, which allowed for quicker pivots that better met the needs of their internal stakeholders.

HR Job Posting – Introducing Small-Slicing to Recruiting

On November 20, 2019, TGG’s Tech Services Lead Matt Jamison presented to AgilePDX on the topic of adopting agile elements in non-development teams. To illustrate his ideas, he shared an example of applying agile to talent acquisition in an HR department, with regard to staffing practices. 

The Problem Statement: the struggle to find and hire talented resources presents a series of constant hurdles. Even without complications, it is difficult to sort through the tides of resumes to find individuals who have the professional and cultural acumen needed for a particular situation. 

But hiring does not occur in a vacuum, and complicating factors abound. Hiring teams struggle to match job postings to the continuously changing needs of their organization. Market factors like shifting regulations, emerging fields, and competitive innovation require constant adaptation to who or what an organization needs on their teams. On top of this, the company mission is regularly transitioning due to adaptations from corporate strategy and new products. 

When hiring for a team, there is a need for agility. Despite this, overworked recruiters are often incapable of the continuous change that would empower them to hire better, faster, and smarter. Poll HR professionals and you will likely hear the same thing, “I’m not getting the right talent. It takes too long to get talent. How do I assess the growth of employees and allow for advancement? I don’t respond quickly enough to changes in my organization and market.”

Enter the Agile WHYs: how would an HR team look to agile to address some of their struggles? Start with the problems: 

– There is too much to change and not enough time to adapt
– Changes in job descriptions require a lengthy approval process

Looking at these problems, several agile WHYs start to jump out in response:

– Vertical slicing deliverables into bite-sized stories
– Sprint structure allows for near-term pivots on vertical slices
– Empowering team members to problem solve allows for quicker creative solutions
– Iteration on pain points or strengths allows for continuous improvement

An HR team embracing these WHYs wouldn’t have to embrace a full scrum adoption to realize their benefit. They could small-slice a job description, looking at components of a specific description instead of the whole thing. They could explore ways that recruiters could update parts of job descriptions in a quicker manner without needing full bureaucratic and legal review involved with a new job post. They could collect user stories from teams with upcoming resourcing needs instead of a list of qualifications and specific experience, empowering recruiters to be more creative in finding the right fit. 

By embracing the WHYs of agile, teams can borrow the best parts of the methods and ceremonies to foster agility. And by doing so, they are living up to the core principles of agile, putting individuals and interactions before processes and tools.

We want to close this paper by reiterating a key point that is foundational to adopting agile in new environments: don’t do agile for agile’s sake. If either managers or direct reports fail to understand the reason why they are making a change, then that change is destined to fail. Do not embrace agile just because it’s trending in high-dollar markets. 

There are good reasons for the successful outcomes of agile—a successful adoption requires an understanding of these reasons first. After witnessing successes and failures in the market around us, we firmly believe that a team must understand the WHYs of embracing agile methods before jumping in. 

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

More about Josh Bathon:
Josh is a creative problem solver with experience in project management and process improvement. Josh thrives in situations that challenge him to learn quickly and adapt to new environments. Leveraging his unique background in seminary formation, Josh brings emotional intelligence and self-knowledge to his interactions to build lasting, goal-oriented relationships. Josh has experience in healthcare IT, primary education administration, and non-profit service, environments in which he has developed a team-oriented leadership style geared toward high-performance outcomes. Josh holds a Bachelors in Philosophy and History from the University of Notre Dame. When he’s not working, Josh loves to read fiction and philosophy, as well as explore the cuisine and quirks of the Portland Area with his wife.

TGG STORY PUBLISHED IN OREGON BUSINESS MAGAZINE

After being named the #4 Best Company to Work For in Oregon (medium business category), Oregon Business connected with us to publish an article highlighting The Gunter Group’s story.

We were excited to share our holistic, Non-Negotiables approach to client delivery with Oregon Business and to be highlighted in their magazine alongside the other 2020 winners on the ‘100 Best Companies to Work for in Oregon’ list. Congratulations to all these awesome organizations! Read the full story at OregonBusiness.Com to learn more.