Power to the Developers

10 Jun

fistI never understod why companies are building a strong management driven culture and destroy the creativity of the developers. We need freedom to build awesome software with great quality fast. That’s why some people see us as the prima donnas in a company. When our management gives us the freedom of choosing our own tools and processes we have to turn that trust into productivity and quality. We have to find a great development culture that we live and breathe every day. Culture is so important:

“Culture eats strategy for breakfast”

Peter Ducker

These are my 7 points how to build a great development culture and give the power back to the developers. It may not be complete but things can’t go really bad if you can follow these things:

1. Find a way to deal with customers

png-4Customers suck! They find all the bugs and call you in the middle of a great pair programming session and destroy your mojo. It’s not a good solution to let just the support or some product managers deal with customers. Try to send developers to your users. Let them see how the tool is used that they are creating day in and day out. It’s not easy to find the right balance between “Getting things done” and learning the needs of the business. But your culture should make this absolutely clear: Everybody has to be at the front line and know what’s going on in the real world. Do daily stand ups and discuss customer requests. Meet customers frequently. This gives us the power to build the best software from a technical and a usability stand point.

2. Don’t be evil to your software (and don’t let other people tell you to be)

png-1We all had this situation: Your boss or your customer asks you to do a quick hack. Just a small change that will drain your quality or it will just look bad. We want to please the people that are responsible for our payment. BUT: We have standards. We have to deal later with the technical dept. We have problems with scaling the software. Stay true to your principles. Say: NO! ..and at the same time try to educate your boss or your customer why this is a bad idea and why it’s important to hold your software development values high.

3.  Show people why they are important

pngWhy do people go to work every day? Yes, to earn money. But this kind of motivation is losing more and more traction nowadays. If you earn a certain amount of money, rewards doesn’t motivate you to be more productive in the long term. People want to get appreciated by humans for what they are doing. Not just once a year when you have your yearly conversation with your manager. Do it whenever you think: “Cool, that was great”. I had a great experience when I’ve send one guy from the team to the customer just to see how they use our software. He came back and said: “They really are productive using our stuff. They love it”.

4. Do your own thing

png-6There are so many good ideas out there in the world. Don’t follow all of them. You should just pick those, that makes sense for your team. Don’t try to implement Scrum by the books. See what works, what doesn’t, get your own ideas and try them out! Don’t follow blindly another Guru that is trying to teach you the right way.
Developers should have the right to decide what works best for the team. But we’ve been studying for years, we fix problems every day and can’t decide how we work best? Developers should be treated like grown ups, not like 13 year old school boys. If we think a tool makes us more productive, let’s buy it!

5. Learning is everybody’s own responsibility

png-3The company can send you to conferences or workshops and they can buy you books. But lets face it: You won’t learn anything from a 45 minute talk or if a book is just laying in the shelf. You have to take action! Nobody can help you with that, it’s your own responsibility. And we have to learn if we want to know what’s going on. Yes, there are some things to do together like coding katas or brown bags. But also here: It’s still the decision of each employee to take that power and use it for something good.

6. Change is the only constant

png-2Do I have to say more? Think constantly about what sucks in your software development and change it! Don’t be afraid of new things or to pull the plugs on things, that have just currently been implemented but really doesn’t work out. Change and improve constantly.

7. Focus on quality and dev speed

png-5Depending on the product you’re developing one or the other is a little bit more important. It’s sometimes hard to find the balance: If you  put too much effort in quality, your deliver speed will slow down. If you’re delivering like a maniac, your quality will drain from that (you will see it in the long run). It is really important to always keep thinking about these two factors and to talk about them in your development team.

Credits for the pictures:
Couple designed by Jens Tärning from The Noun Project
Electrical Shock Warning designed by Travis Yunis from The Noun Project
Blindfold designed by Luis Prado from The Noun Project
Approve from The Noun Project
Interchange designed by Laurent Patain from The Noun Project
Speedometer designed by Olivier Guin from The Noun Project

