“[You] insist upon forcing a square peg into a round hole, because in a round hole you, being a round peg, feel tight and comfortable. Now I call that irrational.”

Edward Bulwer-Lytton, Kenelm Chillingly, His Adventures and Opinions

Agile is the new black. Or at least that’s what its proponents from the software development community proclaim. Since its introduction back in 2001, the Gospel of Agile has gradually moved with evangelistic fervor from engineering teams to other parts of organizations, all the way up to the C-suites of F ortune 500 companies. Beyond its merits, Agile is undoubtedly aided by its name – after all, who doesn’t want their organization to be associated with a word like “agile”? In fact, Agile has become so dominant in the industry that its critics can be looked down upon on social media as being the engineering equivalent of a “flat earther”.

On the surface, Agile would seem to be the ideal, forward-thinking set of principles and methodologies for digital transformation and web and mobile development engagements that we work on every day at Maark. However, based on our own experience and witnessing the experiences of others, I have grown to question that perspective. While I believe that certain aspects of Agile principles and methodologies can be highly beneficial in development projects that we undertake in the services business, a religious adherence to Agile is much like trying to fit the proverbial square peg into a round hole.

A Quest for the Silver Bullet

Agile was first introduced in the early 2000s as a modern response to the old school waterfall methodology. The waterfall approach, which has its origins in manufacturing and industrial engineering, was brought over to the world of software development during the early years of computer programming. A waterfall project has a series of sequential phases (requirements, design, development, testing, and delivery). Since a phase is dependent on what came before it, each phase must be completed before the next starts.

The primary benefits of waterfall are that the scope and timeframe are agreed to and known beforehand; it’s predictable, driven by a plan, and has built-in methods of accountability. However, the waterfall approach to software development has long been derided because of its inflexibility in dealing with changes, inevitable unknowns until the full product is built, and a tendency to sacrifice testing when time runs short.

Enter Agile. While the waterfall approach focuses on upfront planning and a strict adherence to that plan, Agile is all about flexibility and iteration. With Agile, a product evolves over time, and plans are constantly reevaluated to adapt to changing conditions. Priorities are set together on a collaborative cross-discipline team, and then implemented through small phases called sprints. A product using the waterfall approach will be releasable only at the very end of the project, but an Agile-driven product will be releasable at the end of each sprint.

The promises of Agile are alluring and seductive: adaptability, responsiveness, a launchable product at end of each sprint, and a transparent, collaborative environment in which business stakeholders and the development team work closely together to plan and prioritize. Fueled by such potential, Agile has ruled the roost for over 15 years. In fact, a whole cottage industry has developed around it: over 40 variants of Agile; consultants, books, and certification programs; and even new job titles. Terms like sprint, scrum, and user story have become a natural part of the vernacular for most any professional in the tech space.

However, in spite of the accolades, be careful not to think of Agile as a silver bullet and appropriate for all contexts. It’s not.

Something is Rotten in Denmark

As Agile spread in popularity in the 2000s, we at Maark began to incorporate Agile principles and practices into our teams and projects. We assigned scrum masters, created user stories in Jira, restructured projects into sprints, and even experimented with planning poker for time estimates. But, in project after project, its benefits proved elusive.

One might offer a critique and say that Agile didn’t work for us because we weren’t committed enough to its principles. Or perhaps we didn’t follow the methodology rigorously enough or implement the right variant of Agile. Sure, there were many ways in which we could have done Agile better. But, at the same time, I don’t believe any tweaks or changes to our approach would have had a significant impact on our results. Instead, I would argue that we uncovered a deeper, more fundamental problem: that there are almost intractable tensions between the principles and practices of Agile and the real world in which we operate.

First, Agile principles almost inevitably run counter to stakeholder expectations. When we engage a client for a particular software deliverable – whether it is an app or website – the client is chiefly concerned with two things: our ability to deliver the product vision, and the timeline and budget required to do so. The vision often evolves as we work with the stakeholders during the planning stages, but, at the end of the day, the stakeholders want to know where we are going to finish before the first line of actual code is written.

The reality is that much of the larger world outside of software development runs upon predefined plans and predictive results. And most stakeholders who inhabit that world naturally expect to structure engagements in a similar fashion. Therefore, trying to force Agile into this environment naively assumes others will (or even can) adjust to these values and methodologies.

