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.
Products these days are complex. If you think about how many people are involved to gather requirements, to discuss priorities, to write the software, maybe create hardware, to test each feature, to come up with a great design and to operate or distribute the products… not talking about marketing, finance & controlling here… Building great things is a team effort nowadays and communication is the key for success:
40% of creative teams productivity is directly explained by the amount of communication they have with others to discover, gather, and internalize information. [source]
How does information flow? Another statistic tells us that 70% of the information exchange is driven by the team lead and only 30% inside the team. The boss is a bottleneck: Information should flow freely inside the team. How can we change this situation and foster more collaboration inside and in between teams? Here are my thoughts for a collaboration revolution:
Problem: Physical isolation
A lot of workspaces are not designed for collaboration: A hallway with some doors left and right… How should information flow here? Open space offices foster collaboration. You can see who is there and start a direct conversation. Putting up open workspaces with couches, arm chairs or bean bags are great to work somewhere else but at your desk and have spontaneous discussions. When I’m in the Atlassian office in San Francisco I use these places to show that I’m not working on a very intense task that need all my concentration but be ready to be disturbed. On the other hand you should have mechanisms to show people that you don’t want to be disturbed because it will destroy your current flow of work. Some teams are indicating that by using headphones, even though they’re not necessarily listen to music or having a dedicated person on the team that is answering questions for the whole team (doing kind of support).
There is also a need not to isolate specialist. We know that cross functional teams are a great idea. Having a designer in the team when working on the new user interface is making decisions fast and understandable.
Problem: Communication barriers
Three communication barriers are making communication hard: Places, people and timing.
Places: It’s hard to get the right information when you work in a remote team, in a coffee bar or at home. But if you want great people, you probably won’t find them in your town and it’s hard to move them because the competition are already offer them working remotely (do you hear me Marissa Mayer?).
People: Employees keeping information on their hard disks, in Emails or in their own heads. Information are exchanged on hallways not accessible for all employees.
Timing: Meetings are a killer for individual productivity. They have to fit in everybody’s schedule. We also don’t work synchronized anymore! When someone is doing a coffee break another one just works on a great idea she just had at the same time.
We use our collaboration platform Confluence for tearing down the communication barriers. We once had a post on Confluence where our support expressed their feelings how unhappy they are with the work load and conditions. Independent of place, role and time zone other employees from Atlassian were commenting on that post adding arguments and trying to find solutions. After one week we put together a program for better work conditions in our support. We wouldn’t have accomplished the same results by inviting stakeholders to a local meeting.
Also chat is helping a lot when hitting a timing or place barrier. One team can start a conversation in a chat room during day time on this side of the globe and another team on the other side can join the conversation 12 hours later during their day time.
Problem: Foggy goals
If goals are not clear, how can we work as a team? I’ve been working with yearly goals that were obsolete after 3 month. But there was no mechanism to redefine those. Also I was missing a frequent check if I’m on a good way reaching my goals or on changing tactics how to reach those . I’m now doing a bi-weekly check on my 3 month goals that reflects our yearly team goals. Goals can be changed easily if the company focus changes.
Goals should also be transparent. What’s the reason that I don’t have the possibility to find out the goals of other team mates and other departments? It’s so important to align your goals to those other teams have.
Problem: Impersonal environments
Definitely the most important part of the collaboration revolution. If we have a good personal relationship to our team mates we know our strength and weaknesses and how to effectively get the work done! But more important: If you have friends at work it’s so much more fun. So what can we do? First have a good onboarding system. At Atlassian everybody needs to write an introduction blog post in their first week. People can make comments on it and learn some personal things about the new employee.
When your organization is growing it’s hard to know everybody. Hubspot is trying to solve this problem with an electronic wallboard in the hallway, showing faces of people and their name. Watch the video and grab the source code.
A few weeks ago I did a presentation on this topic. Here are the slides and a video on German.
The last 48 hours people were tweeting their tech horror stories in five words. This really made my day… but the scariest thing is: I’ve heard most of this quotes in real life! These are my Top 20 tweets:
My nephew creates web sites #fivewordtechhorrors
— Jason Bock (@jasonbock) December 11, 2013
“Who wrote this?… Oh. Me.” #FiveWordTechHorrors
— Liz Keogh (@lunivore) December 11, 2013
Yup, We Need Another Meeting #FiveWordTechHorrors
— Dion Almaer (@dalmaer) December 11, 2013
Weird. That worked in staging. #fivewordtechhorrors
— beerops (@beerops) December 11, 2013
It is only test code. #FiveWordTechHorrors
— Martin Thompson (@mjpt777) December 11, 2013
We are switching to PHP #FiveWordTechHorrors
— Viktor Klang (@viktorklang) December 11, 2013
“It works on my machine” #FiveWordTechHorrors
— Johanna Rothman (@johannarothman) December 11, 2013
“It’s too complicated to test.” #FiveWordTechHorrors
— Andy Hunt (@PragmaticAndy) December 11, 2013
We have to support IE6 #FiveWordTechHorrors
— Adam Yuret (@AdamYuret) December 11, 2013
Oracle has acquired Sun Microsystems #FiveWordTechHorrors
— Steve M (@shmick) December 11, 2013
The coffee machine is broken #FiveWordTechHorrors
— Arnaud Héritier (@aheritier) December 11, 2013
We’re going to use SharePoint. #FiveWordTechHorrors
— Simon Brown (@simonbrown) December 11, 2013
We need a Devops team #FiveWordTechHorrors
— Gareth Rushgrove (@garethr) December 11, 2013
— Andres Almiray (@aalmiray) December 11, 2013
It can't be tested yet #FiveWordTechHorrors
— Adam Yuret (@AdamYuret) December 11, 2013
Let’s update the stored procedure #FiveWordTechHorrors
— Sam Newman (@samnewman) December 11, 2013
Fixed it with global variables #FiveWordTechHorrors
— Seriouspony (@seriouspony) December 11, 2013
95% done, you finish it. #FiveWordTechHorrors
— George Dinwiddie (@gdinwiddie) December 11, 2013
We can add security later. #fivewordtechhorrors
— James Turnbull (@kartar) December 11, 2013
We wrote our own encryption. #fivewordtechhorrors
— J Wynia (@jwynia) December 11, 2013
“The original developer left us.” #FiveWordTechHorrors
— Lou Acresti (@louroboros) December 10, 2013
git push -f origin master #fivewordtechhorrors
— Jonathan Nicholson (@jonathanichlson) December 9, 2013