THE DEVELOPMENT WORKFLOW OF DriveNow

Henrik Mitsch from DriveNow, a German car-sharing company owned by BMW and Sixt, sat down with me and we talked through their challenges when developing the software behind carsharing and how their development workflow looks like.

DriveNow BMW i3

Please tell us who you are and what you do, Henrik!

Hi, I am Henrik, Head of DriveNow IT at Sixt. My main responsibilities include business/technology alignment, secure stable operations and make sure our software developers have everything they need to make an outstanding job. Before joining Sixt I was a consultant at Accenture, working mainly in the telco industry. This is where my exposure and hands-on experience with Agile in big and small environments started and it is continuing ever since.

Can you tell us a little bit about DriveNow?

DriveNow is premium, flexible car sharing by BMW and Sixt. We operate various MINI and BMW models including the BMW i3. These cars are located via an app, and can pick them up and return anywhere within our business area. This is a very technology-dominated service offering. For this reason, our product and software development teams are closely knit together in order to deliver a high value product.

How is the company and the team you are working with structured?

We are a product organization of approximately 50 people spanning product management, UX, business engineering, software development and DevOps. The team is distributed among two locations and split into several cross-functional entities, each following agile methodologies (Scrum and Kanban).
We observe multiple clock-speeds in our organization. Sometimes features go from ideation to production in a few minutes, in other instances rigorous planning and alignment with third parties might result in a months-long delivery cycle.
In order to stay on top of the many product initiatives which concurrently run through our organization, we use Blossom’s software to manage our “operational release planning”.

Lots of feedback cycles, cross-functional delivery teams and a continuous strive for lean product management principles help us keep an agile spirit along our journey.

How do requirements come to your team and how do they progress through your company?

As DriveNow is a growing business, there are a multitude of entry channels for requirements. About a year ago we have analyzed our value chain and mapped it onto a Kanban board using Blossom. Since then it has been iteratively refined to make sure it maps out our actual flow.
Incoming requirements are captured in an “Alignment required” column. This is the triage point for our product management and business engineering people. We inspect this column at least once per week and together decide on ownership. From there our requirements take a rather standard path: specification, solution architecture, implementation, testing, deployment. Sounds like a waterfall? Not so much! Lots of feedback cycles, cross-functional delivery teams and a continuous strive for lean product management principles help us keep an agile spirit along our journey.

The DriveNow iOS App

What tools (Project Management, Issue Tracker) help you deliver your product and why?

As we have been on the road for a number of years, our tooling landscape is quite diverse.
We are heavily invested in the Atlassian stack for ticketing (Jira Service Desk), development (Jira), requirements wrangling & living documentation (Confluence), and communication & ChatOps (HipChat). Code lives in git with beautiful continuous integration and continuous delivery tooling crafted around it (Hi Jenkins!). Ops tooling is following Etsy’s “if it moves, graph it” philosophy with ELK (Elasticsearch, Logstash, Kibana), Instana and Pingdom at its core.
Finally, ideation and themes are handled in Blossom. We are currently experimenting with the best way to handle our product roadmap and are using OKRs for that matter.

Are there any tools missing from your setup?

Our motto is “people – processes – tools”, in that order. We know that people go first. Next we help them understand value chains and identify appropriate processes. Ultimately, we have a look at supporting tools.
Right now, our team is going through a “norming phase” so we have to evaluate the impact on processes and tooling as we move along.

Do you have a methodology for evaluating the impact of processes and tooling which you are doing right now?

We really like using Mathias Verraes’ “Small Uncontrolled Experiments framework“. The basic idea is: We run an experiment and see how it works after a few days. This is also how we introduced Blossom into our operational release planning process.

The DriveNow Team working in their office in Munich, Germany

When you use the Small Uncontrolled Experiments Framework, how do you evaluate the success of an experiment, especially with tools and processes that might take a longer time to show their real value?

For such cases we rely on an „experiment board“ (i.e. another Kanban board). This is where we keep track of our experiments (Backlog, in progress, done). Such a board allows us to keep track of experiments running longer than our two week sprint.

Agile is hard because it requires you to question yourself every single day (Kaizen), move the conversation from features to purpose (remember Daniel Pink’s Drive), and apply systems thinking to (almost) everything .

How did your development workflow evolve over time?

We have been on the road for more than four years. During this time our product development workflow has evolved substantially. In the early days we were very plan-centric, which certainly was the correct thing in the beginning. Over time, we adopted more and more empirical and lean practices across our entire value chain.

What are your plans to evolve your development workflow in the future, if any?

As our understanding of agile product discovery and delivery matures, our workflow will eventually evolve. OKRs help us to get broader organizational alignment of product goals. This is surely something we will keep iterating on.

The monitoring interface for the DriveNow infrastructure

Thanks! Anything missing you want to point out?

Agile is hard because it requires you to question yourself every single day (Kaizen), move the conversation from features to purpose (remember Daniel Pink’s Drive), and apply systems thinking to (almost) everything . Blossom’s Kanban tool provides us with a beautiful and simple landing base along this slippery slope. Keep it up!

Staying lean is a demanding endeavor, as many  organizations know. Putting people first and making sure the whole team keeps agile principles at its core seems to help a lot. This makes moving fast possible and, as DriveNow shows, is also suitable for highly reliable products. Keeping in mind that moving fast doesn’t mean skipping the planning. This is important as well, especially when introducing agile methods into your organization. 

