The Agile Agency

On top of that we have the hidden disciplines such as search engine optimization, social media integration, or accessibility. Underlying all of this is offline support when we speak about apps, and the foundation for all other aspects: performance.

Digital is a mess. It is a damn hard domain and nobody has figured out the perfect process to create these interactive experiences smoothly. A huge part of the complexity isn’t obvious in the beginning. Concepts and design usually only talk about the visible part of the iceberg. That’s fine, as long as you’re aware of that fact – but usually you are not. You write a concept, design some wireframes and think you nailed it. Then you hand it over to developers who do their best to make it work … and it takes longer. It gets more expensive. Key features don’t work. Stuff breaks. You run out of budget, still in the need to deliver something.

After many struggles you finally do ship the product, but the client expected it to be different and wants you to change it. A couple of years ago we had projects fail that way. Spectacularly wrong estimations regarding budget and time led to underwhelming results that we couldn’t be proud of. We had skilled people and interesting projects, so the prerequisites were there, but we couldn’t unlock the potential. Something had to change.

Sometimes paper is superior to screens, even in digital.

Designers and developers working together.

Agile and early struggles

Digital projects are complex interactive experiences, yet we approached them in the old way. At that point in time, we were seriously questioning our methods in digital projects because they did not work out for us. It was time for a change and we started to approach new projects with a new way of working. We discovered Scrum – an agile framework for managing complex projects. In 2011 Michael Börner joined us as our first Scrum Master, bringing agile thinking to the company.

Agile projects work very differently. You don’t even try to set everything in stone in the beginning – instead, you acknowledge that when starting a project you usually don’t have enough knowledge to figure everything out. It’s more like setting sail in the vague direction of where you want to go without pinpointing a specific location to arrive at in the end. You give up control and figure things out on the way. That’s hard at first, because letting go of control is always scary. But the truth is, that in today’s digital landscape you don’t control many aspects of the experience anymore: typefaces? Screen resolution? Network speed? Even color range of screens? Try to visit your website on a Kindle. All scrambled.

In an agile process you break the project up into smaller sub-projects, called “sprints”. Those usually last for one or two weeks. In the background you have a prioritized to-do list: the backlog. It serves as the pile of things that need attention … the top ones are usually the items being tackled by the project team in the next sprint. Those so-called stories should be fleshed out, be very specific, and talked through with the client. Further down the backlog things can be rough, but you revisit it frequently to “groom it”. That means adding information to the yet-to-be-done stories – like requirements, and roughly estimating the complexity.

Before the sprint starts, the team talks extensively about the upcoming stories, with all team members – this type of meeting is called the “planning”. Designers can describe what kind of UI they envision for the feature at hand, while developers give input on the technical aspects. Usually, the client is present as well, and often all involved parties agree on a reasonable compromise that respects all disciplines.

Then the team gets to work on all stories that fit into the sprint, and by the end everything will be reviewed again with the client. Throw in a retrospective after each sprint for the team to discuss what worked well and what didn’t, and there’s the cycle that happens over and over until you reach a launchable product: plan what can be done, work for 1–2 weeks, review, improve by looking back. Repeat.

When we established this process, I can clearly hear myself ranting how much time we spent in meetings, and why we needed to talk so much about everything. Colleagues were equally skeptic. Often I had the feeling of, “just let me do my work, I’m not dumb, I’ll figure it out on my own.” Clients were skeptic as well, because it broke with the model of the agency being a contractor. You hired us to do work for you, right? Why should you be in all meetings, making it even more expensive and laborious for you? Indeed, Scrum can seem patronizing and pedantic, but you have to realize it is about trust.
– Trust in your own skills to figure things out on the go.
– Trust from and in the client.
– Trust in your team.

All work and no play makes Julian a dull boy.

Back to work, sketching out ideas.

Smoothing out the process

Estimations regarding how long a feature will take to build are usually off by a mile in software projects. By dividing the project into smaller sub-projects and talking frequently about the progress, you break down the complexity. This helps to make more reasonable estimations, and even if they are wrong the consequences aren’t nearly as fatal. Because of the limited time within a sprint you need to focus on the important things – usually called the MVP, the minimum viable product:
– Get something done in a basic way so it works.
– Then iterate upon it until everyone’s satisfied.
– Then move on.

This is a dramatic shift in mindset compared to the old way, where somebody might bury him/herself for a couple of weeks just building one feature, then realizing it wasn’t even what the client wanted or needed.

Agile is also about work ethics: The team decides in the planning how much work to tackle per sprint, therefore extra hours are the exception. We try to always keep the same persons on one project and not switch too much. You have one project at a time, very rarely two, because good work needs focus. This also has a beneficial side effect: By spending months, sometimes years on one project you identify much more with your work and the people working together really form a team, not just a group of workers. It’s team building at its best, because you are in it together.

