Sven Peters

Getting Video Conferencing Right

At MongoDB the current situation has forced us all to be remote and I know there are 100s of other companies that have done the same. Luckily we have the technology to continue to meet and discuss our work.

What’s the big deal? Starting the video conferencing software and jump into the conversation. It’s as simple as that, right? After spending uncountable hours in video conferencing meetings over the past 8 years I learned that participating on a call remotely is fundamentally different than having a face-to-face meeting.

The Setup

You need just 5 things: VC software, a good internet connection, a laptop with a camera, headphones, and good lighting. Some might argue having a good mic is super important and an HD camera makes every video call better. I don’t think they make a big difference. Concentrate on these 3 things:

A laptop with a camera – We want to see each other. We are social people and just speaking with a profile picture of someone feels strange. We want to see the non-verbal reaction to topics we discus.

Headphones – Without them: the mic may pic up the speaker and you get a weird echo. This was a given 5 years ago. Today the software is much better so it works probably 90% without headphones. There is still apr. 10% of meetings where it doesn’t work correct, so please wear headphones. I still prefer the cabled version. Sometimes the VC conference software has problems choosing the right mic or audio output especially with bluetooth. My cable headphones always work.

Lighting – The most underrated equipment for remote calls. In order to see people’s facial expressions during a video conference you need good lighting. You can spend a lot of money on this but it really just needs a lamp with a soft light bulb shining directly into your face. Installing some indirect lighting is a bit bigger investment but it’s also more comfortable for you.

Software – These days most video conferencing tools have all the essential features. The quality of the calls is similar. If there’s one thing you want to check it is support for showing the video feed of the other participants while you share the screen. Talking just to your computer while you don’t see your co-workers is super weird. Tools like Zoom, Slack, Microsoft Teams, BlueJeans, and Google Chat (formally known as Hang Out) are all good for regular video meetings.

The Meeting

Doing 1:1 meetings is a straight forward thing. Both are engaged and you two don’t speak at the same time. It’s getting more interesting when more people meet virtually.

Everyone remote – If you have just one or two people participating remote and the rest of the meeting guests are gathering around a table in an office, there is one recommendation: Everyone dials in with their own laptop. Everyone should share the same experience. This way you don’t have side conversations that remote people can’t follow, you can see everyones reaction to an argument you’re making, and all are suffering from someone speaking while having audio drop outs due to a weak internet connection.

Don’t make the mistake that everyone books their own rooms and dial in with the office video equipment. It’s important that everyone is using the laptop camera. That automatically forces everyone to look at their screen and into the camera. This is much more engaging.

The tiled view – Some video conference tools offer the possibility to show all participants in the same size pictures. Choose that options. Default the person that is currently speaking is showing in large picture on the screen and everyone else in tiny pictures. I want to see the reaction of everyone that’s why I prefer that tiled view.

Mute yourself – If you’re 4 or more people in the meeting it’s a good idea that everybody but the current speaker mutes themselves. Simply unmute when you want to say something. Nothing is more annoying than having a meeting with the whole team and there is background noise from someone that you can’t identify.

Have a moderator – It’s often difficult for remote participants to jump into a conversation when there’s a pause. Especially because of the network latency. Someone else continues the conversation and you end up speaking at the same time. A moderator can assure that everyone’s opinion got heard. A good practice is to unmute yourself when you want to say something. The moderator sees that and will ask you for your opinion whenever there’s a pause in the discussion. Some video conference tools additionally offer the possibility of raising your hand virtually instead of using the “unmute hack”.

Pay attention – Don’t check emails, read chat messages, or browse the internet during a remote call. It’s not alright for face-to-face meetings and it’s not for your remote meeting. People can see that you’re reading something and are not fully concentrated on the call. Really, the chat can wait.

One at a time – If everyone dials in with their own laptop you probably don’t have the problem. But if you have a mixed meeting with some people remote and the rest in a conference room it can become a problem when people speak at the same time. The remote people can not follow 2 conversations at the same time.

You want to learn more about working remotely? Here’s a talk I’ve done:

Learn more about remote work

5 Great Books For Better Teamwork

In the last 10+ years I’ve studied teamwork by talking to a lot of teams in different organizations. Besides that, I’ve read a lot of books on this topic to compare my findings with those from others. Not surprisingly I found a lot of overlap in some of those books. Here are my top 5 recommendations for running self organized teams, scaling teamwork and setting the right direction:

1. Team of Teams

by General Stanley McChrystal