Being an Evangelist

29 May

I just got reminded, that I work now for almost 2 years for Atlassian as an Ambassador. First I was very concerned working for the dark side (the Marketing departement) from a developers view. But it turned out that it’s pretty cool to be a bridge between the 2 worlds. Even though I would love to do more coding I enjoy the job so much! I know that a picture says more than 1,000 words so I created a video with a lot of pictures… what would be worth a 100,000 words. So here is my life the last 2 years in 3 minutes.

I learned a lot the last 2 years, more than I can put in a blog post. But here are some things I discovered to be important.

5 tips for becoming a kick-ass evangelist

1. Create slides that rock

Yes, your presentation style and your message is the most important think for a talk…. but a lot of people look at your slides and watch them later on slideshare. (6,600 developers saw them on a screen, 30,000 on slideshare). I discovered that creating great slides is my thing and I can spend hours working on just the details.

2. Practice, practice practice

…and if you think you are good and are sick of trying your presentation again: It’s time to practice more! Yes it takes one hour to do a total test… but if you speak in front of let’s say 300 people you better be really good prepared and don’t waste 300 developer hours!

3. Prepare your travels

Travelling is sucking your performance. Use time in buses, planes and train stations. I prepare my travel by downloading everything I need to get the job done on my laptop. Internet sucks normally everywhere, but at home or in the office. I normally do translation stuff, blog posts and abstracts for talks during travelling.

4. Make connections

Instead of waiting for the Internet to work at a conference, use the time to talk to people. Hang out in the speakers or attendees lounge, go to the speakers dinner and attend conference parties. I met so many awesome people everywhere I go, it’s amazing. The conference world is small and you will definitely meet people elsewhere. Try not to be shy to talk to your idol…

5. Use the power of social

I was amazed how a message can spread when I wrote my most popular blog post “Don’t use git” (20,000 views in one week). I don’t know which channel was the most successful or which retweet started the domino effect. I just post a new blog on LinkedIn, Xing, Google+, Twitter you name it. And I guess I’m missing also some opportunities, because I’m not aware of them.

Some statistics

Here are some statistisc from the last 2 years:

  • I created 28 different slide decks
  • I delivered 40 presentations
  • I spoke in person in front of 6,600 developers (incl. 2 conference keynotes)
  • I reached 4,000 online video views
  • and 30,000 on slideshare
  • I wrote 3,000 tweets
  • I did 115 personal blog posts
  • I had 70 flights

Thanks Atlassian for creating my dream job and my kick-ass team for helping me becoming a better ambassador!

10 Development Culture Smells You Should Change

6 May

Sometimes you don’t know where your team sucks. Here are some smells that can destroy your team culture:

Bildschirmfoto 2013-04-29 um 15.33.06

1. Non Coding Architects

If you have these type of job position in your organization you should really think about getting rid of it. The team should define the architecture together. If it comes to cross team architecture, send one or two people from your team to a meeting with other teams. It’s just a waste of resources to have a guy that makes the theoretical discussion that got later overruled by the reality.

2. Committee Driven Development

comitteeSome organizations have a committee of stakeholders that decides what to do next. This smells like you don’t finish things probably. You run to the next project without finishing up the old one. If you have delivered a new feature or even a project we all know that the real work begins after that. You need to fix bugs and improve the new feature by collecting feedback from your customer. Involve the team in decisions not just a committee!

3. Developer Primadonna

Do you have a primadonna on your team that thinks technology decisions are more important than customer features and works on implementing the newest framework which is not planned for this sprint? These ego manias concentrate more on the solution then on the problem (if there is a problem at all!). Look out for those guys, they destroy your team culture. Attention: Sometimes it’s hard to distinguish between a primadonna and a passionate developer.

4. The Perfect Software