The post Development Workflow by Example: DriveNow appeared first on Blossom.

The development workflow of Liechtenecker

For this part of our blog post series, I talked to Christoph Rumpel from Liechtenecker about transforming from agency to a more product focused company. Christoph is a developer with a lot of energy and an open mind, always eager to improve as well as getting others to improve as well. 

Christoph working in the lab

Christoph, please tell us who you are and what you do!

Hey everybody. My name is Christoph Rumpel and I’m a developer at Liechtenecker, a lab and studio for digital innovation based in Vienna. Coding PHP is what I do most of my time and what is actually my profession but in a small team you need to come up with the whole dev package.
I care a lot about our web and the community around it and I like it when I can contribute to make it becoming a better place everyday. At Liechtenecker I’ve found a perfect place for me to do so.

Can you tell us a little bit about Liechtenecker and your transformation to a Lab at Liechtenecker?

Liechtenecker has been a digital agency for 10 years now. We did all kind of digital projects like you will find it in lots of agencies. We were very successful in what we where doing but especially in the last years we felt in our hearts that there was something missing. We are a bunch of creative and motivated people and we wanted to be more than just a supplier. We wanted to be a real professional digital studio that acts as a real sparring partner for our customers with the aim to make awesome digital stuff that changes something bad to something really cool. The focus is always on the user.

This was when we decided to stop being a traditional digital agency and when we started our Liechtenecker Lab. It is not just a different name. It is a signal for us and everyone out there that we have changed the way we work and think. It was a one year process and we had to say goodbye to some of our customers because they didn’t fit into our new perspectives. If you want to work with Liechtenecker today, you should be prepared to get a real sparring partner that cares about the products more than about the money.

Christoph Rumpel from Liechtenecker

One great aspect of our transformation is that it always was a team decision. We all felt the same pain and we all decided together what aspects needed a change. This is really important because it does not work if just one tries to force the change. At the beginning we didn’t quite know where our journey would take us, but now it is so much clearer for us and now was the time when we relaunched our own website to finally make it public.

Another important step was to start building our own digital products. This is so much different from working for someone else and it helps a lot to learn about a product life cycle process. It is something we need to know about in order to help our partners and of course it is a lot of fun for all of us too.

How is the company and the team you are working with structured?

We are a small but flexible team of 10 great personalities. In our development team we have two backend programmers and two front-end guys. We do not want to grow too fast, because we really care about being a little family. The quality of it is really crucial to us and we want everyone to be involved in the whole project and not just a part of it. We all have great ideas and we need to benefit from each other.

So these days you are doing more long-term projects focused on quality, if I understand correctly. Are those solely projects for customers or do you have own products (or ideas to develop own products) as well?

Yeah that’s correct. Only with long-term projects you are really able to understand and help your partners. But besides them we are working on our own products too. This is how we are able to easily experiment with new technologies and tools and gain further experiences to make our skills more powerful. Wuzzlio is one of these products. It is a very cool and comfortable tool to manage foosball games. We at Liechtenecker love it to play foosball! Since the beginning of the company it is a big part of our culture. It was only a question of time until we decided to create a lovely tool that manages all our games. Now we want to provide others with the same great experience. It is really crucial that you use your own products too in order to understand the needs of the users.

Working on the new Hype Compass

Besides Wuzzlio we also developed two other tools. One is called Favor and is an experimental browser extension. The goal is to create surveys that have an entertaining character and collect user data in a very simple way. The other one, Random Oracle, helps us to quickly select random teammates for daily tasks like empty the dishwasher, go shopping for lunch or anything else you can think of.

Right now we are working on some big new Lab projects which go beyond our software skills. Digitalization is so much more than just designing and coding and therefore we wanted to spread our skills. IoT is a big part of that. I wish I could tell you more but right now I just can say that it will be about sound visualization, air gestures and 2000 LEDs.

How do requirements come to your team and how do they progress through your company?

From the beginning of every project everyone of our team is involved. This comes down to an UX designer, a developer and a project manager. I guess everybody knows by now how important it is to keep everyone involved from the beginning. Waterfall processes are dead. If you’re not agile you’re too slow and inflexible and this doesn’t fit into our industry. But back to the question. After the first meetings and workshops we use daily standups to organize our internal todo’s. It’s a part of SCRUM that works really good for us.

What tools (Project Management, Issue Tracker) help you deliver your product and why?

Basecamp is our project management tool of choice. We’ve been using it now for many years and we are very satisfied with it. But as always it depends on many factors. For us it depends on our partners, their tools and the size of the projects too. JIRA is also a tool you will find in many of our projects and we like to use Google Drive for all kind of scenarios.

There are a lot of tools that help us work clean and fast like Git and Bitbucket, Vagrant, Gulp, Laravel or Angular to mention just some parts of our tech stack. Tools are important but you always have to rethink your chain. Every tool binds you more to your setup. It’s about the right amount and what fits best to the needs of your team.

The Liechtenecker Team

Are there any tools missing from your setup?

That’s a tough one. Right now I wouldn’t say I am missing something but I know there are always ways to improve the setup. I also think you have to work on your setup permanently because it is a never ending process. Technologies, software, and people as well, are constantly changing. You need to see these changes and be able to adopt your system. But in the end it all comes down to helping your team doing a better job. It’s like a framework that helps you to focus on the business problems instead of the programming language basics.

Let’s get back to the development workflow: How did your workflow evolve over time?