My favourite book when it comes to scaling teams by providing more autonomy. It’s a fascinating read how the US military needed to change from a very hierarchical system to give their teams more autonomy in order to make them faster and more engaged. The book gives a lot of examples and reasons for traditional top down organizations to make the switch to more self driven approach.

Amazon link

2. The Best Team Wins

by Adrian Gostick and Chester Elton

This book describes a lot of great concepts and real world examples how to build great teams. It talks a lot about the need of cross functional teams and how to lead self directed teams. One chapter that I found most interesting (and haven’t really read a lot about in other books) was the one on understanding different generations and the different motivators that drives Millennials, Gen-x’ers, and Baby Boomers. It helps me in my daily work to get behind behaviours, demands and motivators fo my team.

Amazon link

3. Measure What Matters

by John Doerr

One of the biggest challenges I’ve seen for a lot of teams is goal setting and following. This books describes how to use OKRs (Objectives and Key Results) to measure what really matters: the outcome of teamwork, how to be effective vs. being efficient. John Doerr not only describes how OKRs helped Google to scale but also gives a lot of mini case studies from other organizations. After reading this book you can start immediately trying out OKRs for your team – It changed the way I and my team focus on bigger initiatives.

Amazon link

4. Radical Candor

Everyone in a team should read this book about being a better colleague by giving radical candid feedback. It’s a book for leaders as well as team mates. It helped me to understand also the different types of people on my team like making the distinction between Rockstars and Superstars. Kim explains that you need both types in your organization to grow and build on a solid platform. I see the value of different team members differently and have learned how to motivate people differently after reading this book.

Amazon link

5. Powerful: Building a Culture of Freedom and Responsibility

by Patty McCord

Patty is telling the interesting story about scaling Netflix from an HR perspective. I really love the cultural aspects and it’s a great view into how Silicon Valley companies motivates its employees by giving them freedom on one hand and holding them accountable on the other. Since I’ve been working for years in such a company I can totally relate to this culture that covers attributes like:

The greatest motivation is contributing to success
Every single employee should understand the business
Practice radical honesty
Debate vigorously
Build the company now that you want to be in the future

Amazon link

Building Autonomous Teams

I know that autonomous teams sound scary for a lot of organizations and leaders:

How do we align those teams?
How do we know they’re making progress?
How do we compare them with other teams?

I’ve been working for organizations that were afraid of implementing autonomous teams because they were fearing a lack of control. But why can’t teams control themselves? Why can’t the leadership still get insights on what those teams are doing and be involved in the reasons behind their decisions?

Alright, it’s not easy to build autonomous teams but the benefit is enormous: Highly effective and successful teams. Those teams share 4 characteristics:

1. Compelling Direction

Those teams know what their goals are. The leadership is giving the broader vision and the team is setting their goals based on that. It’s still possible for the organization to check in to see if the team is on the right way, but the team is self steering towards the common goal.

Our teams are setting their goals based on the department’s goals, which are based on our company vision for the next 2 years. We use OKRs (Objectives and Key Results) for setting, tracking and measuring goals. Our leadership team is holding weekly townhalls with the whole organization to communicate the overall strategy and give updates on selected projects to keep ebery alligned.

2. Strong structure

For autonomous teams it’s essential to have all the expertise inside the team. That’s why we build a cross functional teams. For our product development team we often have development, product management, and design in one core team. Some teams need a QA engineer so they add those expertise to the team, others need an analyst, etc.. It doesn’t matter if you have a Triad or Squad. You should have the core competency in your team to react fast.

3. Supportive Context

Your team can’t have all the information in order to be successful. You often need the support of other departments like legal or IT to move forward. This should be as frictionless as possible. Information should be open for everyone in the organization to be discovered and used.

We use a ticket system for every request. Not only for IT requests, but also for design, finance, or if we need to travel to another office and want to book the corporate apartment. We have a service center where we can file all those requests.

The information that we need from other teams are shared openly in our intranet. That way lot of questions are answered by reading pages or I just add a comment if I didn’t understand everything.

4. Shared Mindset

Sharing the same mindset helps a lot when working together:

The whole team knows what the goal and the purpose of the project is because we’re sharing a project poster
Every code change need to be reviewed so we’re spreading the code knowledge in our team
Designers are sharing their designs and gathering feedback from the team

..and much more. We’re setting the goals together, develop together, reading through feedback together, and course correct together. All this helps us that everyone in the team is on the same page.

Help your team