Second, Agile priorities often clash with the priorities of the stakeholder. One of the primary tenants of Agile is to empower teams and create a learning organization. As such, misdirections or deadends are considered not so much failures as much as they are educational opportunities. This perspective contrasts starkly with stakeholders that I spend time with. Misdirections made during development will never be thought of by clients as “valuable learning experiences”. Instead, they are major blunders that could potentially cost them a strategic opportunity, sales, or, in extreme cases, even their job.

Third, Agile tries to combine two worlds that don’t easily mesh. Agile requires everyone involved with the product to be part of a collaborative decision-making process. The theory is great, but it places a huge demand on all of the parties. It requires the stakeholders not only to be intimately involved in developing the product, but also to be savvy in both Agile as well as the principles of software development. In the end, clients engage us because they don’t have bandwidth or expertise for this level of involvement.

Others are also reaching similar conclusions on the shortcomings of Agile. Over the past few years, I have seen a steady increase in developers reacting against it. Blog posts with scathing titles such as “Run Away from Agile” or “Agile Is The New Waterfall” illustrate the frustration that some have with the methodology. Even Andy Hunt, one of the original authors of the Agile Manifesto back in 2001, believes it has lost its way in his “The Failure of Agile” blog post.

The S.W.A.T Approach

At Maark, we’ve taken a pragmatic approach to the shortcomings of waterfall and Agile and adopted principles and techniques that work best for the realities of the services business. We don’t do Agile; instead, we are focused on being agile, moving quickly across an enterprise as a “S.W.A.T. team” to deliver pragmatic value to our clients. In my follow-on post, I will dive into how we moved from Agile to develop app and website solutions using a S.W.A.T. approach.

Rich Wagner is the Managing Director of Engineering of Maark where he leads the development team and spearheads the technology strategy of the agency. He has led the development of multiple enterprise apps, mobile apps, and websites for Fortune 500 companies. Rich has also authored over 20 books on software development and other subjects.

Photo credit: LiveTrucking

Posted by Michael Colombo


For CIOs, the ask from the business is to turn a C130 Hercules into a fighter jet…while it’s in the air. It sounds like magic. Even if the mechanics were well understood, perfecting the execution might take years or decades of practice to pull off. Stepping in to support marketing in a digital transformation initiative often feels like an attempt against similar odds.

Digital transformation is about building world-class customer experiences, but there are so few organizations with a real understanding of the mechanics involved, let alone the flight hours needed to succeed. Building digital tiger teams with specific backgrounds and a nuanced set of technical skills is the first step toward reorganizing IT around the customer experience. These nuanced skills can mean the difference between delivering the fighter jet or just a pile of parts.

The skills between the skills.

At a glance, digital transformation programs look familiar. Requirements and Architecture, Screens and Flows, Development and Integration, QA and Deploy. You’ve been down this road a million times, right? Well, not exactly. The difference comes in shifting the priority from delivering a feature set to delivering an experience. And while nailing a feature set is difficult, delivering it within a world-class digital experience is where all the nuance lives. Mastering the nuance has big implications. An IT team with new digital skills in between the traditional IT skills and a proven ability to execute on experience moves them squarely into the growth strategy of the business.

“I believe in innovation and that the way you get innovation is that you fund research, and you learn the basic facts.”

Bill Gates


To effectively document requirements, you need a new kind of business analyst. Going to business stakeholders, understanding their needs and how they apply to the bigger picture of the business strategy, and documenting those requirements and their system implications for a technical team is not enough in the context of digital experience. The nuance here to the traditional business analyst role is that they should now be able to communicate all of the facts of the User Experience. Business intake and competitive research resulting in a User Requirements Specification (URS) should be accompanied by traditional UX deliverables, such as User Flows, Information Architecture, and even rough wireframes and prototypes. Your business analyst should be able to help during concept testing as well as the QA process, as they should have a strong vision for the quality of the experience that is being delivered. The requirements that the new business/UX analyst delivers need to have the users at their core and be directly translatable to digital execution teams.

Project Management:

Project managers, like business analysts, need to know that they exist entirely in an experience-first context. It is not enough for them to deliver on the functional requirements of the system. I can’t state that more strongly. Development and project management teams that have forever judged success based on a “Does it work?” mantra are not poised to successfully deliver world class digital experience. Instead of, “Does it work?” they need to start asking, “Does it deliver an industry-leading experience?” If they are not asking that question, then they are not focused on the right result.

Project managers who have never delivered customer-facing products have a steep learning curve. They will need to begin forming their own vision for the experience they are delivering, and consider how closely they match that vision as their primary success metric. That it “works” is a given, but delivering an experience that technically “works” but nobody likes is a failure. It’s a setback to the business, not an advancement. It’s prioritizing an MVP over an actual ROI. Everyone on the team needs to internalize this reality.