You have to release one month later, because the software is not ready? You need to test more? You want to make the feature to be perfect? Looks like you’re afraid to release your software! It’s not that hard anymore to fix bugs after a release: You don’t have to send disks around, just push the changes to the servers or have the possibility to auto-update a desktop application. Concentrate more on deliver things than deliver perfectionism.

5. Quality is the job of the QA

In bigger organizations you have a QA department which is testing the software. Developers think that bugs got found by the QA and they just have to fix them. WRONG: It’s the developers job to make sure there are no bugs in the features! That’s why testers should just help with testing, creating test data and maybe help with automation. Quality is everybody’s responsibility. The developers should be accountable for their work!

6. No Shared Vision

7251221186_419c51efdfThe team has a different or none opinion how the software should look like in one year. Start asking around in your team if they have the same vision of the product. You all should have the same goal, otherwise you can’t be passionate about what you’re doing every day. You know if you’re back on track if you could send every team member to a board meeting or to a customer in order to talk about the future because you share all the same vision.

7. Featuritis

If your software has a lot of features and it’s very flexible, but hard to maintain you probably suffer under Featureritis. If you fix something in one end you brake something in another end. Maybe you can’t say ‘No’ to your boss or your customers. Please try to concentrate to do a few things right than doing a lot of things just alright. Try to branch your product and learn to say ‘No’ , but maybe you’re also missing a vision (see point 6)?

8. Addiction to Final

Your team can’t estimate anything until everything is sketched out in detail. Of course, they should know the whole story but they  should also be able to estimate parts of the story. If this is your problem you’re probably still in love with waterfall. Gain confidence inside your team that you just concentrate on a small feature set right now and see if the rest is really needed at the end.

9. Legacy Team

You still stuck with the same process than 5 years ago? You haven’t changed your development tools in years? Looks like you are afraid of change. If your team becomes legacy and can’t see the problems anymore or don’t know how to change things you should do something. Software development has changed dramatically in the last 5 years, tools are in the cloud, we have the technology to release quickly and working from home to get things done. Get out of your comfort zone!

10. Process after process

You have too many restrictive processes if you need a signature to start with a feature. If you just added some getters and setters that has to be reviewed before the deployment or you your cool new idea will take 1 week of development but 2 month of justifying. These processes are killing your development speed and stopping you from doing great work. You should just switch some processes just with rules to follow.

Blame Driven Development – finally a methodology that works

1 Apr

blame driven developmentThe development can be driven by a lot of things: TDD (Test Driven Development), MDD (Model Driven Development), FDD (Feature Driven Development), BDD (Behavior Driven Development) and much more. Do we really need a new kind of development? Yes! All other forms are describing the workflow during the development. With Blame Driven Development just the result is important! How a single team member reaches the result is not defined and can individually be chosen. Blame Driven Development encourages the competition between coders. The goal of BDD is to frighten programmers not to be the worst one with the most mistakes and bugs.

How does Blame DD work?

Here are the rules:

  • Every developer has a personal account of finished story points.
  • There is just one developer responsible for a user story. The finished story points per sprint gets added to his account.
  • If somebody finds bugs in a finished user story some points got subtracted from the authors account.
  • Instead of planning the sprint with an average velocity of the last sprints the team plans double as much points for the next sprint. That encourages people to work harder and most likely someone can be blamed at the end of the sprint for not reaching the goal.
  • The developer with the least amount of points at the end of the sprint has to explain at the next board meeting why the development is so slow.

blameDD

 Here is how you implement Blame DD

  • The customer or product owner is just allowed to write the story with just 140 characters. If the story hasn’t been implemented to the customers satisfaction story point got subtracted from the programmers individual account. This encourages the coder to be creative and he need to think more like the customer. Developers that are practicing Blame DD are understanding the customer much better. In addition to that, the coder fears to do something wrong and that pushes him to a better performance.
  • The Scrum Master reads out loud the reached points for every programmer during the daily stand. That motivates the individuals to become the best developer in the team. Pro Tip: Doing the Stand Up in military style let the team members understand that it’s not a game and the development is a critical part of the business.