If you’re coming from a traditional background the idea of having autonomous teams can sound a bit scary, but it works. Those teams are even measuring how they’re doing on their own and course correct. We use a Team Playbook with best practices from other teams to help us improve. Why should you compare teams with each other if each team is doing their best to reach a goal. I’ve never seen a good system to compare team outcome.

If you want to learn more how to build a successful team come to my talk at CTRL in London 31 Oct. CTRL will run as a track at Microsoft’s Future Decoded event in London on October 31st. The event is free to attend so grab your tickets here

7 Bots That Help Improve Your Development

Now I call them robots or short bots. You might call them scripts, services, helper tools or simply automation of tasks. If we see that we repeatedly doing the same task over and over again it is time to automate our software development. Let’s see how far we can go and where bots are used by super productive development teams.

bots

Now automation is nothing new in software development. Refactoring possibilities in our IDE’s, build server that runs on every check-in, automatically deployment of new software are things that we got used to in our industry. We don’t think about those anymore. I mean who changes a name of method and all its references by hand or runs all integration and performance tests on their developer machines?

So let’s look at 7 bots that can help you write better code and make you more productive.

1. Flaky Test Detector

Who doesn’t know the frustration when a build fails, you spend some time looking at the logs and the code but you can not find an obvious reason why a specific test failed, re-run the build and it succeeds. Yes, you’re a victim of a flaky test.

Our Flaky Test Detector re-runs a failing tests automatically. If the second run of the test succeeds we’ve found a flaky test. The detector automatically continuous the build and put the test in quarantaine. That means it won’t be executed in a following build. At the same time the Flaky Test Detector creates an issue for fixing or deleting the test.

Last year the Confluence team has found 817 flaky tests and put them in quarantine. 817 times on not investigating and re-running the build! That are a lot of developer hours.

Screen Shot 2015-11-27 at 10.23.02

2. Production Problem Reporter

What happens at your organization when a service fails in production? Maybe employees in operation start noticing it and may restart the service. If that doesn’t solve the problem they probably going to inform the development about it. But who to inform? And why isn’t the development informed directly?

Pagerduty is a great tool that people use to inform developers and operation employees on problems. We use it also at Atlassian, but wanted to avoid setting up responsibilities per service. People will forget this especially when deploying a brand new service.

So we’re using the deployment descriptor of the service to teach Pagerduty which developer team to inform on problems. It’s a small but very powerful bot that helps our dev team to own their code end-to-end and saves our ops team time to figure out who to call.

Screen Shot 2015-11-27 at 10.22.41

3. Release Notes Writer

Pulling together information for release notes can be painful: What did actually went into the master branch? Is the information in our issue tracker up-to-date? A good practice is to contain the issue key in the closing commit message, so you can go through the commit history and be sure that you catch every feature, bug or improvement for the release.

But if you release hourly, daily or even weekly this could be very annoying. E.g. ZeroTurnaround & Hazelcast using bots to find the commits, grab the information out of the issue tracker, generate release notes automatically and make them public.

Hazelcast is using GitHub with Github Issues and ZeroTurnaround Bitbucket with JIRA Software. This way you also spend more time on writing issue descriptions, making them more problem centric and focus more on the customer value that a specific issue creates.

4. Log File Problem Finder

We’ve developed a bot called Hercules that can analyze log files. If customer have problems with their local instance they submit a ticket on support.atlassian.com and get an option to upload their log file. Hercules examines this file and point out potential problems via a comment.

Behind the scenes our support engineers have build a knowledge base in Confluence with a machine readable part on each page. It’s basically kind of a regular expression that Hercules uses for analyzing the log. The rest of the page describes the solution of the problem, so the support can immediately reach out to the customer and suggest steps to fix the issue.

For developer that means less log file analyzing and interruptions. We’re still trying to improve Hercules for internal use before we will eventually open it for customers to do self-service with their instance. And we’re so proud of this service that we created a special t-shirt with a follow up comment from a Hercules suggestion.

Screen Shot 2015-11-27 at 10.25.40

5. Stand up Reminder

Stand ups happen regularly each day at the same time so you can assume that all team members are aware that a daily meeting is about to happen. But sometimes they chat with other colleagues or they forget the time.

At Atlassian every team has at least on TV that they use as an information radiator. Current development information is shown in a browser tab. We use that so called Wallboard to remind people about the upcoming standup. An engineer developed a Chrome add-on called Crontabs that opens a tab at a specific time with a specific URL. We use it to play music from a streaming service.

Screen Shot 2015-10-16 at 07.46.38 So if you hear ACDC playing you know, it’s time for your daily standup and you have one minute to join your programming buddies. If it’s Taylor Swift, you
know it’s the marketing team’s stand up ;).