While the big shift in IT toward cloud, agile and DevOps are improving the flexibility of what can be delivered inside the enterprise, the underlying point of these advances can sometimes be lost. Putting things in AWS isn’t a win on its own. Spinning up GitHub doesn’t mean you’ve got a modern development organization. The goal is speed, pure and simple. The number one enemy of the enterprise - when it comes to long term competitive threats - is the amount of time it takes to innovate and iterate. If the systems you are buying and putting on AWS are not making you faster, then they aren’t going to help you compete with digitally native companies.

If the DevOps tools you are setting up aren’t actually helping you respond in near real-time with new products and features, then you aren’t getting what you need out of them. If the focus is not entirely on speed, then you aren’t focused on the right thing. The shift in focus to user experience also shifts the business model of IT. While cost is always an important determinant of IT maneuvers, speed to market is your new primary metric. And speed to market with better digital products and services is about new revenue opportunities and increasing the lifetime value of your customers. In this context, IT is core to the brand and the growth strategy of the company.

“Design is not just what it looks like and feels like. Design is how it works.”

Steve Jobs


OK, here’s where the rubber meets the road. We all know that you can have the best requirements, the most diligent and focused project managers, and an infrastructure humming like a fighter jet…but if you can’t reproduce a design comp, you’re toast. “Reproduce a comp” may not even be in the IT vernacular yet, but it should be. Delivering a world class digital experience is brain surgery. It really is. And if you’re treating it like a routine procedure, you’ve got no chance.

The demand for good development talent couldn’t be higher. Some estimates have it at about 5 jobs for every 1 developer. So, just getting good talent in the door is difficult enough. However, changes in the B2C and B2B application space is torrential, so most times any ‘ol “full stack” developer won’t do. You need specific developers with nuanced skills. Frameworks and technologies on both the back end and the front end take years to master, as do the excess of marketing and sales technologies running behind the scenes of the user experience.

Bringing all of these pieces together into a flawless UI is impossible to do with “any ‘ol” guy or gal. (The interface, by the way, is a specialty just like the rest of the stack. HTML and CSS are not passive skills and are advancing rapidly like everything else. They are core competencies of digital tiger teams.) Each area of the application requires expertise and focus. You have to be able to put every pixel in its place in order to get the ROI that the business is looking for.


Partnering with marketing on digital transformation initiatives means signing up to deliver world class user experience as a repeatable capability. Everyone inside and outside the organization has a standard for this level of work staring right back at them every time they pick up their phone, their tablet or a laptop. It’s all around us. We all expect it to be great, and we all immediately recognize when it isn’t. But because the demands are so high, and the needs are so vast, delivering Digital Transformation has become one of the hardest things to do in business. It takes a clear strategy and an experience-first focus, and then a rethinking of core IT skill sets. Flying the C130 while turning it into a fighter jet is the ask. Understanding the mechanics involved and the skills required to pull it off are the first step.

Michael Colombo is the founder and CEO of Maark where he oversees the overall direction and development of the agency as it continues to build its brand as a leading marketing and innovation engine for its customers. He has served as the executive lead in programs including corporate rebranding, solution marketing, sales enablement, digital transformation, and new product design for Fortune 500 companies around the world.

Photo credits: Johnson Barros, Pavel Vanka


It’s not enough for an architect to be creative. They have to do more than just define a space or design the look of a structure. They have to ensure that the structure is sound. This requires a strong foundation, not only in the creative process but also in engineering. As much time as Frank Gehry might spend taping together pieces of paper he has to also make sure those pieces of paper will stand up against this little thing called physics.

The same goes for the industrial designer—Jony Ive balances a strong creative process with one that is inseparable from engineering. The construction, strength, and manufacturing of materials along with an understanding of how the elements are housed within his designed case are a package deal. Form follows function—and he has to really understand the function to create the form.

The architect and the industrial designer are part of a well-rounded design discipline where visual creativity is not enough. They must understand the context of their work, which requires them to be near-experts in physics and engineering.

In digital design, we have moved away from the well-rounded designer to hyper-specialization, with different designers with specific specialties focusing on their single area. But digital design, like architecture and industrial design, should be a well-rounded discipline. As a digital designer, you need to be a near-expert in adjacent spaces to be successful.

So what areas, besides design, does a digital designer need to excel in to be successful? I believe there are four key areas of focus. These are the physics and engineering disciplines for the digital designer.

User Experience

