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.

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.

There was one key pattern that I’ve noticed over and over again.

Some companies approach software development as an engineering management challenge. Others approach software development as a product management challenge.

Good companies manage Engineering.
Great companies manage Product.

In most companies (especially larger ones) product management is severely understaffed or doesn’t have enough political leverage.

If you have a super strong engineering team
but a weak or understaffed product team,
you will struggle.

— Fred Wilson, Union Square Ventures

Putting your focus back onto managing product might sound trivial but it makes a profound difference.

Don’t starve Product Management

There is a simple reason why product management isn’t getting as much attention and political leverage as it deserves. Especially when it comes to larger companies and companies with growing pains.

Without sales, nothing would get sold.
Without engineering, nothing would get built.
Without support, customers would leave.
Without product managers? Life would be just fine. (For a while.)

— Kenneth Norton, Google Ventures

Hiring great product people is easy just so easy to forget about as your company grows.

The key thing to understand here is that when you get overwhelmed in engineering management issues this often is just a symptom of a simple root cause.

Your organization has become reactive rather than proactive.

How to regain your grip on Product

Hire people who have a broad background (ux, marketing, engineering, …) and put them in charge of translating vision into strategy, strategy into tactics and tactics into execution.

You want people who are great communicators and who are able to slip into the shoes of many different roles quickly.

Re-shuffle your engineering teams and turn them into cross-functional product teams of about 3 to 7 people. This enables autonomy, increases quality and accelerates your time from idea to delivery.

Clearly set the vision and why you want to go in a certain direction.
Let your product teams figure out what and how to pull it off.

If you found this essay helpful you might want to take a look at our hand-picked product management training resources.

The post Good companies manage Engineering, great companies manage Product appeared first on Blossom.

I find this especially insightful when it comes to fundamental building blocks like programming languages and runtimes.

Why? Because they aren’t built in a day but rather melded over the course of many many years and in a way they tend to reflect the personalities and beliefs of their creators.

When you look at Python you will find Guido van Rossum.
When you look at Scala you will find Martin Odersky.
When you look at Ruby you will find Matz and DHH.
When you look at Clojure you will find Rich Hickey & David Nolen.
When you look at Go you will find Rob Pike.

Who is behind Dart?

So let’s take a look at the people behind Dart and what they care about.

After consuming hours of conference talks, interviews, blog posts, code and books from the Dart team I can tell that they care about a ton of things from the very abstract down to little big details but if I’d had to put it in a nutshell they care about the following …

• Developer Sanity
• Developer Productivity
• Developer Tool Performance
• The Web as a Platform

To save you some googling I’ve assembled a few brief bios as well as links to videos and further reading so you can take a look at some of the many master minds behind Dart.

Gilad Bracha

In the 90s Gilad together with Urs Hölzle, Lars Bak and others created a high performance Smalltalk implementation called Strongtalk. One very unique thing about Strongtalk was that it supported gradual type annotations. A concept that would take many many years to achieve mainstream popularity and can now be found in Dart, Hack/PHP, Python 3 and TypeScript.

After their company got acquired by Sun Microsystems the rising popularity of Java unfortunately led to the Strongtalk efforts being put on halt.

The team got reassigned to improve Java. Their Smalltalk implementation evolved into Hotspot which is now the official Java Virtual Machine and Gilad co-authored the specifications for the Java language and Java Virtual Machine.

Fortunately Gilad’s fascination with gradual type annotations and language design in general did not disappear after working on Java and he joined Cadence Design Systems to create Newspeak a modern object oriented programming language inspired by Self & Smalltalk. Again featuring support for gradual type annotations. Unfortunately the funding for Newspeak dried up in 2009.

But as one door closes another one opens and Gilad joined Google and was reunited with Lars et al to work on an ambitious project to create a new language & platform for the web called Dart.

Here is Gilad’s QCon San Francisco talk on Deconstructing Functional Programming.

Lars Bak

Lars is the creator of several high performance virtual machines for popular programming languages like Smalltalk (Strongtalk), Java (HotSpot), JavaScript (v8) and Dart.

By now it is hard to imagine what the current state of JavaScript runtimes would look like if Chrome’s v8 had not entered the market. Lars focused many years on improving the performance of v8 while staying faithful to the semantic constraints of JavaScript.

Eventually he felt that it was about time to pursue bolder steps forward if the web as a platform wants to stay competitive in comparison to native alternatives like iOS and Android.

By founding the Dart project they finally had the chance to not only question but change many of the fundamental design decisions of JavaScript and to explore what a language and runtime would feel like if it was designed for the web as we know it today.

Here is a brief video from 2008 of Lars explaining v8 and how they’ve managed to create a fast JavaScript runtime.

Kasper Lund

Kasper also worked at Sun Microsystems and focused on CLDC Hotspot, a version of the Java Virtual Machine optimized for mobile phones and similar environments.