6. Engineering Health Checker

If you’re long enough into programming you know that code gets messy over time: Long classes, use of deprecated methods or increasing compiler warnings. Yes, we should constantly look out to fix those but somehow we’re lazy and it feels better to write a new clean shiny class instead of improving an old one.

Screen Shot 2015-11-27 at 10.24.55 We didn’t wanted a static code analyze that breaks the build – The software is fully functional even though a team member just wrote a new JUnit 3 test instead of using JUnit 4. So we wrote a bot that does can analyze the code and recognizes these engineering health issues.
Instead of a build failure we wanted to rise the social pressure on people. We build a ‘Hall of Shame’ for our Wallboard that shows the face of an engineer that just introduced a new health issue. Those who are working to improve the existing code base enter the ‘Hall of Fame’. It started with a single check and now we’re checking over 50 different health categories.

7. Automatic Merging

Git is very good in merging code lines. Most of the time merges just work. So why not use that power to automatically merge the code?

At Atlassian we develop software for the cloud as well as for installing on your own server. There are several versions of our software out in the wild at our customers. When we find a bug in an older version (let’s say 3 versions back) we need to fix it for all 3 versions as well as for our current development.

We keep our released version each on a separate release branch. Now we apply the fix for the oldest version let’s say 2.0. A git hook kicks in and merges the changes all the way back to following version 2.1, then to the following version 2.2 and so on until it hits the development branch. An automatic builds starts for each of those branches, all tests are executed and on success we release the artifact automatically to our webpage. Here is an article with more details.

Screen Shot 2015-11-27 at 10.21.47

More bots, more details?

I did a presentation about bots at JavaOne 2015. You can watch the video and download the slides.

Empowering Developers – The Next Generation Coder

I’m going to a lot of software development conferences and working in some program committees trying to select sessions about the hottest new trends. If you do this for a few years you see hypes come & go like SOA, ESB, MapReduce, BPM and so on. But once in a while there is a revolution that changes the way we work and think about development like Object Oriented programming in the 90’s and Agile in the 2000’s. I can see a next revolution happening right now. Unfortunately it doesn’t have a couple of smart people coining a term, it’s just me calling it Empowering Developers.

Care More

The old generation
I had some managers in the past that thought adding processes and having specialists was a good idea. It was not! Fixed processes stopped us from improving the way we work, working together and fostered specialism. We had requirements, database, design, QA & It-operations specialists. Developers were just supposed to take their task and code it. They were responsible for the code itself, but not for the functional quality, the usability or the operation part. It was comfortable but also frustrating.

The next generation
I can see the trend that developers are testing their own software. Not just TDD but also through exploratory test.Most of software developers nowadays knows the writing automated tests & let them run on every code change is important to know if we introduced a new bug. As Zach Holman says “You can have the best, most comprehensive test suite in the world, but tests are still different from production.” Having a staging environment and let the team members test the code manually is another way the secure that you have less bugs. Don’t wait until your QA team have time to try the new feature. Let your team members try the new features as part of your development. In the JIRA team we actually have around 65 developers and just 6 QA people. Here’s a presentation how they deliver Quality at Speed.

Technologies like Microservices in combination with Docker helps us to be responsible for the operation of the software. We can deploy & control small chunks of code and be responsible for the whole software development chain. Breaking work down into smaller services from the requirements over quality checks to the operation side empowers the developer to care more about the software he created.
Also if developers don’t use these new fancy technologies it is still important to care more about the software we build. If the design shows flaws it is our responsibility not only to blame the designer but to jump in and fix it. Care more!

Fail Faster

The old generation
I’ve been working in organizations where I got blamed that a customer reported a bug. Bugs were not acceptable. I think one of the reason why people were afraid of making mistakes was that it was a long procedure to update the software even though it was running on a central server (these days we call it the cloud). Testing new versions took a day, the whole system had to shut down for 20 minutes, it was hard to merge the patch into the current development source code and so on. Failure was not an option. A mistake meant angry customer, 2 days dragged away from the current development and normally the whole team got involved.