Everyone creating products needs to be thinking about the user, but the digital designer needs to be able to act on it. Knowing how to talk to users, test users, and getting thoughts and opinions is crucial to realizing what the product needs to be. Folks dedicated to gathering this for you are helpful but not always an option. And once you have that info it is just as important to be able to take those findings and distilling them into simple, readable, and relevant diagrams for stakeholders.


Designers don’t normally think of themselves as researchers, but without researching the world where a product will live, a digital designer will find themselves hitting walls left and right. Researching the industry and landscape gives context for how it will be seen in that environment. Designing an experience for the financial industry is very different from designing an experience for the medical industry. Each has its own expectations and constraints. Designers need to be able to learn about a new area independently and then think critically about that area, almost as if they are living in it.


This one might be the most difficult for a designer—business is not a required course at most art schools (any art schools?). Businesses are constantly considering how to gain new customers or sell more services and products to existing customers. The digital designer’s work needs to support the same goals and strategies as the business to help them succeed. Selling design cannot only rely on aesthetics, but how a particular design will deliver the results the business is looking for. Digital designers should work more closely with the business to learn how they work. For starters, pick up a classic business book like the Essential Drucker—it will introduce the basics and the language of business.


How a digital designer’s work is implemented is just as important as how it’s designed. A digital designer needs to know how applications and websites are built, what they can do, what they can’t do, and how it all gets made. This is not a small ask for a digital designer but it’s a necessary one. The best thing for a digital designer to do is to get in the trenches a little bit and learn to code. Maybe not at a level that their development team is working at, but enough to understand how development works and design a better suited experience.

Digital design is multifaceted and complex. A well-rounded digital designer needs to understand all those facets to create the best solution, considering the user, their research, the business, the implementation, and, of course, the design.

Alex Carr is the Director of Creative Services at Maark, where he leads a team of illustrators and designers focused on marketing, branding, and product design for our clients.

Posted by Michael Dowd


You’ve narrowed down your RFP respondents to a few finalists. They’re flying in from around the country for their chance to give you their biggest pitch. They’ve all brought Fortune 100 case studies, industry legend executives, and a PowerPoint that doesn’t miss a single dotted ‘i’ or crossed ‘t.’ But now it’s time for you to make the people sitting in the room think on their feet a little and see what they’re really made of.

To help you see through the smoke and mirrors, here are a few questions that can help separate the partners from the pitchmen/pitchwomen.

1. Who will be working on my account?

Seriously, give me names. Can I speak with them? Teams aren’t always completely formed at the pitch stage, and that’s okay. But hopefully you can at least get a feel for the management side of things. Pitches are too often a bait and switch where subject matter experts and executive leadership detail out sophisticated strategies that they themselves will never execute. I don’t doubt the ability of the giant marketing agencies and consultancies to deliver award-winning work. I am, however, skeptical of their ability to maintain quality control across all of their employees, which leads to an uneven and unpredictable distribution of talent. Once the contract is signed, account teams are too often cobbled together from available resources with little or no consideration for the opportunity at hand.

In the end, the specific people working on your account are just as important as the agency. Pitches should be a chance for you to get comfortable with the team that you’ll be working with for years to come. Insist upon meeting those people face to face, and don’t be afraid to get personnel commitments in your contract.

2. What does your staff turnover look like?

Even if you can secure rock star talent from your agency, what will that team look like a year from now? The agency world has an annual turnover rate of over 30% (not to mention internal reorganizations), so for every three people working on your account, odds are that one will be gone by next year and replaced with an unknown quantity. There are articles all over the major ad publications about the wasted costs of training and onboarding new employees, but far fewer about the impact that turnover has on the clients. If it takes six months for a new employee to get up to speed as these studies suggest, that’s six months of below-average productivity inflicted upon their accounts.

If an agency has a high turnover rate, keep asking for details. Why is it so high? Is there a cultural problem that may impact your account? What are they doing to address it company-wide? What assurances can they provide that your account will be shielded from the impacts of high turnover?

3. How many layers are there between your point of contact and executive management? …and tactical execution?

A heavily stratified employee structure is a hallmark of the biggest marketing agencies and consultancies. Complicated titles make it impossible for an outsider to understand who reports to whom and who works on what. Typically, Account Directors are the main points of contact. To get from them down to execution, you go through media directors, managers, specialists, and planners. To go up to strategy, you go through more layers of directors, practice leads, managers, presidents, and CXOs. Maybe your company is influential enough that you can pick up the phone and speak directly to the agency CEO. But even then, dispensing strategy unilaterally at the executive level often feels like pushing a rope. There are a dozen layers for that CEO to cut through to make sure that discussion translates into tactical execution, which means a dozen opportunities for the message to be lost.

