Der nachfolgende Beitrag wurde in gekürzter (deutscher Fassung) in der LEAD digital Nr. 22 am 30. Oktober 2013 veröffentlicht. Viel Spaß beim lesen.
A digital agency is a tech company.
This article is an examination of one aspect of what a digital agency is or should be. It is about an aspect than has some misconceptions. One of these misconceptions, perceives that digital agencies are there for making pretty images (digitally). Another comes from “serious” software companies. They often have the attitude, that digital agencies are not making “real” software. To clear these up, I will ask you to change your assumptions and accept two claims.
Firstly, a digital agency is not an advertising agency on bytes.
Although digital agencies are involved with advertising and marketing, they are making things that have programmable code.
And secondly: anything that has programmable code is software.
A digital agency understands the medium it works with and continues to adapt and grow with changing technology. The medium is not just a surface for static content or moving images. It interacts — and soon there will be little left that does not interact.
If we are creating software as soon as we start writing code, then digital agencies are involved in software processes — no matter what they are making. Therefore they not only need to understand the technology but also they (and their clients) must learn software development processes.
Software is not put together on a conveyor belt. It is a creative process involving many different skills — from start to launch and beyond. Successful, creative, innovative projects require a paradigm change.
“Agile” is a buzzword that even classical agencies are starting to use. But “agile” is not just about being flexible. It is about re-thinking processes and about involvement.
Embracing change was a new thing for software developers back when people were used to writing everything down ahead of time — getting it absolutely right — before a single line of code was written. Unfortunately it is almost impossible to get it “absolutely right” at the beginning, and so agile processes emerged.
But (classical) agencies have always been used to change. Painfully so. The attitude has been, to always say “yes” to the clients wishes, no matter how late or difficult the change is. The problem here is usually misleading or missing communication, which in turn is the fault of “factory thinking” and not because a client is “fickle”.
“Factory thinking” is what happens when a client’s “order” is put on a conveyor belt through an agency, progressing through different teams who know nothing of project until it has been placed on their desk. The client sees the project again at the end of the line. Most likely, it is not quite what the client was expecting, and last minute changes and corrections are the consequence.
However the solution is quite simple: Involve everyone in the entire process.
Involvement and Partnership with the client.
At MINISTRY we have been involving our clients in the entire project process for several years now. Although some clients are still hesitant, those who have embraced this kind of partnership, have enjoyed successful and creative processes that have lead to great products.
Involvement throughout the process does not mean more work. It is a shift away from concentrating on the beginning and end of a project. Cooperation is spread over the whole process. By doing so, the risks of not being on time and of dissatisfaction, even conflict, are practically eliminated. Most last minute changes are due to misunderstandings. The agency misunderstood what the client wanted. The client was not so sure what he wanted. The client misunderstood what the agency was planning.
Involvement is a cure for this. It allows us (the agency and the client) to adapt, adjust and prioritise. We can decide together what we can change immediately, what we can do later in order to stay on time, what cannot be changed and must be accepted. The consequences of every decision are carried together.
Scrum & Co.
Methodology is a great place to start, but internalising the principles is more important. At MINISTRY we began a few years ago with “Feature Based Programming”, a method shared with us by Stefan Richter of freiheit.com. Currently we are trying out “Scrum” for larger projects. But in their basic principles all agile processes are very similar. Here is an example of how we use them:
A project typically begins with workshops involving the client, a project manager from the agency and people who have the skills of a developer, a quality manager and a designer. The purpose of the workshops is for all to find out what the project is about, what the desired result is and what we can do to get it done. The result of this phase is not a book about the project, but rather a feature list, which describes what we plan to do — in a style and language that all participants understand. Features can be split it up into blocks and can be made into a roadmap. The important thing here is that we try to get it right from the beginning, but it is possible that some change will come with time. It is important that we define what we are going to do, not how we are going to do it. That will be decided in the next phases.
There is an important difference between this process and trying to get it “absolutely right” before programming. We define what we want to do to the best of our knowledge, but we leave room for course correction along the way, and we never say “how” we are going to something, because we often cannot know that until we get there.
The process that follows is a series of iterations and checking back with the client. Milestones can be presentations of a “clickable” prototype (wireframe), a style guide or layout. Later software releases allow the client glimpses of the real working product, where a designated set of features is already programmed. The product takes shape and is being created at the same time and the client is involved in the entire process.
This is quite different than showing pretty designs at the beginning and coming back shortly before launch to make sure that all that was done in the meantime is OK for the client.
Since designers and developers are involved in the whole process, we can assume that we are saving time by not coming up with ideas that might not work or might take too much time. Since the client is involved throughout the process we can assume that we are staying on track with what the client wants and can adjust throughout to make sure.
Some agencies have entered partnerships with tech companies. That’s fine as long as the technology partner is involved in the entire project process.
The advantage of being a true digital agency (and therefore a tech company) is that you do not have to double up. Each skill is already based on an understanding of making software, whether the consultant, the project manager or the designer — and needless to say, we have developers and testers on each project the whole time.
And if you buy my assumption about what software is, then any agency without skills in the process of making software and knowledge about technologies involved should not use the word “digital”. A digital agency that does not do software is like an automotive designer, who does not know how to build cars. You might get a lot of fantastic looking vehicles out there that don’t work, or many very similar looking functional cars.
So what is a digital agency?
Digital agencies are tech companies that are experts in making software that is enjoyable to use, nice to look at and that attracts customers. They understand software processes and can create fantastic functional interactive products. Incidentally this also has something to do with advertising and marketing in a digital world.