The next generation
Failing faster means to catch possible bugs earlier in the process before the code hits all customers. The next generation developer have tools to optimize code debugging and have a process in place that fosters peer reviews of every new written line of code. To avoid obviously failing code on your main line, source control systems like Git in combination with a workflow that allows you to review code before it hits the production branch. Tools like Gerrit, GitHub, Bitbucket, Gitolite and Stash helps you to easy discuss code changes with the team and to fail faster.
But sometimes bugs hit the production server no matter how sophisticated your dev process is. To make that impact as small as possible the next generation developers know that they have to create a system where they can roll out patches automatically very fast, have good tools to monitor the performance of production systems and can deploy changes just to a subset of their user base so a new bug can just be experienced by some users. These developers know that they are responsible for the running software, their performance and scalability. They work close together with operations to put the best systems in place to catch bugs early and to roll out changes fast with confidence.
What people holds actually back from deploying with confidence is the automation part. The Atlassian build engineering team have created a system to grew this confidence for developers. Peter Leschev talks more about the details about this in his “Infrastructure as Code” video. Tools like Vagrant, Packer & Puppet helps us to encourage people to deploy software more frequently and to fail fast and fix things faster.

As you can see failing faster has a lot to do with automation but also with giving people confidence. If developers are afraid to put code in production they will do it less frequently and therefore it’s always a big event instead of a job that we do 10 times a day. The next generation developer has the power to deploy software & update it fast themselves without waiting on others people.

Be Creative

The old generation

It was hard to put a new idea into production. Developers were just working on features that a product manager has added to the backlog. There was no slack time to try out new things & coming up with creative ideas. There was a process for customer requests but no process for spiking ideas from developers.

The next generation

Developers get time to be creative. Managers knows that their developers can balance their time themselves and that developers know how important it is to solve customer problems and how much time they can spend on working on new creative stuff. Concepts like 20% time, hackdays and innovation weeks helps the next generation of developers to work on new innovative features.
But creativity is also needed when developers needs to create planned features. The next generation of developers are involved in feature design & user story mapping. They understand the problem, the different personas that will use the feature and discuss solutions with designer, product owner and other stakeholders. They play an important part in finding the right solution and understand deeply the needs of the business. We at Atlassian use Personas to keep our developers engaged with the functionality they’re implementing.

Go Team

The old generation

We were collecting specialist in a team. Teams that were responsible for the performance, another team for the database, and another one for the front end. Feature planning needed to be done across those teams which was often very frustrating. Communication between those teams were done in regular meetings or through emails (without all team members on the thread). This all led to big bang releases where we were trying to put the different development threads together.

The next generation

The next generation developer still work in a team. But their responsibility is for a whole functionality. The teams doesn’t only consist of just experts. Every developer in those team have the power to change the database schema, write front end code, design the UI, test the features from other team members and talk to customers about requirements. They are just specialized for their certain feature set like ‘Making it easier for new customers to work with the software’ or ‘Scaling the software for a huge customer base’. Sometimes teams are just formed for some time to develop a certain epic that contains of a couple of user stories. They care deeply about this feature. Of course: Microservices are making it possible that those teams can deploy their features independently from other teams.

Communication is very important for the next generation of developers. Everyone has all information at hand. Team members are using chat rooms for communicating transparently. This helps for people staying in the zone for a while but never miss a team conversation. These devs grew up with Facebook & Instagram, so sharing knowledge and experience with technology is natural for them. At Atlassian we connected our team chat rooms with our automated systems, so everyone can see when we deploy the software to staging or production, when a customer reported a serious bug, when code is ready to be reviewed or when the build failed. These information are essential for us to move forward quickly and keep everyone informed.

Every team can decide the way they want to work. If the current process doesn’t fit for the actual task they have the power to change it themselves. Teams are more like small lean startups within the larger organization. There will be of course still interacting with other teams but it will much less than having 100 people working on the same monolithic code base and application.

The Next Generation Developer

Developer will have more freedom but also more responsibility for the features they’re developing. Even though some companies like Google, Apple, Atlassian and Spotify are starting to work this way it’s still a long way until this hits the majority of companies. But this way of working results in happier developers and better products, so I’m looking forward what we can accomplish with the next generation developer.

Team Building – Winning & Losing As A Team

This part of the Summer of Culture blog series

There have been written a lot of books about team building and the psychology behind this. There are a lot of courses, seminars, talks about this complex topic and I don’t think this post can explain all of it. I just want to share some tips for teams and team leaders what to look after, how to measure happiness, to think about recognizing the achievements & how important it is to manage a crisis.

Special days

Companies are often celebrating their wins with an annual party, a summer party with the family or a christmas party. These are great to get to know some private stuff about your colleagues. Also doing something special day with the team like river rafting or climbing are good exercises for getting to know your team mates in different situations. It helps us for our daily work to know the strengths and weaknesses of the people we’re collaborating with. It also makes us happier because our work get recognized and we are getting out the daily routine.

Sunny days

