Beyond Tellerrand 2017

The four of us (Charisse, Jan, Paulo & Timur) arrived early for coffee. Right before the first talk in the morning we were welcomed by a very happy DJ. As it turned out later, he embedded snippets of the talks in his songs of vastly different genres in the breaks.

Over the course of the two-day conference there were a bunch of talks and almost all of them are available now on Vimeo. Most of them are quite good and worth watching, but we’ll go into details for the talks that we found to be most insightful, interesting and relevant to us.

IMG_4557

Robin Christopherson / Out with accessibility – In with inclusive design
Vasilis van Gemert / Exclusive Design

Overall, Robin Christopherson’s talk was a nice summary on why inclusive design is important. Not only people who are obvious to think of – the blind, the deaf, etc. – will profit from it, but also the “temporarily disabled” like the inebriated, people in a time crunch or or the temporarily incapacitated (such as those holding a coffee cup). I found it a bit sad to have to use this argument, optimizing for people with impaired vision should be reason enough in itself. But if it helps why not. He also took some time to explain how smartphones were a huge step for blind people and how excited he is about the next technological leap – voice interfaces. He’s so excited about that, he even got a podcast about his Alexa.

A good follow-up on the next day was “Exclusive Design” by Vasilis van Gemert, who turns the notion of inclusive design on its head. It begs the question: what would it be like if the users that are usually just considered as a technical requirement (“is is accessible?”) would be first-class citizen and get to enjoy their version of the user interface? An exclusive design?

Both talks made us feel somewhat ashamed – we admit we’ve got some homework to do in this regards at Small Improvements. We took it as a wake-up call and in fact made it an action item in our design meeting before carrying it over to our PM.

Yves Peters / Type with character(s) – reclaiming control over OpenType fonts

Peters took part in an open letter to Adobe in 2014 for better support of open type. The original implementation of Open Type in InDesign for example was more of a hackathon project than a well-planned interface. They were heard and now Adobe is actively adding better support for these fancy features. Google is also on board, with support for the latest and most exciting features – Variable Fonts. This enables fine-grained control over several variables of fonts: weight, slant, contrast, optical size, etc. This way request sizes can be minimized because you don’t have to deliver each font in a separate file. Second, you gain a lot of flexibility by not being bound to certain weights. Here at Small Improvements we always wished for something between Avenir Next Medium and Avenir Next Regular! He also shared an awesome website (axis-praxis.org) that shows these possibilities.

For now this still seems to be a thing of the future, but we’re hoping it gets the deserved momentum, and maybe we’ll see better support for all browsers pretty soon.

Alla Kholmatova / From Purpose to Patterns

What surprised us the most about this talk was the neutrality of it. Alla presented us with all things regarding design systems, living style guides, modular design and its pros and cons, but from the perspective of a non-biased researcher, not an opinionated “this is how you should do it.” That was pretty refreshing and particularly relevant for us as we’re now in the process of building our own style guide. She presented some case studies like AirBnB and TED, and how those different design systems fall into different ends of the spectrums – strict/loose, modular/integrated, centralized/distributed. As always, when you ask “what’s the best solution?” the most prudent answer is “it depends”. And that’s where it ended, also leaving us wanting to get her book “Design Systems” where she delves much more into detail, in the hopes of getting a deeper understanding of how we should move forward with our own style guide.

See you next year!

To recap, it was a good two days packed with interesting talks and a lot of ideas. It made us wish we’d have more time and resources to bring them all to our teams and to the things we’ve been building. It’s surprising how Beyond Tellerrand manages to have such a solid quality of speakers with subjects ranging from the freshest news in browser capabilities to the always inspiring career of Paula Scher..

How we develop software in teams

Here at Small Improvements we have 3 development teams. Each team is an autonomous unit that consists of frontend & backend developers, UI/UX developers and designers, so that they can build and ship features independently.

In this blogpost we want to share an insight into what the development process looks like in Team Green. We don’t follow any predefined scheme (like Scrum or Kanban). Rather, we pick the tools and methods that work best for us and adjust them constantly to our needs. Other teams work in a slightly different way, but the overall structure happens to be quite similar.

Iterations

The main building block of our team process is our weekly iteration. Unlike Scrum, these aren’t sprints: it’s not our primary concern to deliver exactly what we had planned, they rather act as a central clock that give us recurring temporal structure.

 

out iteration flow

Weekly planning

Each iteration starts on Tuesday morning with our weekly planning meeting: we sit together as team and review the last iteration in order to clean up leftovers from the last week that need to be taken over. Afterwards, we fill the upcoming iteration with tasks from our team backlog until we feel that we have found a good scope. Usually, we tend to overplan slightly, so that nobody runs out of work. (Read the section about backlogs to find out how we know what to work on next.) Estimations help us to find a meaningful size for our tasks, but we are not too strict about them: we aim for high throughput, but still value quality over delivery dates.

Retrospective