Reduction of Points

  • hall_of_blameTesters are called inspectors. They maintain a checklist and are subtracting a point for every found bug.
  • You can also use one person as a code inspector. He is allowed to subtract points for bad variable naming, not folling coding conventions etc.
  • A good ratio of inspectors to developers is 1:1
  • It is also possible to have negative points (this is actually the norm in Blame DD)
  • Every subtraction of points should be discussed in the daily stand up. It should be possible to blame somebody else for the mistake.

Additionally

  • If a bug is found in the production system, everybody has to stop working and find the guy who is responsible for the bug. He will be blamed on the web page publicly. It is not so important in Blame DD when the bug actually will be fixed.

Pro tips for Blame Driven Development

  • If you reached a certain amount of story point for a sprint you should concentrate to find bugs in team members code.
  • Use a tool that checks in the code under a different name. Just implement an infinitive loop and merge it into the main branch with the name of a team member. It’s so much fun to see people trying to defend themselves in the daily stand up.
  • Don’t do pair programming. It has been shown, that the pair programming partner will smuggle in buggy code when you just visit the toilet for 5 minutes.

Fear is such a good motivator for pushing people to better performance. Let’s blame the ones, that are not performing! I love to hear your experience or ideas about Blame Driven Development. Use the comment function to give me feedback and share your thoughts with the big Blame DD community.

Git & Continuous Integration – Does that work?

11 Mar

In my last blog post I was mentioning 6 arguments why you shouldn’t use Git. While 5 arguments were obviously meant to be sarcastic (who can really think that slow operations like searching the history in SVN can be an advantage) there was doubt about one argument that can be tricky:
Git destroys the idea of continuous integration
In Git you are using branching heavily. Let’s assume everybody’s working on feature branches. Then somebody is renaming a widely used interface or class and checks the code into the mainline. If you don’t integrate your feature branch early this can result in lot’s of conflicts.

Some people favor solutions with an integration branch. People integrate the changes from their feature branch on an integration branch. If the CI-Server has build the software successfully and all tests passed, the changes get automatically pushed to the mainline. That way the mainline stays always deployable and green. I don’t like this solution: The integration branch is basically the mainline. But if a build fails, it is not so important to fix it. Not my understanding of continuous integration.

I stil prefer the SVN statement: “Commit early, commit ofter” what should be translated for DVCS into “Push early, push often”.

Solution 1: Making the mainline the communication point again

Bildschirmfoto 2013-03-07 um 13.23.50

Switch from SVN to Git and work as you have before. Don’t branch, just push your changes to the mainline on your central repository. You still benefit from fast history searching, offline capabilities and much more. Just beware that if you once started with Git, you’ll probably come to use also the awesome branch features, that drags you into a different workflow.

Solution 2: Promiscuous Integration

Bildschirmfoto 2013-03-07 um 13.23.22

Martin Fowler has written a great and much more detailed blog post about Promiscuous Integration. Basically people talk about changes and integrate the changes from feature or personal branch to another. The way changes got also continuously integrated in each others feature branches. When it comes down to pushing changes back to the mainline, you won’t experience lot of merging pain: Changes have already be integrated. Martin is pointing out, that this requires communication between developers and this can go wrong. There is no clear rule which changes you should integrate into your personal feature branch.

My favorite solution: Feature Toggle + Task Branch + Automatic Push!

Bildschirmfoto 2013-03-07 um 13.23.07

With Feature Toggles you design your software that you can turn your feature on when it’s ready. When currently developing the feature is usually off so you can deploy the software immediately. A feature can consists of many tasks. I like the idea to have a branch for each task and push changes to the mainline when your task is done. I assume a Task Branch doesn’t live longer than 2 days. That way you still continuously integrate your changes and work focused on your branch.