Ok let’s have a look. In the past we did a lot of different projects of all sizes. We did knew about Git but barely used it. So the basic workflow was asking if anyone else is working on file X. If not, you were able to edit and upload it via FTP ? . Of course you didn’t want the client to see your changes or var_dump tests immediately, so you would check for the IP in the code. I guess these were the days of cowboy coders.

These days are definitely over. Today we wouldn’t start a project without using Git. It’s a no brainer and it gives you so much power and control. Of course it could overwhelm someone at the beginning but it is a tool every good dev has to get familiar with. In most of our projects we use a feature branch workflow. Everything is developed in separate branches. For us it is enough to distinguish between a feature and bugfix branch, next to a production and staging branch. Once the work is done and the tests are green we merge the branch and push it to a staging or live server. This depends on the project and the client. As I mentioned tests are very important for us too. I would lie if I said we write tests for all of our projects, but we do for most of them. This is also something that depends on the project. For product-like projects like Wuzzlio it is clearly great to have lots of them because they make me sleep better at night ?.

Deployment is another topic where we have various workflows. Some of our clients have their own hosting provider where we depend on their setup. But for our latest products we have separate server droplets where we are taking care of the whole provisioning part too. This is great because this way we are able to test new stuff like PHP7 and HTTP/2, as we do on Wuzzlio. To deploy we basically just use SSH and Git. It is simple but convenient. Tools like Laravel Envoy help us to automate these tasks.

What are your plans to evolve your development workflow in the future, if any?

Now that we are concentrating on bigger and long-term projects I guess we will take a closer look at Continuous Integration and Continuous Deployment. I always like to automate as much as possible and a better deployment workflow will definitely be something the whole team can benefit from.

Discussing new ideas

Thanks! Anything missing you want to point out?

Maybe just a little reminder for every developer out there that we are responsible for what the web will be in the future. Let’s build things to last and products that really enhance the user’s life. I know it’s hard but we are capable of making the web even better and it will be worth it. Finally I just want to say thank you for this great interview and it’s awesome to be part of this blog series.

Change doesn’t happen over night, but if a team is dedicated to make it happen, you can be sure it’ll find a way. Thanks to Christoph for these great insights into an evolving company. I like the theme of doing one step at a time a lot. Recognizing your weak points can be demoralizing when you realize there are a few of those. But you will only get better if you start with what you have and improve continuously.

Checkout their latest project What The Feeling, an interactive map showing Twitter emotions from the European Football Championship in real-time.

The post Development Workflow by Example: Liechtenecker appeared first on Blossom.

The development workflow of Codeship

For this interview, I had the opportunity to talk to Florian Moltik, Co-Founder and CTO of Codeship. While managing a fast growing engineering team, Florian still tackles the small bug fixes and helps out different departments when needed. Describing himself as the “Jack of all trades” at Codeship, he shares his knowledge whenever possible.

Florian, welcome! Please tell us who you are and what you do!

I’m Flo, the CTO and one of the founders of Codeship (Together with Manuel and Moritz). As CTO at Codeship I’m basically helping out in many different ways. From implementing small fixes in code that I’ve written a long time ago to helping with Marketing, Sales, helping guide our engineering practices or Customer Support. I’m basically a Jack of all trades here at Codeship.

I also write regularly on our Codeship blog and give talks from time to time about Developer Productivity, Engineering Workflows and how to build infrastructure.

Can you tell us a little bit about Codeship?

Codeship was founded in late 2010 to help teams be more productive by taking away the need to build your own Continuous Delivery infrastructure. On our service you can run your tests, but also deploy into production. We support tons of different technologies so you can get all of your builds working.

How is the company and the teams you are working with structured?

We’re currently 18 full time people and several Freelancers. We started in Vienna, but moved our Headquarter to Boston. In 2013 we took part in the Techstars Accelerator program in Boston and we all moved to the US for a while (we moved to Berlin a couple of months before that). We still have our office in Vienna, which I run, and have remote people in Berlin and Austin at the moment.

The Codeship web interface

We’re definitely looking to grow in the future as well and see remote work as an important part for growing our team. But by having 2 offices in Vienna and Boston it’s also easy for us to fly remote people into those locations regularly so they can meet up with the whole team on a regular basis.

As you have people remote: did you start working with people in different places than your headquarters because you couldn’t find the right people near your offices or do you think there is more value to a remote workforce than “a bigger pool of talent”?

Both. At first we weren’t able to find the right talent only in Vienna or Boston, so we decided we wanted to basically start looking everywhere. In the end the most important question when hiring a new Person is the quality they bring to the company. Everything else is secondary and can be figured out. If we build a team that is fully focused on getting high quality engineers and we can set up a structure that allows for them to be productive in working together we can have a much better long term result.

We’re definitely looking to grow in the future as well and see remote work as an important part of growing our team.

How do requirements come to your team and how do they progress through your company?

New requirements typically come from 3 different areas:

• Customers talk to Support and let us know what features or improvements they might want
• We’re talking internally about the next steps our platform should take and where we want to get the company to
• We talk with partners about potential integrations and features we can build in the future

Alex, our head of product, then takes all those suggestions and discusses with various people in the team their view on the importance of specific tasks. That then leads to our timeline and those tasks are then picked off by engineering and worked on. We have a weekly team call where we present next tasks, status of the tasks and future product direction.

Florian discussing on a Team Building Event

What tools (Project Management Tools, Issue Trackers) help you deliver your product and why?