As agile software developers we are doing a retrospective after each sprint. We’re looking back to talk about what went wrong, what went good and how we want to fix the wrong parts in the future. Then off to the next sprint. STOP. We should celebrate! I loved the movie Ferris Bueller’s Day Off when I was young. Ferris is taking a day off from school and having fun. The most famous quote from the movie is this:
“Life moves pretty fast; if you don’t stop and look around once in a while, you could miss it!”
origin_53506972 This is it. When we’ve finished a bigger feature (maybe after a few sprints), when we successfully migrated the database or when we redesigned our app: We should stop, and celebrate. Maybe people just bring some cake with them and meet with the stakeholders for 2 hours. You could also do an offside or invite the team for an evening in the pub. In the times of continuous delivery we tend to forget these things.

kudos But also care about the small things; when people did something great like fixing that annoying 3 year old problem with the database connection or giving a presentation about a book they read the last vacation about Design Thinking. At Atlassian each employee can give Kudos to others without permission from their manager. You just fill out a ticket, give the reason why someone should get Kudos and pick a present like cinema tickets, amazon gift card or a bottle of wine. The rest is organized by our HR team. It’s a great and simple way to recognize and thank people for being awesome.

Rainy days

Sometimes we fuck things up. We deploy the newest version and our 400 users can’t login anymore or some services stop working and we can’t find out why. If you’re a developer you probably went through this. If it’s a real crisis and there is a lot of pressure on you to fix this as fast as possible it’s good to stop the current sprint, get everyone at a table and divide the work. Don’t point with fingers on people like: “It’s the performance team that fucked it up, so they need to fix it”. Be not only transparent to your users but also to other teams. Give daily status reports so everyone in the organization or department knows that you and your team is working 100% on fixing the problem.

After rain there will be sunshine again. If you went through a crisis and handled it well, your team will be much stronger afterwards, knowing that they can deal with problems without letting each other down.

Is it sunny or rainy?

We can tell the weather by looking out of the window. But it is extremely hard to tell if your team is happy. You can not look inside of everyone & it’s hard to recognize slow trends. We wanted to create an easy anonymous way to measure the happiness of the team.

MoodApp_Screen1 In an Atlassian ShipIt day we developed an iPad app where people can express their current mood. You can do statistics and see how happy your team is in total and react if the mood is going down like talk to them & fix things before these grow into real big problems. Now iPads showing this app are at every exit in the Atlassian office asking “How do you feel today?’ or ‘Was it a productive day?’ or something else. Just one question!

We win as a team & we lose as a team!

We know as a team we will have sunny days as well as rainy days. No surprise. We just have to be sensitive to recognize them so they don’t get covered under the daily work and people get frustrated that their work don’t get recognized or they’re putting out fires without help from other teams or team members.

Photo credit: simonech via photopin cc

Have a DOmocracy

This is part of the Summer Of Culture blog series.

Coordinating work across teams is a real big challenge. Each product and organization is different and so have different needs in how they scale. I’ve seen a lot of companies struggle with scaling teams and being agile. Here are some problems when more than one team works on a software product:

coordination of work tasks – teams have different goals and therefor it’s harder to plan bigger pieces of work
dedication to a specific field – front end, database or performance teams are often not dedicated to customer benefit anymore

We know that these problems doesn’t appear when just one small team is responsible for the whole product development, but what can we do when the products and team grows? How should we scale the work efficiently?

Building teams around themes

I know that a lot of companies often build teams around technologies like databases or JavaScript or it was accidentally and nobody gave it a thought. That doesn’t scale. Teams should be build around groups of users like ‘Beginner’, ‘Large Customers’ or around themes in your software like ‘Search’ or ‘Mobile’ (like Spotify does it). We at Atlassian like the dedication of one team to a specific customer group. Each team have this target customer in mind and are directly connected to the value they’re creating. E.g. we have a team for Confluence that is building features for software development teams: Better integration between our bug tracker JIRA and Confluence, creating retrospectives or doing roadmap planning within Confluence. This requires cross functional teams with designers, web & enterprise developers, or preferable people in one team with multiple talents (e.g we encourage coders to train their designer muscles).

Team autonomy

This way teams can work autonomous giving them the freedom how to solve problems and how to work together. They are responsible to make their specific customer group happy. Not every team does daily stand ups, some do it every two days and others just meet when necessary. Teams can pick the tools that makes them most productive: Using a post-it task wall, working daily with JIRA Agile, estimating in story point, not doing estimates… it’s important that they get their tasks done, because people are different and teams are different.