The client being in all important meetings also gets to know the team, because there is no traditional project manager in this setup. The team interacts directly with the client – called the “product owner” (more on that later), nobody is standing in-between turning communication into a game of Chinese whispers. The Scrum Master is not a project manager, rather a facilitator enabling the team to accomplish their tasks and watching over the process in a broader sense.

Our Berlin office.

Having breakfast together to start the day.

Honor the rituals

Scrum works best when you stick as closely to the guidelines as possible, because it’s a well-orchestrated process. Therefore all different types of meetings and roles are important. Here’s a list with some take-aways we learned over the years.

The planning can and should be tedious
The planning meeting sets the foundation for all work being done in the upcoming sprint. It should be well prepared by the product owner, having added detailed information to immediately upcoming backlog stories. The planning then usually lasts for a couple of hours and that’s a good thing. The more productive the discussion in the planning, the clearer the team knows what to work on. Therefore it is in its own interest to ask lots of questions and talk through every feature. There are no dumb questions, make sure everybody knows exactly what’s coming up. Don’t be lazy here – if you are, it always comes back to bite you mid-sprint.

The planning is concluded by estimating the complexity, or duration of upcoming stories, and using these numbers as a baseline for committing to what can realistically be achieved in one sprint. Estimation happens either based on complexity, or needed time to complete the story. We’ve used both metrics in projects, but I’m leaning towards estimating complexity. Mainly because I feel it is the more basic metric and estimations regarding time – at least in terms of development – are too often horribly wrong.

Keep the Daily Scrums short and on point
There is a type of meeting we haven’t talked about yet: the Daily Scrum, sometimes called “stand up”. It is a daily ritual of the team getting together each morning for 15 minutes, in order to figure out tasks for the day. Often this gets out of hand, taking much longer because people start discussing challenges in a bigger group than necessary. These discussions should be postponed until later. The Daily Scrum is meant to be short and concise. Each team member updates the others on yesterday’s accomplishments and what is on the table for today. That’s it. The client can and often does take part in these daily meetings (in person or via Skype).

The review is the team’s stage
When the end of the sprint is nigh, we review the accomplishments in a meeting aptly named the “review”. Depending on the project and team size this can take hours, but it’s worth it. The whole team is present and each team member presents the work he, or she, did during the sprint, as well as the reasoning why things might be different to what was previously expected. Presenting your work yourself is a key point, because it makes you feel responsible, instead of being an anonymous little gear in the machine. Usually there are no big surprises because the short daily meetings make the sprint transparent; however, stakeholders not directly associated with the project might join in as well. For example, in the Ableton project the CEO and a handful of other important people from the company always attended the reviews and gave feedback. Having them around was incredibly helpful and rewarding, when they liked what we did. It’s not just presentation though: usually everyone gets to see the product working as a whole for the first time. Therefore an important aspect is to analyze how well it all ties together and using these insights for iteration in the next round. 

Working closely together
Usually the two big parties working together are developers and designers. Scrum is about bringing people, and therefore disciplines together. Static mockups and pixel perfect implementations are dead. What’s the workflow within a sprint then?

Over the years we found that giving designers a head start is a smart thing to do. Designers must have time to explore possible visual directions without developers running dry in the meantime. We usually have dedicated design exploration stories that allow us to design the interface roughly, get feedback, and then sit down with developers to talk about it. Afterwards, developers get to work and bring the designer back into the loop when they’re about 80% done. The final bits fall into place by sitting together, looking at one screen, and discussing how to finish the feature.

Of course, you run into problems here in case you don’t have developers in-house … luckily we realized this quite early and now employ around 10 developers at Edenspiekermann Berlin. Some of them are hybrids between front end development and design, which makes the process even smoother. Whenever we have people sitting together at one table we see fundamentally better results, so we try to facilitate this situation as much as possible. In a couple of projects we even had developers and designers from the client working full-time in our office which greatly enhanced productivity.

Cross-disciplinary teams produce the best work.

A good retrospective has a phenomenal impact
The retrospective is a meeting for the team, and happens once per sprint, looking back at the work that was done and discussing the state of the project. It is the easiest part of Scrum to skip and I’ve heard the phrase “we don’t have time for the retro” more than once. Don’t fall for that thinking, retrospectives are tremendously important. Sprints get stressful, leading to tunnel vision, and the retrospective allows you to take a step back and look at your work with fresh eyes. They can be an open discussion or be more playful involving little games. A well executed retrospective can break the ice between frustrated parties and greatly improve the atmosphere in the team. Also, they’re fun – never underestimate the impact of fun. Here’s a primer with tons of good methods to use.

The role of the Scrum Master is diffuse, but indispensable
At first sight, the Scrum Master seems to be a weaker project manager, but inherent in the role are a lot of soft skills that are easy to overlook. Traditionally, the project manager used to be the interface between the client and the team. In an agile process the team should be as self-organized as possible, talking directly to the client. The Scrum Master is a sensitive mentor, providing guidance, organizing meetings, and generally standing by the team’s side whenever uncertainty creeps in. This facilitating role brings all other parties together and makes sure the process is smooth and to the point. In a nutshell, the Scrum Master is supposed to make the team better and more effective. I find it comforting and encouraging to know that there’s someone having my back at all times.