We use PivotalTracker for managing all of our tasks in the engineering team. Other teams use various other tools (Salesforce, Trello, …). Once a developer wants to release something she opens up a Pull Request and we can have discussions about that PR on GitHub. Then obviously we’re using Codeship extensively to deploy our applications.

We have to do quite some work to get the different tools working together and data available to everyone on the team.

Are there any tools missing from your setup? Maybe there is a gap somewhere which makes things uncomfortable or unproductive?

Yes, making those tools work together is still not easy. We have to do quite some work to get the different tools working together and data available to everyone on the team. But just for the development workflow we’re pretty fine at this point.

How did your development workflow evolve over time?

As we’ve grown the team, the processes definitely changed a lot. Its much more formalized now than it was in the past. We do weekly sprints and features get discussed with many people before they are put into the timeline. We really try to think very hard about the features, talk to customers and really make sure we nail it early. Of course you want to move fast as well, but that’s the tradeoff between moving fast and still shipping features.

Make sure there is no loss in focus from anything and you’ll get way more done in your engineering team.

What are your plans to evolve your development workflow in the future, if any?

We’re definitely going to grow the team, probably splitting it at some point. We will have to figure out how to manage that in the longer term. We definitely want to keep all the automation that has helped us so far and extend that even further so that we can make sure that even though we’re growing our engineering team, the team can still focus 100% on the most productive work.

Thanks! Anything missing you want to point out?

I’m working with many engineering teams and one of the biggest problems I see again and again, especially in small teams, is the missing focus on making your team as productive as possible in the medium or long term. Automating everything in your stack so scaling, health checks and replacing faulty parts becomes automated is such a boost to productivity that you have to do it. You can’t afford having your developers do small tasks to keep the system running every day as even small tasks take so much time away from getting something productive done. Make sure there is no loss in focus from anything and you’ll get way more done in your engineering team.

There is a lot of content within these answers. Thanks to Florian for taking the time and making it possible to get some idea of how a growing startup works on the inside and how the development workflow looks like for Codeship. There is a lot of value in having a Head of Product who is responsible for the product at large and talks to everybody involved. Unfortunately, it’s common for the product team to only fulfill a wish list of feature requests. This time-sink can pull the team away from developing value for its customers and is something we should all try to avoid.

If you want to work at Codeship, make sure to check out their current job openings!

The post Development Workflow by Example: Codeship appeared first on Blossom.

There comes a point when you have to stop. We’ve all been there before. Sometimes it means your product strategy is saying “no”.

via Intercom

Obviously, saying “no” can’t be your only strategy. There’s a balance to maintain between adding new features, culling old ones and explaining how they all fit together.

To get you kick-started, we’ve collected four techniques to help you reduce feature bloat in your product:

1. Conduct a “Feature Audit”
2. Ask the question: “Does the feature fulfill a customer goal?”
3. Align features to your company’s vision
4. Are you making decisions that benefit a ‘loud few’ or the ‘majority’?

1. Conduct a “Feature Audit“

First, you can increase adoption and/or frequency of use of features with low adoption / usage frequency.

Be cautious if you’re trying to optimize these levers for every feature. Not all infrequently used / low adoption features are low value and can be perfectly fine as-is.

For example, an ‘updating account information’ feature — it’s infrequently used by all, but still necessary.

2. Ask the question: “Does the feature fulfill a customer goal?”

Arguably, the most important part in reducing feature bloat.

If you define the wrong goal, even a great team will develop a slick, fast and ‘cool’ feature which no one uses and/or wants.

How do you avoid it? Look into the motivations, situations and context of your customers. Not just the solutions. They come after. Job stories help with defining these.

• Job stories are like the context behind personas. While a persona might describe a person (which helps to form context), a person’s situation and motivation(s) when they’re engaging with your product could be completely different to their description of themselves or how they usually act.
• For example, someone who is usually a healthy eater (persona) might be tempted to eat unhealthy fast food because they don’t have much time to spare and need food that is energy dense (situation + motivation).

“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” — Theodore Levitt

3. Align features to your company’s vision

Let’s look at Twitter’s vision:

“Twitter is your window to the world. Get real-time updates about what matters to you.”

One glimpse at this and it becomes obvious why Twitter haven’t lifted their 140-character tweet limit (yet). It’s not because they can’t. It’s because if they did, people would communicate in way that isn’t in “real-time” on Twitter. You can’t type essays on the fly about world events (and if you wanted to, there’s other platforms for longer-form writing, e.g. Medium).

Make sure to stick to your product’s vision or it won’t be clear who your product is for.

4. Are you making decisions that benefit a ‘loud few’ or ‘the majority’?

It’s not your job to make everyone happy. Of course, sometimes it will make sense to, but it needs to be blindingly obvious.

To get your ‘objective’ mind on track, you should be answering no to these kinds of questions:

1. Would you make your product free if 10 customers loudly complained that “it costs too much”, in contrast to 1000s of happy, paying customers?
2. Would you develop a feature because 10 non-loudly complaining customers asked for it?

If you have any other techniques to prevent feature bloat, we’d love to hear about them in the comments below!

The post Feature Bloat – The Silent Epidemic appeared first on Blossom.

To copy a card to another project board, first open the card, then click the triple dots in the top right corner, click ‘Copy this Card’ and select which project board you want to copy it to. All of your card’s details will transfer across to the other board, automatically.

