Skip to main content

AGILE For DIGITAL AGENCIES

[PLACEHOLDER]
Image

Introduction

Some Digital agencies have a project process where waterfalls still plays a big part of it, and as far as I can tell, the tech team is usually the one suffering as they are at the last part of the chain left with limited budget and time for execution.

I do believe that adopting an Agile approach could make a Digital Agency better and faster.
In this article I’m presenting you just another point of view of why it make sense looking at Agile Methodology. 

Why Agile for a Digital Agency?

The Agile movement started in the software development industry, but it has being proven to be useful in others as well. It becomes handy for the type of business that has changing priorities, changing requirements and flexible deliverables.

In the Digital Agency of today you need a different mindset. Creative will always play a huge role (“the bread and butter”). But the “big guys” need to understand that without technology there is no Digital Agency. Technical resources are just as important as creative resources for the modern Agencies. If we talk about multi-touch campaigns, multi-platform solutions, CRM, APIs and so on; you would see how everything is supported by technology.

“In this industry the Techy needs to be creative and creative need to become techier.”

From the Creative/Design perspective perfection is the desire. Agile is more around iterations, as perfection might never come and, if you think about it, it may never be necessary. You need something done, functional, scalable in order to get to where you want to. At that collision of thoughts comes frustration from both parties. The solution comes with compromise and collaboration.

I like to think that creative is the dreamer side (crazy and amazing ideas drives innovation. But things like budget are just stones in the way) were the technical side are the ones making the reality check (inspired to make something amazing real and tangible. But the reality check sometimes looks like pessimism under some eyes). But when synergy happens then this middle ground gives you a different chemistry that provides flexibility.

I believe that Agile goes well with Digital agencies were scope changes, the budget is always a challenge, client change their minds, the talent (resources) switches. In the Agile methodology true collaboration comes into play. For those Digital Agencies that claims collaboration as one of their key elements then it should be a good fit.

By just reading the 1st principal from where the Agile Manifesto is based on, you can tell how beneficial is the Agile approach: “Customer satisfaction by rapid delivery of useful software”

The 2nd nails it for UX cases, were clients keep adding or changing requirements: “Welcome changing requirements, even late in development”

In addition if you look at the 3rd item of the Agile Manifesto you will see how important is engaging the stakeholders: “Customer collaboration over Contract negotiation”

If you are a manager moving forward with this concept then here are some tips around your POC when bringing Agile inside the walls of your Digital shop:
  1. Proof of Concept (POC) by picking 2 projects (small and medium size for example)
  2. Engage the client. Without them this process will fail. Their feedback is key in order to provide the product/service they are expecting. This means your account team is also key maintaining a healthy and transparent communication. The account team should not be a blocker between the client technical team and the digital agency tech team, but they should be aware of everything that is happening. If you heard about extreme programming, where developers work in pair over the same code using the same computer (taking turns), well that type of collaboration has to happen between the account and the PM, at such point that you could not tell which one is what. This will bring the PM closer to the client and the account closer to the tech team (you need your account team to become techier, after all they are the front-line of your army).
  3. Select a PM, a Creative and a Tech (your leads for your POC) that will lead your teams through the Agile process implementation. The PM should be different from the PM of the actual project selected for the POC, as it should be focus on the Agile implementation. (Note: if the budget allows it the PM lead can be a consultant, preferably with experience on Agile Methodology)
  4. Have daily meetings with your leads until the time when the POC start. Mentor/guide them, your support as a manager is key. When the POC start then switch to weekly meeting with your leads. Also one-on-one with members of the team (informal coffee breaks perhaps) will provide valuable feedback.
  5. “Lessons learned” sessions after each iteration and at the end of the POC are crucial as it will help you find:
  • The pros and cons of the implementation
  • Tweaks/adaptations that needs to be made to the process
  • A better understanding that will help to make the proper selection around the tools (software) for supporting your new process.

Some ideas on how to measure the Agile POC

  1. Client feedback. Around execution and product/service delivered (expectations/quality). Make them part of the process by asking them questions about the experience, for example: “what are your thoughts about the project and the process? What can be improved? Do you find this better than our previous process? Was the change in the execution noticeable?”
  2. Get feedback (survey) from all the members of the internal team that participated in the POC. After all is the team that will have to deal with the process on a daily basis. “It is not a process by force, it should flow naturally”. Remember there is always room for improvement.
  3. Budget. Make a comparison between the POC and other projects of the same size.
  4. Quality. Engage your QA team to evaluate and compare the POC with other projects deployment cycles.
  5. Present the results to others in the organization by organizing a Q&A session. Receive more feedback…

Tools

As you make mistakes, adjust the process to your needs, gather feedback and finally established a process that works for the Agency (for the client and your team) then you’ll need to arm your army with the required tools.