You could combine this with a feature Atlassian has build in their Continuous Integration Server Bamboo: Automatic Pushing. If the mainline changes and the build went good, Bamboo is trying to push the changes automatically to your task branch. That way you have always the latest changes in your branch. I guess there is also a plugin for Jenkins available, I just couldn’t find it ;)

In my opinion this is the best of all solutions: The mainline is your communication point, you recognize conflicts very early, merging is not to hard and you have done some things to keep your mainline up-to-date and  your builds green.

Another thing that your CI-Server can help you with is running a build of a potential merge. Before merging for real you can see if your build will succeed or not without pushing your changes already. Jenkins with Gerrit or Bamboo with Stash can be set up for such a workflow.

These are just my thoughts. I would like to know what your experience are with CI and Git. What works for you in your organization?

Tags: , , , , ,

Don’t use Git

21 Feb

no_gitEverybody keeps telling you that Git is better than Subversion. You keep hearing Git has better workflows, offline capabilities and  is faster. But should we really jump on every new technology that is coming around the corner? Your source code is the heart of your software developement and you want to store it with a tool that is working. Here are 6 reasons why you shouldn’t use Git at work.

1 – Git destroys the idea of Continuous Integration

ic_action_collapseGit encourages you to use branches for your development. But when you work for 1 or 2 days on your branch, you’re not continuously integrate your code changes with those from your co-workers. You don’t know if someone changed something important in between that collide with your changes. And if you want to have your build server automatically build your development branch you need to copy the project for each new feature branch.

2 – Developers can be offended

ic_action_sadSVN has this great feature that if you merge a branch to the trunk you lose all commits of the branch. This is great because the developer that has merged the changes is the one that is responsible for the changes. The dev manager can not blame you for a bug. Git keeps all the commit information from a branch when merging to another branch. You can blame the programmer  directly. There is no technical protection for developers anymore.

3 – Git destroys the team experience

ic_action_usersWith SVN merging a change into the trunk is a real team experience. When you see conflicts you have to talk to the two developers that have changed the same code and find a solution. Because of the fact that merging with Git is different you end up with less conflicts and less possibilities to discuss the code changes directly with co-workers.

4 – Developers have too many options

ic_action_playback_schuffleWith Subversion you have a simple workflow for adding your code to the repository:

1. You merge your local changes with the trunk on your machine.
2. You commit the changes.

I will not mention the second workflow (branching) because there are lot’s of discussions not to use branches in SVN. We have one simple workflow that everybody understands!

Git gives you the opportunity of  lot’s of different workflows you can adapt and even combine: Having a Gatekeeper for your main branch, do cherry picking or let everybody pull and push to everybody’s development branch. What a mess!

5 – Git makes people work overtime

ic_action_clock

Subversion requires a server to search the history, create a branch or commit code changes. Git stores the wholes repository on your hard disk (what a waste of disk space). This makes it possible to work without network connection with the same possibilities as if you are in the office and connected to your SVN-server. It’s the perfect argument for your team lead to ask you to work over the weekend from home to hit the deadline of the current project. Don’t use Git and let this happen!

6 – Git is unsocial

ic_action_micoff

Subversion gives you time to socialize when creating a branch, checkout a branch or even switch beween branches. You get some time to chat with co-workers, go to the kitchen and grap a cup of coffee or to write comments on facebook. Git changes the game for the worse: Due to the fact that you working just on your hard disk to do all this tasks in Git, it is faster and you lose the natural social time. It’s good for your dev-manger but bad for knowing what’s going on.

It is pretty clear that we shouldn’t use Git at work. Why should we change at all? SVN is a mature technology that has been around for more than a decade. There is no reason to change to a just 8 year old repository technology. Let’s face it: It’s great for open source but in a corporate environment  offline possibilities and advanced workflows are not so important. We have been working for ages with centralized version control system. Think about the knowledge that is in the SVN community. Some people will be out of jobs if all companies switch to Git.

Don’t let that happen. Don’t use Git!

UPDATE : Did you git it? 