Here are some ways you can make card copying work for your team:

• Product teams: Move cards from your idea collection board to your development board when they’re ready to be worked on.
• Agencies: Have one board for your clients and another for your internal work.
• Software teams: If a released feature has a bug, copy across this feature to a bug board to maintain context.
• Personal kanban: Copy personal tasks over to a team board when you need your team’s help.

If a different workflow works for your team, we’d love to know in the comments below!

The post Copying Cards in Blossom appeared first on Blossom.

The development workflow of Usersnap

This time, I talked to Thomas Peham from Usersnap. Thomas is responsible for the marketing at Usersnap and works with all the different departments. He cares a lot about all the small details that matter when you are building a product. In addition, he is a very visual person with a hands-on mentality!

Please tell us who you are and what you do!

My name is Thomas Peham and I’m running marketing at Usersnap, a visual bug tracking & feedback tool. In my day job I’m managing Usersnap’s marketing efforts which mainly consist of inbound marketing. Since we’re quite an agile team, my role not only involves various marketing activities, but also some involvement in the product and customer support team.

Besides that I’m also responsible for managing bugtrackers.io, which is a side project of Usersnap where we show-case the life of people in web development.

Can you tell us a little bit about Usersnap?

Yeah, sure. Usersnap is a visual bug tracking and feedback tool for every web project. Usersnap creates screenshots of the current browser content. It helps you to communicate effectively about issues and share feedback between developers, customers and everyone involved in a web project.

With point and click issue reporting tracking bugs was never easier. Screenshots, the used browser version and a lot of additional information help you to solve every web issue faster. We currently offer 20+ integrations with leading project management tools, customer support software and chat messengers. Therefore, you can enhance your bug tracking & feedback experience.

The idea behind Usersnap resulted from our daily work in developing web applications where we faced different communication problems. The product emerged from our vision to make web development more efficient and pleasant. Since not finding any existing solution on the market and seeing the potential of a visual bug tracking tool we started to build Usersnap in early 2013.

First of all, we try to live up the “release early, release often” paradigm. This mainly means that we established an open-minded culture in the way we work.

How is the company and the team you are working with structured?

Usersnap was founded by Florian Dorfbauer (CEO), Gregor Dorfbauer (CTO) and Josef Trauner (CPO). Today we are a team of 9 people working at Usersnap and we’ll add new people to the team (make sure to check out our current openings). We are structured along the following areas: development, UI / UX, product, marketing, customer success and business development.

How do requirements come to your team and how do they progress through your company?

That’s a great question. I think there are a lot of touching points when it comes to product requirements. I would distinguish between internal requirements (coming from inside the teams) and external requirements (addressed by customers, users or other stakeholders). We try to do different things when dealing with those internal and external factors.

First of all, we try to live up the “release early, release often” paradigm. This mainly means that we established an open-minded culture in the way we work. Basically, everyone at Usersnap is encouraged to not take every product feature for granted and consider it from different viewpoints.

Other than that, talking with our customers and users is key. By building sustainable relationships with them (mainly through emails) we always try to be at the sweet spot of current problems and challenges.

When adding more people to the team and scaling up your tech stack, your workflows also need to adapt.

Can you go into detail how requirements progress within our company?

The main thing is that we try to follow the “jobs to be done” framework when it comes to releasing new product features. We always ask the question “What’s the job of our product / feature / etc?”

Happy customers are probably the most valuable thing. Though there might be suggestions or feature requests which are not matching our product vision. We believe that adding new “invisible features” gives us the possibility to keep a close relationship with our users.

If you ask me on our development workflow, I’d probably draw something like this:

What tools (Project Management, Issue Tracker) help you deliver your product and why (I guess Usersnap is part of that setup)?

Our product team relies on a product roadmap, which we call a feature matrix. This matrix includes all features that we or any user would like to see in our product. Though this sound complicated, we use a simple Google Spreadsheet for this feature matrix. Beside that feature matrix, we use a couple of internal tools making communication and life in general easier. We mainly call Slack our home, since it enables us to communicate throughout the company.

For “managing new projects” we actually rely on Blossom & Usersnap:

• Blossom enables us to get an overview of the bigger picture. For example we have a Blossom board for our product which gives us a great overview on the current state of new requirements.
• Usersnap, our own product, lets us manage all product ideas, improvements, bugs or simply customer feedback. We store, discuss & share everything inside Usersnap.

What other tools complete your setup?

I think I mentioned the most important ones. Besides that our tool stack relies a lot on Google Apps (Mail, Drive, Google Forms for collecting feedback, etc.) and as a distributed team we live inside Slack, Skype and Google Hangouts. Other than that, I’d love to mention InVision and Usersnap, since both of them made our feedback loops super lean and efficient.

Do you feel that there are tools which would make your process for managing Usersnap even better?

That’s a great question, since we at Usersnap are always looking for new ways and workflows in order to be more productive.

Right now we are evaluating our tech stack in order to find various ways on how to release new landing pages and our website faster. We already took a closer look at static website generators, such as Hugo, and we’ll definitely put some additional time into this topic.

I’d like to highlight the importance of a proper bug tracking & feedback workflow, since this is probably one of the most overlooked area in web development.

How did your development workflow evolve over time?

When adding more people to the team and scaling up your tech stack, your workflows also need to adapt. I would say we learned a lot about scaling up our cloud infrastructure. Providing a fast & reliable user experience is key for any web app. With Usersnap we want to provide the best bug tracking experience available.