The team agrees on a set of stories in the sprint planning, then gets to work for a fixed amount of time and ideally delivers a working increment by the end. Short daily meetings ensure that everyone is on the right track.

Downsides

Every process comes with its own downsides, Scrum is no different. Its biggest strength – having results and a working product early – also inherits a weakness: you’re encouraged to get stories done quickly and move on, which often doesn’t leave time for delightful details. Polishing happens to be neglected, which leaves parts of the product in a prototype-like state. Also, teams tend to over-commit in the planning, and the very rigid timeframe of a sprint forces you to cut corners at some point and leave stories in a less-than-desired state. These problems can be dealt with by creating follow-up, or dedicated polishing stories for the next sprint, but often they add up and clutter the backlog. Polishing and thorough planning of features just doesn’t happen naturally in this kind of process. It’s a constant weighting of speed against quality, and all involved parties need to understand the importance of avoiding technical debt.

Having people work in sprints and being busy their whole day on one project with a fixed goal to achieve also leaves little room for tasks outside of the project. Things like writing this blog post, open sourcing parts of your work, getting new colleagues up to speed, or finding time for professional development is difficult when you’re always booked 100% of your time. The solution to this is committing to fewer stories in the planning, but from my experience this doesn’t guarantee free time. Even if you try to keep a day reserved for other tasks, you’re still involved with the project, reading the team discussion on Skype, following Basecamp threads, or taking part in the daily stand up meetings. Scrum tends to absorb you 100% of the time and you gotta fight for slots away from the project.

An essential part of Scrum is getting people together and having fruitful discussions on various aspects of the project. This makes true remote work practically impossible, and we try to keep as many people in one room as possible. The daily stand up does work via Skype or Google Hangouts, but planning, review and retrospective are infinitely more effective when all parties sit around one table. Therefore, depending on the location of the client, we or they have to travel a lot to make these meetings happen.

One of our teams in a daily standup meeting, discussing the upcoming tasks for the day.

Clients are not from hell

Probably the biggest change in how we work lies in the role of the client. In our process we involve the client at all stages – from the obvious kick-off workshop to daily presence in the stand up meetings. This requires quite a commitment, but ultimately leads to a product tailored to the specific needs.

The pivotal role in shaping the project is the “product owner”, being in charge of the product vision and steering the team in regards to which stories and features to tackle next. Inherent in this role is fleshing out the backlog and making sure all needed information is available to the team. The ideal product owner has a deep technical understanding, as well as skills in negotiating solutions with the client’s stakeholders. We’ve had freelance product owners, as well as somebody directly working at the client’s company. This means all critical information about how the project is progressing is available to the client at any point in time, which brings us back to trust and transparency.

It’s no secret how many people and who exactly is working on the project, leading to realistic expectations of what can be done in which timeframe. The client does, and needs to take an active role in the process, and cannot lean back to get a product delivered in the end. This may sound tedious, but ultimately leads to much better results, helps us to manage expectations, and fosters respect for the team’s work. We see ourselves as partners, not suppliers and want to work at eye-level. This has led to intense partnerships in which all parties benefit.

Our lean device wall for testing, built from Lego blocks.

Team retrospective to figure out what worked and what needs to change.

Tools we use

There are tons of tools out there helping you to organize agile processes. Trello comes to mind, for smaller projects. With Ableton we used Pivotal Tracker which seemed intense and technical in the beginning, but succeeded in presenting lots of dense information in a very clutter-free way. ScrumDo, Jira and TinyPM are being used in various projects and all of them have their pros and cons. You won’t get around trying a great variety of tools to find the one best suited to your requirements and workflow.

In most projects we also have a physical board, mirroring the state in the digital tool of choice. The board enables you to understand the progress within a sprint, even at a quick glance while walking past it. Updating it may seem laborious, but especially in the daily stand-ups it’s easier to gather everyone in front of the physical board and talk about upcoming tasks together, away from the glowing screens.

Getting feedback from colleagues.

A quick meeting to overcome a challenge can save heaps of time.

Wait, there’s more!

So, there you have it. This is how we operate and build digital products. If this sparked your interest and you’re curious to know more, or have specific questions, feel free to contact us through the usual channels. Here are a few pointers to get you going:
– Agile: best way we ever worked
– Creative Mornings talk about our work with Ableton
– Book recommendation: “Do better Scrum”
– Teehan+Lax has similar insights: “Don’t go chasing Waterfalls”
– Scrum Master certification at DasScrumTeam

Also, Michael Börner and Christian Hanke will be talking about our process at this year’s Agilia conference in March.

Oh, and of course we are still looking to hire Scrum Masters in Berlin and Amsterdam: If you’re interested, look no further.