Due to the confusion people have whether this article is meant to be funny or sirous: I love Git and I think it helps teams to do a better job. It solves a lot of problems that we have with SVN. Don’t let our children grew up in a world of Centralized Version Control! Just to be sure you realize that this is just a sarcastic blog post.  Hope you had some fun reading it!

Tags: , , , , , ,

Hiring Kick-Ass Developer

16 Jan

Finding people that can kick ass (if you give them the freedom to do so) is not an easy task. Kick-ass developers are not the norm. They constantly think how to improve things, they are passionate about what they’re doing and they have brilliant social skills. How can you find these special kind of people?

At Atlassian we want kick-ass developer to find us. So the first step is to raise some interest in Atlassian as developers paradise. We need to be honest when doing that. If the right candidate has found us, we don’t want to loose him again when he finds out that we didn’t tell the truth about working at Atlassian. From 77 applicants we hire one.

Navigationsgast Hauptgefreiter El Jarraz mit Fernglas (DF)

Spreading the word

We try to attract people by giving them holidays before they even have started working for us. We want people to be fresh and prepared for the job so we give them a voucher for spending a weekend in a hotel with the family. We also encourage our developers to speak at conferences and tell other developers how awesome it is to work for Atlassian. Employees should also blog about their cool framework they are working on, what they learned by using a new technology or just what fun side project they’ve created. It sounds more honest and real if our developers tells that stories to possible candidates.

It is cheaper for us to make people find us instead of trying to find talents through traditional job offers. We got the best people from recommendation from other developers. That’s why we’re giving everybody a flight to a destination of their choice for a recommendation that we have hired.

Finding the kick-ass genes

On one hand you need a system that scales, on the other hand you want to look at each candidate if they have some kick-ass genes. We have developed an online coding test for candidates. Instead of looking for right or wrong answers we’re trying to look for good potential. So if we see some innovative solution to a problem that don’t lead to the 100% right result, we are still interested in speaking to the applicant. One of the first interviews the candidate is doing is with a technical person. If we found a good developer through interviews and pair-coding sessions we are checking if the candidate fits into the Atlassian culture. This is the most important thing that differentiate between a good developer and a kick-ass developer.

Onboarding and ruining developers

Here is where most companies suck: They give you a desk and a computer, maybe a 2 day course and a monthly salary. So why should you complain?

If you have put so much effort in finding the one developer that fits into your team, you should do everything you can to bring him up to speed so he can kick-ass. At Atlassian every employee is doing a boot camp where he learns how the different teams are working, how development is organized, basics about design, testing, product management and so on. The classes are happening in the morning and the new employees are working together with their team in the afternoon. After the 4 weeks of boot camp people are ready to really kick ass. Whoot!

For graduates we have a special program: They are being send to our hack house: One week at a beach with some bootcamp classes, coding sessions and lots of fun to get to know our culture. They are learning how we collaborate, our focus on shipping and what our 5 values means for us.

developers stay

mood_app

One of our goals is to ruin our developers so they don’t want to work anywhere else. We put a lot of effort in creating the best place to work. To find out the actual mood of our employees we’ve developed an iPad app. Employees can easily tell us their mood just by tapping on the screen when they leave the office. This way we can react just in time when the mood goes down. Our open culture allows everybody to blog about things that don’t went well. It’s amazing to see how people react and jump in to help, if somebody sees a problem.

It’s the people, stupid!

The secret of attracting and keeping kick-ass developer is to be picky in the hiring process. Great talents likes to work together with other cool devs, so they can keep learning from each other. You want to make their work environment as great as possible so other kick-ass developers will be attracted by that. Measure the mood of your employees constantly not only through apps but also through personal interviews. Give your employees the confident to complain, the best tools in the world to get the job done and the power to change things. That’s the only way they can really kick ass!

Tags: , , , ,

← Older Entries

Follow

Get every new post delivered to your Inbox.

Join 28 other followers