We are doing retrospectives on a fortnightly basis. They last one hour and are a place for discussion about our workflow and process. Everyone can talk about their thoughts as long as they like. However, we don’t just aim for good conversations: our goal is to identify actionable things that we can improve on until the next retrospective. We don’t want to change everything at once. Our philosophy is continuous improvement through small yet steady steps. Our retrospectives are facilitated by one team member, who is in charge of preparing, moderating and documenting the meeting.

All-Hands Meeting

Every Tuesday evening the entire company comes together for an all-hands meeting, including at least four of our employees who are regularly working from different time zones. Every team (not just devs, also marketing, customer success, etc.) reports their progress from the last week and announces their agenda for the upcoming week. Thereby we are making sure that everyone is up to date on what’s being worked on at the moment. In contrast to a sprint review, this meeting is not about giving account. It’s rather a window in time, where every team shares insight into their current status.

Long-term planning

Roughly every four weeks we conduct a long-term (or monthly) planning to stock up our team backlog and discuss our roadmap in the long run.

Team backlog

We have mainly four sources of work that supply our team backlog.

 

sources

Product and feature work

We have two dedicated product managers who maintain a product roadmap, where tasks and stories are prioritized and broken down into smaller pieces. Every developer is actively involved in product development, but our PMs do a lot of organization and planning upfront, which is a great relief. Every dev team has a designated Feature Coordinator who constantly stays in touch with the PMs and arranges meetings and conversations when needed. Together, we prepare features ahead and make sure that – once we start to work – everything is right in place.

Tech work

Another big source of work is our tech roadmap, which is a joint venture from all developers. The tech roadmap usually contains refactoring and innovation projects that don’t necessarily create immediate customer value. We discuss and prioritize these projects together in our weekly Dev-Exchange meeting. As examples, we recently had:

  • Migrating our backend authorization logic to a predicate-based framework written in Groovy
  • Making further progress with our Angular-React migration: one step was to introduce React Router 4, which we did a couple of weeks ago
  • Building and launching a dedicated microservice that renders auto-generated user avatars for all users who didn’t upload an individual avatar yet

Apart from the tech roadmap, we also have a biweekly DevOps meeting. However, since we are hosted on Google App Engine, we are usually not too concerned with DevOps tasks so the workload varies a bit in that respect. That being said, we still have some fun tasks on our current agenda, such as dockerizing our local development setup.

Design work

All designers and frontend-addicted developers form a so called “meta-team” that comes together every week for a design meeting. This yields smaller tasks such as the overhaul of graphics and icons, but they also work on bigger projects like revamping our style guide. Lucas (our UI/UX developer) usually brings tasks from the design meeting into our iterations.

Side projects

Apart from these three bigger backlogs, we have some smaller sources of work that can be summarized as “side projects”:

  • Every employee at Small Improvements is encouraged to take time for personal development. (In Team Green we believe heavily in manifesting our personal goals with Objectives). If someone wants to take time to make progress with their Objectives, they are free to file a time slot in the iterations. For instance, Sharmeen is currently on her mission to increase awareness about possible vulnerabilities so we can maintain the security of our application, and recently wrote a security-oriented development guideline for the backend.
  • Usually, there is always room for small spike and innovation projects in order to explore new technologies and ideas. As an example: a couple of weeks ago, Jan set out for one day to try out flow type annotations in our frontend code. In the end, we decided against it, but the experiment served as basis for a valuable discussion.

Bringing it all together

The interesting question now is how these backlogs are balanced: the answer might be a bit disappointing, since we don’t have a secret formula that tells us where to pick from next. In fact, the team roadmaps are a matter of ongoing negotiation between all involved parties. Sometimes it makes sense for a team to take over a task because they already have expertise in that area and can deliver outcome fast. Another time we decide to assign the same project to a different team, because we think that it’s a valuable opportunity to share knowledge and prevent silos. Small Improvements is still a comparatively small company, so we don’t need formal processes and heavy decision-making hierarchies. Most of the time we can figure it out by just talking to each other, which is a great privilege. 

FIZD7068

The current state of DevOps

In course of the DevOpsDays 2015 in Berlin, Small Improvements is going to host a Docker meetup with John Willis of Docker Inc on October 26th!

John’s presentation covers the current state of the DevOps movement as presented by one of the original “Core Organizers” of the movement. The presentation will look at some of the taxonomies that have been used to describe DevOps such as CAMS and ICE. It will also cover the recent 2015 Devops Survey and we will end up with a discussion about how DevOps is being adopted in the enterprise.

Though the event waitlist is already packed, you can still try to visit our office – only if it becomes too crowded, we’ll have to give the Docker Berlin members priority. The event starts at 6:45pm, all details can be found on the Docker Berlin event page.

Meet us at Berlin Expert Days

It all started way too early for our taste, but we made it to Berlin Expert days in time! We’re looking forward to the talks, and to meeting tons of nerdy Java developers! If you have any questions about our job offers, don’t hesitate to bump into us. Spot us by looking for our T-Shirts, ping us at @smallimprove, or attend our Friday morning talk by Per.