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
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.
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.
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.
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.
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.
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.
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.
More bots, more details?
I did a presentation about bots at JavaOne 2015. You can watch the video and download the slides.
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.
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!
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.
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.
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.
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.
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.
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!”
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.
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.
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.
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.
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
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.
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.
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.”
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.
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!
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.
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.
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).
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!
After more than 2.5 years working as an evangelist for Atlassian it’s time to look back on why the job rocks but also about the shadow sides. I guess every company have slightly different expectations when they hire for the evangelist role. At Atlassian we want raise awareness for our products and the company in general. We are creating products to help everybody that is involved in the software development process to work happily together. An ambassador at Atlassian has a strong development background and is not shy to talk to developers or jump on stage and talk about development in general. So it’s natural that a developer should fill that role.
My job is awesome
Speaking to developer
When I started I was a normal Java developer nobody knew. I started with going to conferences, was accepted to do some talks, met some other speaker, got invited to do some presentations and then got asked to do some keynotes! I really enjoy staying on stage and the more you do it, the less nervous you get. I say less, because I’m still nervous even speaking in front of a 10-20 people. I love putting ideas in peoples heads where they can grow. If I just can help 2-3 people start thinking more about improving their software development I’m a happy evangelist.
The community is great and people that I was looking up to when being a normal developer are now my friends. This job has open the gates for me to exchange ideas with thought leaders of this industry and believe me: They are also just humans 😉
Being an evangelist involves a lot of travelling in my case it’s about 30%. You hang around on airports, train stations and hotel rooms. Sometimes my travel schedule is so tight that I don’t see anything from the great places you’re speaking. Sometimes I just have to force myself to take a later plane and walk around the city I’m visiting. I’ve seen great places in the last year like Moscow, Kiev (before the situation escalated), Sydney, San Francisco, Atlanta and many more. A great thing is also that I meet Atlassian’s everywhere. We have people from local offices or that work remote in that region staffing a booth, so they can talk to the local customers and learn how our products got used in the field. It’s great to catch up with so many different colleagues.
I got the privilege to decide for myself what I want to speak about, what article I would like to write or new ideas for t-shirts that we should create for trade shows. It’s a very creative job where you have to come up with new ideas and new concepts all the time. What will developer like to hear, what is currently hot in software development, what is Atlassian doing? It’s so great if a create stuff in my home office in my little town in Germany and than the marketing in San Francisco want to reuse it for their global campaigns. This is also what this job is about: I’m the guy on the ground, I talk to many customers, I talk to thought leaders, I talk to developers. From all this information I can maybe create a more appealing angle of the story we want to tell our customers.
And if I think it’s time for me to get my hands dirty I’ll start coding for a while, not creating a product but just to do some small things improving my day to day work.
My job sucks sometimes
When working for a while at home I’m starting to miss colleagues. People that I can talk to each day. HipChat video can help but it’s not the same than meeting them in person. We’re trying to do team meetings at least 3-4 times a year in Amsterdam and San Francisco. The switch to not creating a sustainable software that people use each day was kind of hard for me. I now got used that marketing is a much faster business and collateral you created last month is old stuff and not used anymore. Also traveling makes me feel lonely sometimes. Sitting on an airport or in a hotel room, just myself, my iPhone and my MacBook.
Most of the people I’m collaborating with are sitting in San Francisco. We’re trying to coordinate our meetings that they happen early morning in San Francisco / early evening in Germany. So it’s sometimes not easy to meet friends in pubs, bringing my daughter to bed or taking my wife out to the movies, but it gives me on the other hand the opportunity to bring my daughter to the football training in the afternoon or pick her up from school for going swimming with her.
In the end I must say that I have the best job in the world. You have to be passionate about your products, your culture and the community you engage with. This makes me jump up each day in the morning. I’m looking forward to open the eyes of people to see that they don’t have to suck in software development and that they can be happy developers by changing the way they think about this profession. I’m so pumped to tell people that we have an amazing job: We can be creative, we’re helping people to be more effective and we work with cool stuff. You just have to realize that this industry is dynamic and it changes fast and so do we as developers need to change constantly.
Help me not feeling so lonely!
We’re looking for a team mate for me in France and the UK! Do you want to hang around with me in old hotel bars, spend the night in front of a screen doing a video conference call with people in San Francisco, or just pissing in your pants before going on stage at a developer conference? Sounds great? JOIN US!
“Code Reviews Are More Important Than TDD”
Dr. Venkat Subramaniam
Don’t get me wrong: Test Driven Development is great and it helps with a lot of things: Good quality, maintainable functionality, repeatable tests and much more. We did a survey at conferences that showed us that around 70% of all developer teams are practicing some kind of TDD but just 30% are doing regularly code reviews. Why is that? Here are some explanations why test automation is so much more common:
- It’s automated: Developers love to automate things. You can use a fancy build server and show that your code is running.
- It’s an easy to follow process: You write tests, you write the code, you run the tests. Easy to follow for each individual programmer.
- You do it on your own: There are no dependencies: Developer don’t have to wait for other developers to write tests, no social interaction is needed, the machine tells you if your code works or not.
The benefits of Test Driven Development are obvious, but here is why I think code reviews are more important:
- Better code quality: Reviewing the code by a team member can maybe not catch all functional bugs but it can catch obvious mistakes, correct bad variable, method and class naming and it improves the readability of the code (and we all know that we read code way more often than we write it).
- Learning: When reviewing code developer can learn from each other to write better code. Even intern can give senior devs a new perspective. This is also recommended practice for book writers: Read! But it also helps to understand the whole code base and not only the parts you are normally working with. You will review code from other parts of the system that you maybe were afraid to touch yet.
- Feeling better: Having another developer looking over your code before it goes into production can make you feel better. You don’t feel that you’re the only one responsible for a potential bug. There are others that haven’t seen it either!
Code Reviews with less meetings & better tools
So what’s the problem with code reviews? Why are not all teams doing them? First we should all agree that the time reviewing code is well spend! Some teams practicing a meeting every week to look at the code written the last 5 days or at a special feature. These can be a painful sessions for various reasons.
Make reviews less painful with tools.
When we discuss code in front of the whole team it can be hard for the author: Everybody is staring at his code and give comments. I’m not saying that it can’t work, but here we have the same social problems as we see with Pair Programming (and there’s just one guy looking at your code). I’ve seen people not showing up or coming with stomach problems to work because his/her code was on the schedule for the code review meeting that day.
A tool like Gerrit, GitHub, Bitbucket, Stash or Crucible can help because the author has more time to about the feedback and don’t feel like going into defense mode right away. In code review tools authors can invite other developers to participate in the online review. You see the code changes and add comments to the code. Developers with strong opinions won’t take over the review in tools that easily and others that may be a bit more shy have a lower barrier to participate in the review. But the same rules apply also for online reviews: Be gentle!
Make the review part of your process.
Don’t make code reviews an end-of-the-project event. Reviews can get long and boring. Keep them small. For people that already uses Git with feature branches this one is easy: If you want to merge changes back to the main branch you can create a Pull Request. Git tools like Bitbucket, Github or Stash have a visual interface to make comments. No change will touch the main branch without a review (if you want). Just make it a natural part of your process: If you have a change, it needs to be reviewed. Keep changes small so people are not afraid of reviews. A task is not done if the connected code review is still open.
Some tools also offer the ability to see the code changes in context. What’s the problem these changes should solve? Most code review tools let you connect to an issue tracker to be able to jump from the review directly to the issue.
If you still prefer review meetings do them regularly, so people get used to them. I think once a day would be best but at least two days a week. Never cancel the meeting because of too much work and try to review every change. If you can’t run through all changes split the group and rotate the group members.
Review code when it fits into your schedule.
That’s a problem with another meeting on our schedule: They never fit into our personal flow. If you do code reviews in tools you can do them whenever you got time: In between programming tasks, first thing in the morning or after the lunch break; independent from team mates and their schedule. Also: Don’t expect every reviewer to finish review your code. Someone will always not make it within one or two days or gets sick. Have a rule that you invite maybe 4 people and mark the review as finished when 2 people have approved the review. Just make sure that it’s not always the same people that are not reviewing the code.