This required us to put a lot of thoughts into our infrastructure.

AWS, for example, enables us to host and run our web apps as well as performing massive high-performing batch jobs. With Elastic Compute Cloud (EC2) AWS provides scalable virtual servers for every business.

(c) Flo Huber Fotografie

What are your plans to evolve your development workflow in the future, if any?

As mentioned, static site generators are now something we’re looking into. Further on, we’re always re-thinking the way how we use certain technologies like RabbitMQ, or MongoDB.

As a growing startup we are continuously thinking about new ways on how to be more efficient. Adding new people to our development team also requires us to rethink how we work and which work must be done differently.

DevOps for example is another topic which becomes increasingly important when you grow. Looking into monitoring tools for our app will be on our agenda pretty soon.

Thanks! Anything missing you want to point out?

I guess I’ve already shown you the in’s and out’s of our web development workflow ? Besides that I’d like to highlight the importance of a proper bug tracking & feedback workflow, since this is probably one of the most overlooked area in web development.

Some great insight from Thomas into a growing startup there. I like the exploration they are doing with new tools and it looks like they are trying really hard to incorporate the best tools out there into their development workflow in order to ship an outstanding product. Given they are only a small team, it’s especially important to automate all the things possible to not have people doing busy work. Thanks to Thomas once again!

Check out their current job openings to join the great Usersnap team!

The post Development Workflow by Example: Usersnap appeared first on Blossom.

The development workflow of Die Socialisten

For this first part of the series, I talked to Johannes Nagl from “Die Socialisten“, who are behind Swat.io and Walls.io. Johannes is a very invested CTO who made the transition from agency developer to managing a product team. He isn’t afraid of big changes and while he keeps a high-level overview, he’s still down in the trenches doing development every day!

Johannes, tell us who you are and what you do!

Hi, my name is Johannes and I’m CTO of “Die Socialisten”, a Vienna-based Social Software development agency. We used to be a very classic agency, but in the last couple of months we have evolved to a “modern” SAAS-startup. Although our field of activity is still the same (Social Media, Facebook, Twitter, …), our internal development paradigms changed totally. I’m in web-dev for almost 16 years now and it was never more exciting to create web apps than today.

Can you tell us a little bit about “Die Socialisten” and swat.io/walls.io?

“Die Socialisten” is a relatively small software agency in Vienna, Austria. We’re Austria’s only Facebook Marketing Partner and very well known for our deep knowledge about Facebook and the Social Media scene in general. A couple of years ago, we decided to start more complex software products for partners of us. The feedback was so positive and the market potential so big that we decided to standardize these products over time and jump even more on the SAAS-train to focus on these products. While Swat.io is a Social Media Management tool for teams, where you can manage your published content and your community for all major social media networks, Walls.io is more of a social media aggregator for displaying live-activity for a specific hashtag. Both products share the social media aspect but have different target audiences. Swat.io is used in many companies over years, while Walls.io is often a one-time-shot for events.

Establishing these workflows is really important and every time we did something wrong we reflected on our workflows and introduced something new.

How is the company and your team structured?

Our company consists of ~12 employees, mostly dev related. We have no big hierarchies or management overhead, almost all of our team mates (including our CEO) are directly involved in improving our products. The dev-teams for Swat.io and Walls.io are decoupled but share sales, customer success and product managers. In our working environment speed is everything – using multiple external APIs is always a bit tricky and changes to these APIs happen very often, so we try to push changes on a frequent basis (multiple releases per day). To be able to deploy often, we have to reduce the size of each work package to a minimum. For Swat.io, we end up with ~50 issues/bugs/features a week the development team has to take care. This is why we use Kanban since the beginning for both projects. In a weekly kick-off, the development team tries to prioritize our Kanban board, so every team mate is able to pick new tasks on his own.

Could you go into a little more detail on what changed when you moved from agency to SaaS provider?

Almost everything changed for us. We used to build one-time-shot marketing apps with a campaign run-time of 4-8 weeks. Although quality of these apps was one of our USPs, we had to change our mindsets completely after moving to the SaaS business. We do not make any projects any more, we do products. So every code we write should have a half-life of many years now. Code Quality, Coding Guidelines, Code Reviews, Pair Programming. This is all happening now on a daily basis. Establishing these workflows is really important and every time we did something wrong we reflected on our workflows and introduced something new.

How do requirements come to your team and how do they progress through your company for one product like Swat.io?

Well, there are three different areas of origins. First, our most important channel for new requirements: Our customers. We really love to get feedback from them and try to solve their needs (not always the same as their ideas ?). Most of the time these requirements are easy to implement, so we try to fulfill these very fast. Second, there is our very own roadmap, where we define where we would like to head to. Michael, our CEO and product manager of Swat.io comes up with quite some challenging tasks all the time. We try to keep our roadmap agile and limited to a maximum of 3 months. Although we know there are tasks in the mid- and long-term, we also know that it does not make sense for us to plan longer than 3 months. Our market is too fast and changes happen very often. That brings me to the third source of requirements: External sources like social network apis. If Facebook introduces a new API, or there’s a new hip social network introducing an API, we need to catch up with this very fast. And of course, there are a ton of API bugs we encounter every week, so our weekly sprints are often disturbed with small bugs. Hey, nobody ever said, it would be easy to talk to ~15 apis concurrently ?.