Trusting the team

There is no code ownership. Spotify is calling this ‘internal open source’. Sure, some teams have written most of the code in specific packages. If another team wants to change that code we trust them, that they’re doing the right thing. Also the management need to trust the teams that they’re doing their best to make the customer awesome and that teams are able to coordinate their own tasks.

Trust & autonomy comes with a lot of responsibility for the single teams and developers. But also if you size your team around customer groups, give them trust & autonomy you’ll need some coordination of tasks: The different product manager & dev teams have to collaborate when designing a new feature, because it can have impact on other teams work or existing features. Also you can create side effects when changing code that another team have thoroughly designed.

Transparency

A DOmocracy doesn’t work without transparency. We use code reviews where we invite original code creators & contributors to review the changed code (we actually have written an add-on for identifying theses persons). We use our collaboration platform Confluence to share & discuss new features we’re currently planning or developing. We gather feedback from everyone in the company, sometimes a designer has a better idea how to solve a problem, legal has some input for a disclaimer dialog or the support raises a few issues. Transparency gives us feedback for requirements, feature design or coding standards from the whole organization and it is essential for a DOmocracy.

Picture Credit: Billy Metcalf Photography via Compfight cc

Summer of Culture – The Beginning

This is the first part of a blog post series about company culture. I’m planning to write 5 posts in the upcoming 2 months about certain aspects of creating a great culture.

What is company culture?

I guess this is the hardest thing to explain, so why not ask Wikipedia about it?

“Culture includes the organization values, visions, norms, working language, systems, symbols, beliefs, and habits.”

Wikipedia – Company Culture

So I ask again: What is company culture? It seems to be very fluffy, but we all know when the culture of the organization is broken, when people have no connection to each other or to the values of the company. People get frustrated, demotivated and tend to do business as usual and the good employees are looking for another job. When people work in a great culture they’re motivated, have the freedom to change their roles, try out new stuff and are mostly very productive. So the benefits are obvious: Why are companies creating frustrating hierarchies, practicing micromanagement and stop employees to be creative? Let’s compare old working cultures with modern ones:

Culture from the past

In the beginning of the last century Frederick Winslow Taylor introduced Scientific Management also known as Taylorism. The goal was to make the workers efficient and mass production predictable. Workers wasn’t supposed to think. They should do their work like machines. The managers were responsible for the thinking part: They managed the workers, planned how much the factory can produce and optimized that system. Perfect for that time… But we still see this behavior in companies nowadays where most of the predictable work has been automated, but some managers/organizations still want to manage every step of the employees.

Company tend to fall into Taylorism because they think that planning everything and having processes for everything makes their business still predictable. But it isn’t a very flexible and agile way of working in the world of lean startups & fast changing requirements.

Modern Culture

New technology and prosperity in western countries requires a rethinking of how to motivate employees and make them feel comfortable in modern organizations to react faster. People nowadays want to work for a purpose instead of just work to survive. In the past we went to work at 8am and went home at 5pm, this has changed. We can work whenever we want, we have emails, laptops, smart phones, tablets. We can write emails before the breakfast at home or restart the production server from the pub at 8pm (watch your beer consume before doing that). Especially the IT-sector have started with changing its corporate culture so work fits more into our modern lifestyle where we look more after how to integrate work into our life instead of balance between life and work. It shifts also the focus away from ‘how many hours we work’ to ‘what did we achieve’.

Modern culture is not about just having free food, table tennis & after work drinking sessions. I don’t say that free food doesn’t help to attract employees and companies shouldn’t do it, but these things doesn’t help if your competitor just have kicked you out of the market with a new and better product. It’s the passion, the purpose and the respect that helps you build the next killer product. Culture is about people.

Summer of Culture

I want to show over the next 2 month how teams can benefit from a great culture, making them more productive, loyal and having more fun at work. I will cover topics how to break down culture from the whole organization to small teams, how to spread culture, how to hire for cultural fit (but also for a diverse culture), how to integrate innovation into the culture and how values can give culture stability and direction. Stay tuned!

If you have a great culture story (or also a bad example) I would love to post them under the Summer of Culture theme. Just contact me and we figure it out!

How Fixing Paper Cut Bugs Makes Customers & Developers Happier

When doing sprint planning meetings we always care about the big user stories. Stories that help the users solve real big problems. But what about the small things that hides in our backlog? These got almost forgotten, marked as “’should be fixed” but “not so important”. Sometimes it would be just a 3 hour job to make pasting pictures from the clipboard into the software work, but we won’t have the time. It’s not in our sprint goals. We have the same problems at Atlassian and that’s why we used a similar concept as Ubuntu is doing for their Linux OS: Paper Cut Bugs!

