Imagine a seven year old playing the piano. She hits every note like it’s the only one, taking long breaks between each note. The play drags and listening to the singular notes is a pain. Instead of music, all you hear is a bunch of individual sounds, each one rivaling with the others to be the loudest one.
Now imagine the same play performed by the same kid five years later. The notes flow like a river, the emphasis not on individual sounds but on the whole sequence at once. Listening to the piece is pure joy, because every note works together with the others to create a beautiful experience.
Distributing your software development through separate departments is like a seven year old playing the piano. Every department works on its own, rivaling with the others to be the most important. The output is a pain for your customers and the quality is really poor. But how can we create an organization where the individual parts play nicely together? One way of making departments play together are feature teams. Let’s see how this could work out.

Feature teams are cross-functional teams

They consist of team members from every department involved in feature development: business analysts, developers, quality assurance, operations, and so on. Ideally, they’re co-located – working in a big room together or at least in the next room. This shortens communication paths and speeds up necessary information exchange.

Feature teams are responsible for a certain set of features or a specific service. At amazon.com every part of the website like recommendations or reviews are separate services developed by individual feature teams. Each team is fully responsible for the feature, from idea to operations. Any challenges that arise within their specific feature must be solved by the team.

Solving challenges is simpler in smaller teams

If you form feature teams you should keep them small. A famous quote from Amazon: “If a project team can eat more than two pizzas, it’s too large”. Keep your team between five to nine people. This will keep the complexity of inner-team communication as low as possible. You scale your projects by combining multiple small teams – each one fully responsible for certain features.

Embed every required skill within your teams to create a successful feature. This isn’t possible with all skill sets, but you should limit external party support as much as possible. External dependencies always slow down a team and increase complexity.

It’s all about reducing complexity

Trying to drive a feature through multiple departments can be quite a challenge. Every department has their own goals which usually conflict with other departments. Even if they want to help, they have a hard time understanding exactly how.

Building feature teams tears down those departmental barriers and joins people from every department into one team. This helps to create empathy and, more importantly, trust – the number one factor to speed things up in complex environments. Without trust, blame games and CYA tactics are rampant. Only if people know each other, have the same goals, and work together are they more likely to trust one another.

That trust thing sounds great, but won’t work for us

Let’s say you already have feature teams. This is often the case in so called “matrix-organizations” where every employee is part of a certain department but works in multiple projects. And with multiple projects, the problems start. The employees are supposed to serve multiple bosses: the project leads as well as their department head. Because they’re assigned to multiple projects, they usually find home in their department and give it the highest priority.

But giving the highest priority to the department is not what you want. Therefore it’s important to assign people to one and only one project. Make that project (and the feature team driving it) the home for your employees. The department should mainly serve as interest group.

Feature teams take responsibility

They’re fully responsible – end-to-end – for a certain feature or service. They’re small, co-located and they have all the needed skills to be successful. Feature teams act as the home base for employees as departments fade into the background providing mentorship for honing one’s skills. But the main, business contribution happens in the feature teams.

If you setup your organization like this, you’ll begin to see a nice flow of great feature releases – like a well played musical piece.

“But our customers don’t want 10 new versions a year. The last release alone had over 600 bugs!” retorts the hotline manager.
“How about a small update with just a handful of bugs?”

Your big-bang release is scary. It’s full of issues and weird, new features that nobody understands. It requires documentation and training and who the hell has time for all that?

Monthly, bite-size updates will have fewer features requiring less support (pro-tip: less code == less bugs). Speeding up your release cycle also allows quicker response to customers’ feedback. You’ll finally feel your company moving in the right direction again.

Of course, it’s easy to say. But how can you actually achieve this positive flow? Follow these key points and you’ll be well on your way.
Click to continue…

Monday morning on the highway. Your speed: 0 mph. You’re stuck in the usual rush hour traffic jam because the capacity of this road is exceeded. And it’s now obvious you’ll reach your destination much later than if the road were empty.

But what happens if you exceed the capacity of your development team? What happens when you cram in more features than the team can develop? Your features will get stuck in development. Let’s see how this can happen.
Click to continue…

A rope. Eight people on either side. “Pull!” And then it begins: both parties are pulling in their own direction. A tug-of-war has started.

Imagine your developers and sysadmins as those two parties starting that tug-of-war

Each group has different goals. And having different goals leads to each party pulling in another direction. How can this happen and what to do about it?
Click to continue…

There are DevOps tools and DevOps job ads. People talk about culture and sharing and being nice to each other. Sounds pretty fishy, right? The only thing missing is a DevOps certification and we’re done with the DevOps hype. Is DevOps really just a fad? Let’s take a closer look…
Click to continue…

Investing into code improvement is a dual edged sword: on the one hand you know that if you don’t improve your code you’ll get slower over time. On the other hand improving your code does not deliver tangible value to your users. So how do you know whether you’re on track?
Click to continue…

Epson iPrint

London Stansted Airport, early afternoon – a huge crowd at the railway station. No trains – only people, and a lot of confusion and anger. Having just flown an hour from Munich, Germany, I was supposed to meet a client two hours after touch down. But here I stood, waiting with the crowds: the railway just broke down. After several hours of waiting, I was able to catch a bus and reached London city late in the evening – but the client meeting was long over. The whole trip (not to mention an entire day of my life) was wasted just because one leg in my journey failed. Do your users waste their time because you have failing legs in your product development journey?
Click to continue…

CD and Devops

We’ve teamed up with Packt Publishing to organize a giveaway of their new book “Continuous Delivery and DevOps: A Quickstart Guide” as a holiday gift to you our readers!

Four lucky winners stand a chance to win copies of this new book. Keep reading to find out how you can be one of them.
Click to continue…

While I’m collecting Devops Protocols which highlight healthy patterns in your organization, let’s take a quick look at the opposite: Devops anti-patterns. Would you be able to spot the warning signs when your team starts to slip in the wrong direction?
Click to continue…