From the development perspective your development team already most be using tools for their cycle. If they don’t then you need to quickly fix that:

  • Version Control System (VCS) for your files (creative documents, code, assets, etc). You have several flavors:
  • TFS
  • SVN
  • Git
  • Mercurial

  • Continuous Integration (CI): several tools out there. It will depend on your budget, your team. Also consider the “flexible aspect”, meaning how well integrates with your other tools (for example your VCS):
  • Microsoft Visual Studio TFS
  • Teamcity
  • Jenkins
  • Bamboo
  • CruiseControl
  • To have a full picture you want a tool that helps you with your Application Lifecycle Management (ALM), that goes well with Agile, works not only to handle your tech side, but also your creative side of your company (you are a Digital Agency) and, if possible, integrates well with your other tools (CIs and VCSs that are part of this cycle). Essentially something that glues everything together, reducing the use of a few things that can slow down a team or misplace “stuff” like:

  1. Multiple Emails with different versions of the requirements list
  2. Emails with out-of-date spreadsheets and other files
  3. Client feedback
  4. Bug lists
  5. Members of the team not knowing the due date of the project
  6. And others
           Here are a list of software that can get you started and move away from the previous list of issues:

Final thought:
Do not be afraid of mixing things up. It is not an exact science and there is no need to enforce every little detail of the “Agile”. Tweak, adapt and find the formula that works for your client relationship, the productivity, the team collaboration and product quality.

If you are still with me then I would like to invite you on taking the time to see this TED video:
-    Agile Programming for your family:  https://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family#t-223367

References:

Trending posts

Democratizing AI

Democratizing AI is all about empowering others to use it, by making it available to them. Audiences, such as marketers in a company, will be able to access AI capabilities as part of their MarTech solutions, without the need of being technical. It could also be schools, where the younger generations are learning how to use it in responsible, secure, innovative, and creative ways. This is the year where companies, after discovery phases and teams experimenting, are looking to activate and take advantage of the AI advances. Generated with Microsoft Designer   And so, questions emerge, such as “What to democratize when leveraging AI?” There are common scenarios, as well as specific ones, that will depend on the company, and the industry they belong to. A common scenario, seen in many industries, when democratizing data is the data visualization and reporting . In digital marketing, as an example, data scientists and data analysts can automate reporting, making them available to the c...
Read more

The value of listening

 Have you ever been in a conversation that you feel at best is just a waste of time; at worst, that the other person does not care? Have you been the messenger in some of them, the recipient in another? We’ve all been there; at times with family, with friends, at work. When at work, has this ever happened to you in a group meeting, at a one-on-one; when giving or receiving feedback?   Photo by Christina Morillo via Pexels   I knew the type of manager I wanted to be from the start of my mentorship. As I continued to navigate the waters, it became increasingly clear that the path I had chosen was appropriate, and therefore, the type of future colleagues I wanted to be surrounded by, and the type of mentors I wanted to continue seeking guidance from.  For me, the path has always been of being a leader over a manager. I believe I can attribute that, first and foremost, to my family’s values and  principles, and the way my parents raised us. Secondly, my path in the ...
Read more

SRE, DevOps and ITOps

 If you are wondering what the differences between the SRE and DevOps are, as well as how these roles work with ITOps within an organisation then you are not alone; and best of all you are on the right blog post. Often enough business units in a company get confused, assigning the ServiceNow or Jira tickets or any other ticketing system of your preference, to the wrong group, and even having the incorrect expectations when doing resourcing. Let us go through definitions, insights and scenarios that will help you understand the difference. DevOps software development operations - AI Generated When it comes to DevOps and SRE, then you might be wondering which practice came first. While SRE may have originated a bit earlier, internally at Google, DevOps came first publicly as a practice and started to be used by companies. A few years later was when Google decided to open SRE to the world after the publication of the "Site Reliability Engineering" book. Therefore, technically sp...
Read more

SLA-SLO-SLI and DevOps metrics

Companies are in need of the metrics that will allow them to stay in business by making sure they meet the expectations of their customers. The name of the game is higher customer satisfaction by winning their trust and loyalty. To do so, you want to provide good products and services. Therefore you need to find ways to monitor performance, drive continuous improvements and deliver the quality expected by the consumer in this highly competitive market. Photos from AlphaTradeZone via Pexel and Spacejoy via Unsplash SLAs, SLOs and SLIs are a good way to achieve the above. They allow clients and vendors to be on the same page when it comes to expected system performance. If we go one level deeper, vendors/providers work on NFRs (Non-Functional Requirements) when working on their solutions. NFRs define the quality attributes of a system. I bring them up because the relationship between them and the SLAs is that they provide, in a way, foundational aspects for the SLA-SLO-SL...
Read more

This blog uses cookies to improve your browsing experience. Simple analytics might be in place for pageviews purposes. They are harmless and never personally identify you.

Agreed