Our approach is very agile so we test some tools and if we like them: boom, they make it very fast to master/production. If we find something better, then we switch tools quickly.

What tools help you deliver your product and why?

GitHub is currently our one stop shop for all information regarding development tasks and roadmap. We store every Kanban todo as a GitHub issue. GitHub is good for storing and referencing these tasks from the code base, but it’s really bad in visualizing these issues. So we use Waffle.io on top to visualize the tasks in a Kanban-style board. As mentioned earlier, code reviews help a lot to deliver the product in a much more stable condition. As external bug tracking / issue management tool, Intercom helps us a lot! We installed the widget almost 2,5 years ago and since then our customers love us for our quick replies to any questions. Intercom is really great in getting almost any information you need (which user, which browser, on which site does a user asks something). For visual bugs we’re currently investigating the additional use of UserSnap, where you can annotate screenshots directly within your site.

Are there any tools missing from your setup?

In the last 3 years we tried to improve Swat.io and invested a lot in our tool chain. Now we’re having quite a good foundation, where we can add new things on top. One area where we aren’t there yet is automating testing. We use PHPUnit & Codeship for basic testing, but need to implement way more automated tests in the backend as well in the frontend. Our approach is very agile so we test some tools and if we like them: boom, they make it very fast to master/production. If we find something better, then we switch tools quickly. Almost everyone in our team loves Facebook’s mantra: Move fast and break things!

Do you think your current setup of GitHub, Waffle.io and Intercom is a good one? Is there something missing from the picture?

It’s definitely an improvement to our old workflows. Currently, the GitHub centered workflow is quite good for dev-related topics and cards. But what is good for developers, is often bad for others. So, especially for our Product Managers, it’s hard to filter “user related stories”. There is a lot of noise with all the technical refactorings, library upgrades and so on, so a “high level overview” about features/bugs can get very challenging.

But what is good for developers, is often bad for others. So, especially for our Product Managers, it’s hard to filter “user related stories”.

How did your development workflow evolve over time?

As said before, we were agency devs. We needed to learn more suitable approaches for SaaS tools. I’m really proud about our achievements in the last couple of years. When talking to other devs, I always receive a very good feedback. Pushing continuously small changes, doing Kanban, removing unused features, have coding guidelines in place, having a fully standardized dev-environment (Vagrant) which can be installed in less than an hour, having time and CEO-commitment for big refactorings and fulfilling all external communicated timelines is rare. But it’s the necessary foundation for “moving fast & compete in the market”.

The “Die Socialisten” team while on their corporate retreat at Lake Balaton

What are your plans to evolve your development workflow in the future, if any?

Well, there are a few challenges we face at the moment. The last years were driven by scaling our PHP backend. We’re not done yet (or never will be), but now face more problems in our UI. We try to switch to a more SPA architecture, more (internal) API-based communication. So we definitely adapt our development workflow to be JS(ON) first ?. This is quite a challenge for our devs because we are all more or less backend devs. I’m really looking forward to this next paradigm shift for us.

Thanks! Anything missing you want to point out or something?

Yes, definitely! Thanks for having me. It’s already a tradition for me to point readers to Arnold Schwarzenegger’s 6 Rules to Success – they are simply amazing: Trust yourself, Break the rules, Don’t be afraid to fail, Don’t listen to the Naysayers, Work your butt off, Give something back!

Thanks again to Johannes for taking the time to do this interview. There are some awesome insights into their development workflow, especially for small, agile teams. I love the approach of  doing Kanban and not focusing too much on planning every detail for a long time but instead keep an overview over the next month and only be detailed about the very next steps.

Die Socialisten are hiring, so check them out!

The post Development Workflow by Example: Swat.io & Walls.io appeared first on Blossom.

At the end of the day, if you’re hiring the right people, they’ll get the work done.

Don’t be a babysitter, be a manager.

“[if] you can’t let your employees work from home out of fear they’ll slack off without your supervision, you’re a babysitter, not a manager.” ― Jason Fried, Remote: Office Not Required

Where to find distributed workers

Deciding you want a distributed team is the easy part. Building the right team is hard and takes time.

Conveniently enough, there are a number of remote and distributed team hiring websites. They are all offshoots of the original that was setup after Basecamp wrote their personal stories of remote work in “Remote” (a great read if you’re new to the distributed/remote team world).

We’ve done the legwork for you. Here are a few of the best sites to find & hire remote workers:

• We Work Remotely – The original remote job board
• Remote OK – Remote job aggregator
• Remote Year – Hire people remotely for a year
• Nomad List – Where remote workers discuss where they’re working

Taking it a step further, find people who are actively engaged in the niche community your startup is involved in. It’s how I got hired (via a blog post and Twitter interaction, from Europe to Australia!).

“Hard work increases the probability of serendipity.” ― Ken Poirot

The qualities to look for in distributed teams

Once you start looking for the right people, how do you know who’s the best fit for your company?

The Buffer team nails it, describing their key indicator for a great distributed team hire being previous experience as:

• A freelancer, or …
• In a startup

We’ve found a few other attributes that can make a great distributed team hire (most are part of our company culture):

• Autonomy
• Transparency
• Communication
• Focus
• Empathy
• Humility

What does it all mean?

Since you might not see your team or be in the same timezone, it’s critical that your work is transparent. So while you’re sleeping, a team member can take over your work, and vice versa.

Instant messaging tool integrations with your project management tool help a lot.