In 2002 Kasper and Lars went on to found a company called OOVM to further explore the challenges of building high performance embeddable virtual machines for object oriented languages. While at that time mobile was already a super interesting space it was still pre-iPhone (2007) and hard to grasp how important mobile and mobile optimized runtimes were going to be going forward.

Eventually they joined Google to work on a project that would shake up the browser market; the Chrome browser and its v8 JavaScript runtime. Kasper was tech lead for Crankshaft, an optimized compilation infrastructure for v8 that got released in 2010 which used type feedback to dramatically improve Chrome’s JavaScript performance.

I find his enthusiasm for developer sanity and how tooling can help very inspiring and Kasper has given quite a few talks and interviews on this topic over the years and that aspect really shows when you work with Dart on a daily basis.

Here is an interview with Kasper on platforms and developer productivity from the 2012 GOTO conference in Copenhagen.

Bob Nystrom

Bob was a game developer at Electronic Arts and is the author of Game Programming Patterns. He has a very pragmatic approach to programming languages and really cares about how software gets designed and feels in the day to day.

He is the author of Dart’s Style Guide and responsible for a lot of the sensible defaults and recommendations that shape the experience of writing and reading Dart code. Recently he also helped to formalize the process for how proposals for improving Dart are managed (similar to Python’s PEPs).

One additional artifact that Bob worked on is Dart’s package management system pub which is inspired by JavaScript’s npm and Ruby’s bundler. Another one is the fact that you can use markdown in Dart comments which makes writing and reading great inline documentation way easier.

These things form the little big details of the day to day Dart experience that you only really notice when you’ve worked in other languages that got some of these wrong or don’t have them at all. In that vein I like to think of Bob as Dart’s dungeon master. He keeps things in order.

Here is a talk by Bob on Dart and how it relates to various programming languages from StrangeLoop 2014.

Vyacheslav Egorov

Vyacheslav worked on Excelsior JET, a fully compliant third party Java Virtual Machine implementation including an AoT (ahead of time) compiler.

He later joined Google to work on Chrome’s v8 JavaScript runtime and now works on the optimization pipeline for the Dart VM.

Vyacheslav regularly gives insightful and entertaining talks on virtual machine performance. If you’re interested in how the JavaScript virtual machines in modern browsers are designed and how the Dart virtual machine can be even faster than that make sure to check out his talks.

Here he talks about v8 and the Dart VM from Dart Flight School 2014 in Oslo.

John McCutchan

John is the creator of inotify. He contributed to the Gnome project as well as to the Bullet physics engine. Before joining the Dart team he worked on PlayStation game performance optimization at Sony Computer Entertainment.

Recently John added SIMD support to Dart (and EcmaScript) and currently works on Observatory which is an advanced profiler for Dart applications.

Peter is a first class compiler engineer and all-round tooling enthusiast.

Back at Sun Microsystems he was the tech lead for javac (Sun’s Java compiler). During that time together with Gilad, Gafter and Gosling he drafted a proposal to add closures to Java 6.

Peter also put a lot of effort into making Java IDEs more powerful and Java itself more toolable. Last but not least he was an avid supporter of open sourcing the JDK, no small feat.

Currently Peter is working on things like incremental compilation support for Dart as well as on an experimental Dart runtime called fletch.

Here is a brief demo by Peter showing a proof of concept for incremental compilation and code changes that are pushed to the browser.

Go to dartlang.org and take it for a spin or subscribe to our mailing list about Dart.

The post Who is behind Dart? appeared first on Blossom.

Many of the founding teams we back include a strong coder and a strong product person. A typical configuration is the founding CEO is also the “VP Product” at the start. This is a great configuration for a starting team. The two individuals can and should build a tight knit relationship with each focusing on their particular roles in getting the product built. The product person sets the overall requirements, specs them, focuses on the UI and UX and manages the process. The engineering person builds the product or manages the team that builds the product, or both. The yin and yang of product and engineering are represented in these two founders and their relationship and combined effort is what gets the product out the door.

As the company scales the yin and yang of product and engineering often gets out of whack. What typically happens is that the engineering team scales and the engineering leader either scales with the team or hands over the job of managing engineering to a seasoned executive. But the product side often does not scale in the same way. Many founding CEOs who are also acting in the VP Product role attempt to do that job for too long. Or they bring in product managers but don’t build a highly functioning product organization. And hiring a really strong VP Product is often an afterthought.

I have seen many companies go through this phase. What happens is the company starts having trouble getting product out the door as rapidly as it had in its early days. Other issues start cropping up and the engineering team has to focus on them. A typical one is technical scaling issues. If the service is popular, the entire engineering team can get pulled into firefights related to scaling issues. And I have often seen companies spend a year or more rebuilding the guts of their product to make it scale better. During this time, product related efforts can languish and feature development takes a back seat. This period in a company’s development is brutal on the product team who gets frustrated with their inability to move the ball forward.