What are Paper Cut Bugs?

Paper cut bugs are the “low hanging fruits” that get left behind or forgotten. Things that annoys people in their daily work, that would make a huge different and that are often trivial to fix.

A bug, UI annoyance, or an unintended problem occurring within an existing piece of software,
the presence of which makes the product more difficult or less pleasant to use,
that is easy to fix,
that the average user would encounter…
in a default installation of the latest release.

It’s only a Paper Cut Bug if all of the points are fulfilled.

Identifying Paper Cut bugs?

We went through our backlog and marked all issues that looked like paper cut bugs. For new issues the team should collectively decide if this could be a pear cut or a bigger / not so annoying problem. Depending on the size of the backlog and off course how good you have been in the past on fixing these small issues you could end up with lots of those. For JIRA Agile we identified around 50 of those nasty small things that we wanted to get rid of and that our customer hated.

Planning with Paper Cut Bugs

We took those bugs and planned 3-4 of those for a one week sprint. We allocate a few story points for Paper Cuts each sprint and started to fix those. It helped us to still deliver defined “Business Value” and also bring a smile on our customers faces when they found out that it’s now easier to use the software because of a fixed paper cut bug.

So what’s in it?

There’s a lot in it: Issues that customer requested a long time ago gets fixed, the support spends less time explaining small workarounds, happier customers and HAPPIER DEVELOPERS, because at the end of the sprint you have a feeling that you achieved something small but important.

10 Reasons Why Every Team Needs a Chat

In the year 2004 I was working in a development team and one guy suggested to use chat. I didn’t see the advantage to chat with other team mates next door. I could stand up and talk to them directly or pick up the phone. The chat client looked so ugly, I didn’t get notified on new messages, couldn’t see the history and so on. 2011 I joined Atlassian and they were using chat heavily. I must say, my opinion about chat has changed dramatically in the last 2 years. I think every organization should add chat to their communication tools to get rid of the email flood and be better informed what’s going on.

Here are my 10 reasons why I love chat:

1. Real time conversations
Emails are bad for conversations. Chat’s are designed for that. Asking a question, discussing a topic or just a group question: You normally get an answer instantly.
2. Team chat rooms
We have chat rooms for everything: Product development, product design, it administration, football, you name it. Chat rooms helps teams to discuss a topic or connects you with experts of specific topics.
3. Expert chat rooms
Do you know who to call in IT if you need access to a specific server? What was the IT guys name and is he maybe on vacation? A ticket system is too slow. We have expert chat rooms where IT experts or product experts hang around. It’s very easy to raise a question and get the answer within seconds with chat.
4. Real time development information
…at one place: build failures, deployments on the test server, new pull request: It’s our real time notification center for our code. When a build fails a developer can answer through the same channel that he’s looking into it. Our marketing has even connected our chat to Confluence and see edits of pages in a specific space.

5. Documented conversations
Our chat records every message. Even when I was not online I can look up what the team has been discussed. I also go back to conversations if I know that someone shared a link or a file with me that I can’t remember anymore.
6. Remote team discussions
I work remotely. I can’t imagine how I would share the link of our daily video conference, an update of a new presentation or just my actual experience at a dev conference with the rest of the team. No matter if I sit at home or being on the road: It’s my instant and always available connection to my team!
7. See who’s there
A green bubble next to my team mates name tells me if he/she is currently online and I can expect an answer immediately. When the person is not available I decide to write an email (yes, we also do that sometimes) or I write him/her anyway (see reason 8).
8. Offline notifications
When I’m offline or not at my desk for some time (yes, that happens) and someone writes directly to me or @mentions me in a room, I got a notification on my mobile and additionally an email. This way people avoid writing an email directly and I would answer through chat when I’m getting online again.
9. Emoticons
Never underestimate that: It’s hard to express emotions through text. In modern chat tools you have the possibilities to use emoticons, little pictures to show your emotions. If you’re surprised, just add (boom), which will look like (If you use HipChat here’s a list of all emoticons).
10 Chatterbots
Bots are a great way to find all kind of informations: Which product version runs on our test server, when was the last deployment or ask if the current build on the master branch is green. Just ask the bot!

Chats can replace emails for a lot of situations, helps remote teams to grow together, can keep information in one place and act as a notification center… but it can’t beat face to face conversations and meeting people in person.
BTW: We use and love HipChat at Atlassian!