The added benefit of this shift in timezone is it’s easier to focus. Because you communicate asynchronously, it’s more difficult to get interrupted.

But… there’s a dark side to this.

Don’t cave into multitasking 10 things at once. You’ll quickly find that you’ll get less done. But, don’t fret! You can counter multitasking with work-in-progress limits.

It’s all about balance in distributed teams. You’ll even find that being a distributed team will help increase your software quality.

The tools to manage distributed teams

In distributed teams, communication is king.

Because of this, communication tools can help make or break your effectiveness as a distributed team.

Here’s our own distributed team stack to get you kickstarted (most tools are free):

• Blossom – agile project management
• Slack – instant messenger that’s also a notification hub
• Intercom – customer support
• Github – source code management
• Google Drive – docs, spreadsheets, forms and more.
• Skype / Google Hangouts – calls and video chats
• Sunrise – multi-platform calendar app
• Mailchimp – emails and drip campaigns
• Kiwi for Gmail – desktop Gmail support
• Homeslice – timezone syncing

Start distributing… now!

The best time to become a distributed team is now.

If you’re a co-located team, you can trial it out for a few days a week until everyone is comfortable. With the increased work life balance, we have a feeling you won’t go back.

And if you’re starting from scratch, go to the places distributed workers are already at and be deeply involved in your niche’s community.

You never know, your next best hire could be a tweet away.

The post How To Find & Build Distributed Teams appeared first on Blossom.

“The number one reason customers quit is because they believe the company no longer cares about them.” — Intercom

The 5 Key Customer Support Metrics

According to Des Traynor and John Collins, there are 5 key metrics to a successful customer support team:

The first three are fairly easy to calculate, but the latter two are often overlooked.

The 90% Rule For Response Times

Finding an optimal response time can be tricky, because…

• You have free and paid customers
• You have customers that pay a few bucks a month and others who pay 100s
• Your support team can reply with quality or quantity, but usually not both
• Your support team is finite or you decide to hire more, taking the financial hit

So how do you decide how much time to spend?

“Look at the 90th percentile value. This is the longest wait time for 90% of your customers that get in touch”

Once you know the longest wait time for the majority of your customers (i.e. ~90% of them), aim to reduce it. For example, Buffer replies to 57% of email within an hour.

Following this rule of thumb will ensure your customer retention rates explode, as you make more of your customers happier, more of the time.

Keep Creating ‘Wow’ Moments

• Buffer does it by having a customer happiness percentage of 94%.
• HotelTonight maintains a 24/7 response time of less than 10 minutes.
• Zappos does it by helping you with anything (like a 10 hour long customer call).
• Asana makes everyone in the company do support — CEO to intern.
• GrooveHQ has their CEO spend 20+ hours on support per week.

These moments create a viral word-of-mouth loop. It’s growth 101. Your customers win and so do you.

What will your ‘wow’ moment be?

Step In Before They Step Out

Heard of ‘Next Contact Avoidance’ before? Neither had I.

The crux of it is to proactively help a customer achieve their goals, even though they may have come to you with a single problem.

Running customer support with this mindset will (over time) decrease total customer support time and increases customer satisfaction.

It’s win-win!

AN EXAMPLE

A customer has asked you about a due date feature being built in your project management tool. By asking a few logical questions (or preemptively telling them), you might just find your customer is actually having problems with meeting project deadlines. From there, you can help them structure their work in a more predictable way and help them to avoid relying on due dates altogether.

You’ll become a mind-reader to your customers (the good kind).

Remember, Your Customers’ Success Is Your Success

Customer support isn’t building a product, nor is it distributing one.

But don’t let that fool you. Stellar customer support keeps customers for longer and turns them into your biggest fans.

And you never know, it might just become your competitive advantage.

The post 5 Customer Support Metrics for Startup Growth appeared first on Blossom.

The Distributed Team Test

A distributed team is one that’s spread across geographical boundaries and time zones. The key difference? Most people will be based in different cities and don’t often physically work together.

If you’re not sure if you fit into the category of distributed or remote, take this quick test:

The Difference Between Remote and Distributed Teams

To be clear, the trend that’s currently being set in the startup world is around distributed teams. That’s because being distributed helps teams to:

• Utilize global talent
• Cover multiple time zones
• Communicate effectively
• Increase software quality

Hubstaff’s Distributed Team

On the other hand, remote teams operate much like co-located teams. Most of the members in a remote team meet up at the ‘office’ on a regular basis. However, some (or all) team members can work from home for part (or all) of the working week.

Being an effective Distributed Team

With technology, it’s only becoming easier to be an effective distributed team. To get your team there, you can employ:

1. Communication tools (& asynchronous comms, e.g. Slack, Hangouts, Skype)
2. Effective email (short and to the point, e.g. Gmail)
3. Mastery of time zones (e.g. Homeslice)
4. A focus on ‘why’ (e.g. jobs-to-be-done and job stories)
5. Regular retreats (e.g. Buffer’s retreats)

Examples of awesome Distributed teams

These companies are already effective distributed teams:

• Automattic
• Buffer
• Zapier
• Groove
• Baremetrics
• InVision
• Help Scout

Buffer Team Retreat

We can all learn how to be more efficient in our own teams by looking at how distributed teams work. These teams use asynchronous communication and their dispersed time zones as  a competitive advantage.

Is your startup a distributed team? We’d love to know how you run yours!

The post The Difference Between Remote and Distributed Teams in Startups appeared first on Blossom.