The prescription for these problems is two fold. First, the company needs a strong executive in both product and engineering. I say executive because the key skill set is the ability to manage people and create organization structures that are highly functional. The VP Engineering and the VP Product need to have a history of being highly skilled engineers or product managers, but in the role of leading these organizations, those skills will not be the ones they use. They will hire, fire, organize, manage, resolve lingering issues, and make tough decisions. They will be managers. And these two individuals need to pair up in the same way that the founding team did. They need to be partners with each other and reinforce each other. The ability of the VP Engineering and VP Product to work well together is so key to building a great tech company.

The second thing that has to happen is that product and engineering resources need to be divided up into small teams that actually build stuff. Teams should be between three and seven people. Anything more than that should be broken up into two teams. Each team needs to have a product lead and a tech lead. And just like the two founders and the two VPs, the two team leads need to partner up and work well together.

So hopefully you see that this yin and yang of product and engineering must always be at the center of the company and they need to be in balance. If you have a super strong engineering team but a weak or understaffed product team, you will struggle. If you have built a functioning organization in engineering but not in product, you will struggle. If you have a team where one of your two team leads is weak, it will struggle.

If you are stuck between being the scrappy startup you used to be and the highly functioning big company you want to be, look at your product and engineering organizations and make sure they are well balanced and that you have strong leaders in both who work well together. If you don’t see all of those things, think about making some changes to get there.

The post The Yin and Yang of Product Engineering appeared first on Blossom.

Google App Engine

We’ve traditionally hosted everything ourselves, no matter whether it is a personal project, a project of a friend or a project for a client.

We’ve used PHP, Ruby, Python, Haskell, Java, JavaScript, Debian, Ubuntu, FreeBSD, Solaris (ZFS rocks), SQLite, MySQL, PostgreSQL, Varnish, Nginx, Mongrel, Lighttpd, Memcached, various taskqueues and a ton of other technologies that would probably fill a whole book.

The first time we hosted a pet project on Google App Engine was an enlightening experience. We immediately understood that while we enjoy and really care a lot about sysadmin challenges what we actually enjoy most is creating great products on reliable infrastructure.

The warm fuzzy feeling you get when you can stop to worry about database scaling issues, hardware failures or monitoring and restarting a herd of daemons is incredible.

While Google App Engine as a platform was somewhat restrictive in its early days, it has improved steadily and we are very happy campers.

Flask

We’ve been heavy Django users in the past and learned a lot from the community and the vast amount of top notch documentation it provides. But as Django was built with relational databases in mind it wasn’t a perfect match for Google App Engine. So we started to dig around for a good alternative.

Flask was exactly what we’ve been looking for. A lightweight database agnostic framework based on Werkzeug and Jinja2. Similar to Django it comes with outstanding documentation and a very supportive community.

Python

As you probably already have guessed Python is our language of choice for backend code, command line tools and data crunching. It is probably the least surprising choice in our stack. Python offers great libraries, clean syntax and a healthy community that cares about documentation, stability and pragmatic solutions.

Backbone.js

We’ve been very early adopters of Backbone.js and looking back it definitely is among the best technology choices we made. While Backbone is very lightweight it gives your codebase a lot of structure by providing a few simple building blocks like Views, Models and Collections.

Also browsing through its source code teached us a lot about event handling and pragmatic approaches for architecting frontend-heavy JavaScript applications.

CoffeeScript

CoffeeScript is a programming language that compiles to JavaScript. It was created by Jeremy Ashkenas, the author of Backbone.js and underscore.js. It enables us to write tons of JavaScript without actually having to fight with many of JavaScript’s quirks. Classes, cleaner syntax & semantics, lexical scoping and list comprehensions definitely go a long way.

Dart

Having worked with Google Closure, CoffeeScript and the Google Developer Tools in we’ve experienced how access to great tooling can drastically decrease complexity.

I think Dart is a very worthwhile tabula rasa bet on what an alternative to JavaScript could look like. It enables incredible tooling support, comes with optional typing, tree shaking (Dead Code Elimination), a package system and a promise of extraordinary performance down the road.

That’s why we are going to push Dart code into production at Blossom in the coming days. Stay tuned.

Ping me anytime you want to chat about tech stacks and trade-offs

The post Blossom under the Hood: Our Technology Stack appeared first on Blossom.

Zach Holman shares with us how the workflow at GitHub looks like. These slides are from the Frozen Rails Conference 2011 in Helsinki.

Build features fast. Ship them. That’s what we try to do at GitHub. Our process is the anti-process: what’s the minimum overhead we can put up with to keep our code quality high, all while building features as quickly as possible? It’s not just features, either: faster development means happier developers.

Also make sure to read his insightful blog posts on the topic:

• Hours are Bullshit
• Be Asynchronous
• Creativity is Important

The post How GitHub uses GitHub to build GitHub appeared first on Blossom.