Understand the process by which each company builds and distributes strategy. Ideally, it will involve input from all parts of the company, but at the very least, look for evidence of how new strategies are built and applied to active clients over time. Too often, new strategy is used to lure new business while existing clients fall into more comfortable patterns because their account teams don’t have a reliable source of new ideas or enough incentives to generate their own.

4. How do your different departments communicate?

Just because your “holding company” can do everything under the sun doesn’t mean those people are talking to one another or even know who the other is. Agencies and consultancies like to issue acquisition press releases that make it sound as though they’ve acquired a fully integrated partner. In reality, acquisitions are about the consolidation of profitable companies, and on the back end, they usually operate as they always have – not just as separate entities, but often times as competitive ones, even within the same holding company.

It’s unrealistic to expect that companies will never need to bring on additional resources – especially as project scope grows – but don’t accept those partners at face value. Look for companies that are upfront and transparent about their relationships with both other marketing teams and outsourced partners and ask to meet with those teams directly. Understand how they have worked together in the past, how they unify strategies, and how the broader team is structured.

5. Does your company build and maintain its own MarTech infrastructure?

…why? When it comes to agencies, invest in people over platforms. The proprietary marketing technology arms race is an artificial competition created by the mega agencies to compete against one another. Don’t get me wrong, there are reasons to invest in internal technology, and they generally center around the large-scale application of intelligence. For larger agencies, distribution of strategy and insights is a challenge, and technology can facilitate that in a way that more grassroots methods often cannot. But for automation and aggregation technologies, there are SaaS companies out there that are doing phenomenal jobs at democratizing their applications at affordable rates. And those third-party technologies are incentivized to integrate with other industry leading technologies instead of remaining siloed within a prescribed technology stack.

Even if you aren’t using their technologies, you are likely paying for their overhead. Ask your agencies how they break down development resources, how technology is funded, and what their incentive model is with any technology platform – internal or external. Otherwise, you risk paying for people and platforms that have no relevance to your company. If you’re concerned about conflicts of interest, seek independent review of technology recommendations until you’re comfortable with your new agency.

The common themes in these questions are people and accountability. Understanding your account team, their communication structure, their incentives, their culture, and their responsibilities will give you a better understanding of your partnership’s potential than any case study ever will. So be noisy, demand more up front, and set yourself up for long-term success with your new agency.

Michael Dowd is the Executive Director of Digital Strategy at Maark, where he coordinates new product development and execution for our clients. Mike brings with him eleven years of experience in agency-side digital marketing, during which he provided guidance on marketing technologies, platforms, and strategies for more than a dozen Fortune 100 companies across the B2B, retail, and automotive industries.

Photo credit:


Agency on Record, the podcast from Maark, just hit the eleventh episode of our weekly podcast. That might not seem like a lot, but it’s a milestone for us. That’s because the beginning episodes were a trial run to see if we could do this podcast thing for real. Could we find the time? Could we come up with enough topics? Would anybody listen? Would Mike and I rip each other’s faces off? Would we even really like doing it?

And since the answers to all those questions is a resounding “yes” followed by a resounding “ish,” we’ve leveled up the podcast.

You’ll notice starting at Episode 9 a much, much higher sound quality. We’ve moved the studio from the Maark basement to its own dedicated room and invested in higher-end sound gear.

That’s right. Invested. We’re in this thing for a run.

In our first 11 episodes, we’ve tackled everything from GDPR (“Data Privacy: Secrets Never Stay Secret”) to UX engineering (“The UX Engineer as Unicorn”) to business storytelling (“Marketers vs. Storytellers”). We’ve welcomed on colleagues here at Maark to join the conversation when it touched their area of expertise. Our content seems to range, but that reflects the nature of digital agency life and work.

Soon, we’ll be experimenting with other features for the podcast, including an industry news segment and interviews with guests outside of Maark. It’s actually been a lot of fun figuring this whole thing out.

Some come on by. Give us a listen if you haven’t. Give us a second chance if you have. Want to know more about Maark first? Check out the most recent episode.

And keep checking back, as this is a weekly podcast that shows no sign of slowing. And that’s because it can’t. We have to in order to get our investment back on all the equipment we bought.

Oh, and if you dig it enough, throw us some stars or a review on iTunes. You listen to podcasts. You know how that goes.