Git & Continuous Integration – Does that work?

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?

Advertisements

Don’t use Git

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!

Hiring Kick-Ass Developer

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!

Kick-Ass Software Testing

If you want to be a Kick-Ass developer you care about the quality of your software. The QA shouldn’t be responsible for finding your bugs. At Atlassian QA means Quality Assistance. For each 13 developer there is one employee working in QA. And we think this a great ratio! Sometimes QA departements see themselves as the quality keeper of the company and often they are a bottleneck within the organisation. Features are new Versions are waiting for the approval to be released.

QA

Developers are Tester

..or as we call it at Atlassian DOT -> Developer on Test! We want our developers to test the features they produce to raise the awareness for quality. We want to move fast so we have a passion for quality but are not obsessed with it. So Developer picking tasks from other Developers and test them. This way developers are feeling more responsible for the quality they produce. It helps them focus on quality when they implement the code. There is not a QA that will find the bugs, just the person next desk. The QA is focusing on providing the Tools for screenshots, picture comparison , test automation frameworks, data generation and so on. Some features are still be tested be a QA employee. These are normally the risky features, that require some more attention and test knowledge.

More Test Awesomeness

To make DOTing really rockin we implemented some more things:

Training: Every developer get some training lessons from the QA about how to test and what to look after.

Training

Pairing Sessions: A developer and a Tester are pairing. This is also part of the DOTing education. The developer is doing the actual testing and the QA person is giving tips and tricks how to become more effective. This helps also the QA team to get a better understanding of the developers mindset.

Split Sessions: In split sessions a developer and a QA employee is testing the same feature at the same time but separately. After the split sessions the two come together and discusses what they found. This way the testing becomes a little bit of a competition where everybody wants to find the most issues and the developer can become better by learning from the QA person.

Blitz Test: In Blitz tests our QA is inviting developers from all over the company to participate in a time boxed test session. The more the better. We are normally testing new features of our software. Some people get the task to test something specific like different browsers others just have to try to break it. The best tester (decided by a jury) gets a cool Blitz Test winner shirt.

Test Recipes: After educating so many great tester the QA employees start writing a test recipe for a feature. It tells the developers what the QA recommends to test. These are done in Bonfire test session so the documentation of test is directly connected to the feature in JIRA. At the moment this is the holy grail of our testing strategy. The QA is only involved in giving advices and it scales quite well. We don’t need an army of QA employees.

Bug Hunter: Another thing we’re currently trying is to implement a bug hunter in the team. Each day or second day one person from the team plays the bug hunter. His task for the day is to find bugs in the currently developed features. This raises the awareness for quality even more.

bug_hunter

More Awareness for Quality

The goal of the QA team at Atlassian is it not to get more people but to be more efficient. With Developers on Test the QA gets more time to work on strategy and it scales way better than doing all tests themselves. They can work on cool tools like a “Flaky Test Detector” or QA plugins for JIRA. For developers it raises the awareness for quality. Before we started with DOTing 36% of fixed bugs got rejected. No we are down to 7%!

Kick Ass software developer

  • are accountable for the quality of the software they produce
  • care about good quality but are not obsessed with it. Speed is still the key for Kick-Ass software developement
  • love the idea to test  the software themselves and don’t have to rely on the time schedule of a QA person
  • are willing to learn how to test better and faster with more fun

Kick-Ass Development Needs Great Design Fast

This one is maybe Atlassian specific but I guess it happens in lots of engineering driven companies: You start with a small team of developers and as you grow you add more developers. Maybe at some state you add a bunch of tester. But what about designer? Developers can do a little bit of design themselves, right? Or they think they can. Design is also an easy thing to outsource. You let your interface design by an external designer and then the developers are iterating on that. The result of all of this can be seen in some older JIRA versions. Great product, but no holistic design or a great user experience.

Starting with Design

menu

The first designers that came to Atlassian had a lot of things to do. When they looked at what the developers have done, they found 60 different implementations of a drop down menu. They all looked different. Our designers jumped into the teams and helped them with the design problems. One of the first things they did was to work on design guidelines. A paper that explained how a button or a menu should look like. Developers are smart people and they learned fast. Every time a designer broke a rule of the design guidelines a developer noticed that and told the designer. That made us think, because we still had problems to find good designers. Why not educate our developers to become designers?

Developers are Designers

Every Atlassian employee need to do a bootcamp class in their first weeks called “Think like a designer”. That helped a bit. But we wanted some design advocates inside the development teams. So our designers recruited the best talents (mostly the front end developers) and taught them for one week the basics about design. We didn’t want the developers to become designers but just that they can help out with some smaller tasks. That helped our design team to get more time on the holistic design, the usability tests, and some more advanced designs. On the other hand it speeded up the development: The designer is not the bottleneck anymore.

Designer & Developers

Designers are Developers

But also designers can help the developers to speed things up. The good old design tools like Adobe Photoshop and Illustrator are pretty static and have a hard time adapting all the cool HTML 5 interaction stuff. It is way easier if the designers can come up with their designs already implemented in code. Why should’t a designer not do a pull request with a new button design already written in JavaScript/CSS? When a designer understands some JavaScript, they can edit the code and make some corners a little bit more round. This saves a lot of overhead time. There is a great blog post from one of our developing designers explaining the details.

Designers are Team Members

One designer at Atlassian didn’t like that team members interupted him just to see the new not finished designs. He set up his desk in the corner of the office so nobody could see his screen anymore. That was a horrible experience for him. He felt disconnected from the team. After 2 weeks he decided to have his desk in the middle of the office. If we have a design task, we need to have opinions from every angle: The product manager, the front end developer, the back end developer and the designer. That way we come up with the best solution. We also set up a design wall for the team where our designer can put up the newest ideas. Everybody in the team can comment and correct on designs just by using a pen. The whole team feels responsible for the design.

great design fast

Kick-Ass Software Development Needs Great Design Fast

Kick Ass developer need to work closely together with designers and even do design tasks. Kick-Ass developer

  • knows that speed is the key. Not everything has to be polished (but you have to know when)
  • with design skills are helping designer, so that the design is not becoming the bottleneck
  • are helping designers to work on code, so you reduce the steps between design and code
  • help designers to become team members and are trying to understand their pain

Kick-Ass Build Automation

robotsAs a Kick-Ass Developer you should automate as much as you can, so you’re able to do more coding. Looking at the development cycle the most obvious automation are your builds. Nowadays I don’t know many teams that are not using a Continuous Integration server that kicks off a build after every check in (in fact I just know one). But how much effort did you put into to making your builds Kick-Ass?

If your builds can execute fast, your developers can react directly when the build fails. They maybe haven’t even started with their next task, so there is almost no context switching involved. The changes are fresh in their mind and they can fix the problems fast. So we want fast builds to shorten our feedback loop. We want to fail faster. Do you know if your build scripts and concepts are effective?

Here are 5 lessons we learned at Atlassian to make our build pipeline kick-ass again:

Kill hung builds automatically

First we start with an easy Kick-Ass advice, that you probably can implement in a few minutes. How do you currently find out if your build is blocking? Well, I guess you have to look at your CI-Server UI if you haven’t set up a notification on build success. If a build hangs for hours you will end up with a lot of build requests in your queue. All modern CI-Server are capable on killing hung builds. Just define a time and automatically rerun the built. If it hangs for a second time you can setup a notification and have a look at it.

artifact passing

Pass the artifact

This is easy and short: Pass your artifacts like JARs, EARs and WARs. You can use something like Artifactory to check in the artifacts you are building or just put them on a file server and grab them from there. Reuse your artifacts if you’re running UI tests or Integration tests instead of building it all the time from scratch. Sounds obvious. Yes, but look how much the JIRA team cut down the build time since we passed around the artifact.

Run tests in parallel

Another way to make your builds fast is to split your test suite into batches. You normally don’t have to run them in sequential order. Take some tests that belongs together and run them on a different server in parallel to other tests. Most of the modern CI servers allows you to install build agents that can be triggered and run the tests on their own. Some tools (like Atlassian Bamboo and Teamcity) allows you to aggregate the test results in a single build result. Atlassian had some awesome success when splitting up our tests and distributed them on different servers. If something goes wrong, we find it out fast.

Have a build strategy

loopsLet’s face it: Even we’re trying hard to make our test fast, there will still be some tests that takes a long time. At Atlassian we test against different databases that works with JIRA. We also have tests for different operation systems and for different browsers. So you can imagine if we automatically test all the combinations it will take some time. But as a developer you want to have fast feedback. You don’t want to work for hours on the next task and get interrupted by a build you broke with your merge 2 hours ago. Also if you have 20 developers each checking in code every 2 hours, you have to start 10 builds per hour. You need to have a lot of hardware to support this or you have a long queue with builds waiting for execution.

We operate in different loops:

  • inner loop: This is starting a build for every commit. We’re just checking out the code, compiling it and run the unit tests
  • middle loop: This is timed (every hour). We take the last successful build artifacts and run some UI tests for the most common browsers
  • outer loop: We ran this every night. A full integration UI test and smoke tests.

That way we tightened our feedback loop. When the middle loop fails things are still fresh in mind. Of course this is the pay off you have with long running tests but we think it is a good compromise.

Look at your stats

Find your very own bottleneck to kick-ass with your Continuous Integration / Delivery / Deployment. Which test takes so long? How often do we checkout the code for a build? These and more statistics can tell you where your bottlenecks are. If all of sudden your build time goes up, you might want to have a look at it. Normally your build server just sits in the corner and works silently. But it is a good time investment to have a look once in a while at the build time statistics.

build-stats

Use more robot power!

As a Kick-Ass Software Developer you:

  • have short build feedback loops to avoid context switching
  • know how long parts of your builds takes
  • constantly work on improving your builds
  • make sure all builds stay green, otherwise you stop the current work

Kick-Ass Code Collaboration

Collaboration on code is important. If we want to do Kick-Ass Software Development we need to get our changes fast, easy and without a big process into the code base and keep the code quality high. I start with 2 problems I’ve seen in software development teams.

Code collaboration problems

The indispensable developer

If you’re a developer that works just in your own codebase without anybody else touching your code, you are in a very unique position. You can commit code changes and apply patches for older versions without notifying anybody else. It’s just you, that have to know the code. But I’ve seen this behavior also when people work together in a team. Especially developers that are working for a long time on the project can have the tendency not wanting to share their code with the rest. These people do it because of two reasons: They are afraid that they got criticized  and they want to save their job and position by making themselves indispensable. This person is a big risk for the company and destroys the team.

The control freak

In other projects you have one or two senior developers. They are so smart and they know the code that well, that every change by someone else needs improvement by them. The other developers in the team (let’s call them shitty developers) have to get their code reviewed by the senior people. If they reject their changes the shitty developers need to change the code again until it looks right in the eyes of the smart developers. Sometimes it takes over a week until a senior person can review the code. They have all tons of other more important stuff to do. You can indicate these “developers” easily when looking in their meeting schedule. Smells like a big unnecessary bottleneck to me.

Kick-Ass code collaboration

With Kick-Ass software development  everybody can change every line of the code. There is no code ownership. When somebody sees a bug, he has to fix it. We share our code to learn from each other. We want to get our changes fast into the master with high code quality to start with the next code changes.

A branch for every task

We use the power of Distributed Version Control Systems like Git and Mercurial at Atlassian. We’ve implemented a simple workflow to avoid having a bottleneck in our development and move fast to the next task. Kick-Ass software developer create a branch for every task. With DVCS this doesn’t cost anything. When the task is done the developer can merge the changes back into the master branch. A task-branch doesn’t life longer than 2 days, so the change set for a branch is small and we can keep the overview. You don’t get lost when looking at the changes. This approach kicks ass because it’s fast, easy and it makes the developer to focus on a small set of work.

Don’t loose the power of CI

We’ve set up our continuous integration server to find all new created branches and apply the built plan automatically to the new branch. So we have an automatic build for each task branch. The developer doesn’t have to care about this. He just gets notified when he broke a test on his task branch. The CI server even deletes the plan automatically when there is no activity on the branch anymore. We even can do a built on a virtual merge: If our developers wants to find out if they will break the built after they merged the code back to the master they can do that without doing the actual merge. This helps us to avoid broken builds on the master branch.

Code quality and sharing with Pull Requests

What about code quality and collective code ownership when everybody can push changes to the master? Oooops, I forgot a detail here. Of course we’re doing code reviews. In Git code reviews are done with Pull Requests. The code author asks some reviewers for their feedback on some recent code changes. The changes are not very big (short living branches) so it doesn’t take long to go through the changes. The task based approach makes it pretty clear what the code change should do. If two reviewers are  ok with the changes the author got notified and merges the code into the master. We normally pick three or four reviewers for a Pull Request just to avoid bottlenecks. Every “approve” counts the same, no matter if it was an expert or a newbie.  The advantage that Git gives you over Subversion or CVS: You don’t have to merge the code before your code review has been approved. Your master stays always clean!

Kick-Ass Developer share code

The most important thing on code collaboration is the sharing part. We can learn from each other and we got to know all parts of the code base. Here are some points to keep in mind on Kick-Ass code collaboration.

  • Kick-Ass Developer are happy to share code with others.
  • Kick-Ass Developer are gentle to each other when commenting on other people changes.
  • Kick-Ass Developer use automation to keep the code quality high and catch problems before they stop the whole team.
  • Kick-Ass Developer trust each other that they won’t harm the code.
  • Kick-Ass Developer can also communicate face to face when an online conversation takes too long
  • Kick-Ass Developer don’t have complicated workflows or processes: branch – code – share – merge

Tools we use:

Beyond Scrum – Is Agile dead?

Since one decade the agile coaches keep telling us how to organize our development. How the awesome agile process gives developers better results and that it will make us happier. People were writing excellent code and delivered good software before we had processes called Scrum or XP.

I visited Devoxx in Antwerp last week and saw a few talks heading into this direction: We keep talking too much about how to organize our software development than caring  about our software. There is some truth in that: Every time we are following a new methodology we think this is the holy grail. It’s newer, it’s better, it makes us happier. Does it? It takes time to learn it, to implement it, to follow it and sometimes you need a certification to become a master. It’s process overhead and we should get rid of it.

Here are some programs that want to guide us torwarts a new more programming centric approach:

The Diabolic Developer

Martijn Verburg shows in his diabolic developer talk how much methodologies suck, how collaboration is bad for our career and how we get rid of tester by just shipping the product. It is very funny to see Martijn ranting on well known agile practices. But he has some point in what he’s saying. We’re hiding behind processes that doesn’t help us move forward. You should watch his hilarious  5 minute video from this years OSCON!

Programming Motherfucker

The methodology from Zad A. Shaw can be explained in 2 words: “Programming Motherfucker“. They’re saying in their Manifesto about Scrum, Waterfall, XP, Software Craftsmanship and Pair Programming:

“We must destroy these methodologies that get in the way of…Programming, Motherfucker.”

The’re also using the agile manifesto and replace every value with “Programming Motherfucker” and they offer a pretty cool t-shirt.

Dark Manifesto for Agile Software Development

The Dark Manifesto is written by Andrea Janes und Giancarlo Succi and is replacing the word “over” in the Agile Manifesto by “not”:

“We are uncovering the only ways of developing software by teaching others. Through this work we have come to value:

  1. Individuals and interactions over and not processes and tools
  2. Working software over and not comprehensive documentation
  3. Customer collaboration over and not contract negotiation
  4. Responding to change over and not following a plan

That is, since there is no value in the items on the right, we value only the items on the left.”

Andreas Janes and Giancarlo Succi explaining in their manifesto white paper that Agile has followed the Gartner Hype cycle and that there is room for improvement.

So, should we shoot Agile in the head?

The great thing is, that people keep thinking about Agile software development or development in general and doesn’t want to follow just a new methodology (but having fun creating a new one). We don’t want to be controlled by smart consultants that tells us how we should develop and after two weeks they leave again leaving us alone with a Scrum Master certification. Don’t get me wrong: I love what Scrum has done for our industry. It helped us a lot to have a more team centric approach, more interactions with the customer, constantly reviewing and improving ourselves. It was great and I loved Scrum from the very first days. Now it’s becoming common sense. We should move on. But instead of creating a new methodology and a leader to follow (can you hear me Uncle Bob?), we should look out for what doesn’t work in Scrum or Agile and fix it. We should concentrate more on development than on methodologies. I call this Kick Ass Software Development. This is not ment to be a new methedology but just some things to consider, that can be changed in your software development. In the next few weeks I will write a couple of blog post with some topics that helps making Agile even more awesome, and fixes some process restrictions.

Let our software development and our products Kick Ass again!

Starting with Public Speaking

Exactly one year ago I did my first talk at a public conference. I wrote an abstract about my experience how to clean up the code of a legacy system. Three weeks before the talk I totally panicked because I haven’t done one slide and didn’t know if I could fill a 60 minute slot with information. I freaked out even more when I saw that I have to speak in the big keynote room with 700 seats. Don’t get me wrong: This was always my dream it was just so comfort in my comfort zone only consuming great talks. Anyway the talk went fine, I felt well prepared and didn’t throw up on stage.

One year later I’ve done some more talks at large and small conferences. It’s not rocket science. If you think there is no story you can talk about, you’re probably wrong. I was thinking the same. But when I told people what we’ve been doing at work, how we ran our team, how we tried constantly to clean our code, I got a great response. People like to hear real stories and want to get inspired by others. It’s a great experience. Here are 5 tips for people who also want to start talking in public:

1. Learn from the masters

There are some great talks out there. My favorite speaker was Uncle Bob. I saw him speaking at Devoxx a few years ago. He just had one sentence on each slide an talked about the topic for 10 minutes. I think this is a great presentation style. But instead of copying him, I tried to develop my style. If you watch different speakers you can get inspired by each of them. Take bits and pieces (gestures, slide design…) and tie them into your style.

If you visit a conference just don’t look for interesting topics but also for good speakers. You will definitely see things that you don’t like (like reading out loud a bullet point list) you should learn from that, too. I saw some great presentations from famous speakers but also some that really sucked.

That said, you should not forget point 5!

2. Preparation takes time

I’m surprised every time how much time it takes to write a talk. Developing a 30-45 minute talk takes me about 40 hours of work (incl. practice sessions): Getting the messages right, finding great examples, looking for more data on the web… and designing the slides. You should put some efforts in designing your slides: FInd good pictures that underlines your message, find the 3 -5 words that tells your message, find a cool color scheme and a good font. It doesn’t matter if you tell your story in 10 or 100 slides. I saw great talks with just a few slides and awesome talks with slides each 30 seconds. It depends on the talk and the presenter (see point 1).

If you’re done with everything you should practice your presentation at least 4 times! Do it loud. You can use index cards for the first run but you should avoid to use them on stage. After my first practical run, I need to change a lot of slides, remove some and add some more. Before I deliver the talk for the first time at a conference I try it out in front of a real technical audience (thanks to my old team mates at REpower Systems SE to listen to it and giving me advices). They can give you real valuable feedback.

You should also record your talk with a screen capture tool for two reasons: One is to listen to yourself and see where you are boring and how you sound to other people. Reason two for recording the talk is to document what you’re saying. I suck updating my speaker notes when I tried the talk 3 times. The talk changes. When I do the talk for the second or third time I just listen to it before and I’m up to date. You can also release it that way on YouTube. You will reach a lot more people online than at a conference.

3. Interact with the audience

It is the first few seconds when people decides if they like you or not. I don’t say that everybody should like you and what you’re saying but it helps if you get a connection to the audience at the beginning. How are you doing that? Start your talk with a story of your own. Get to know the audience. Ask questions. Interact with the audience. Be yourself.

You should also try to be funny. Entertain the audience. I guess, this is the hardest part. I’m not good at telling jokes. I’m even not good at entertaining people at parties. I always try to put in funny pictures that underline my story or say something provocative and smile. At some conferences that works, at others it doesn’t work. If your audience is not reacting or showing any emotion make a pause, give them some time. If there is still no reaction just go on.

4. Adjust your talk

If you’re a public speaker you will probably reuse your material for multiple presentation. There is actually nothing wrong in giving a talk 10 times at 10 speaking events. It’s like a concert: It’s a new talk for the audience… But if you noticed that you stuck with some slides or the talk doesn’t flow don’t hesitate to change something. Improve your talk after every presentation. Don’t hesitate to throw parts away. If you get the same key message to the audience in shorter time, that’s even cooler. BTW: I don’t have problems finishing the talk 10 minutes before the conference schedule.

Probably some people will show up to talk to you after your session. Take the feedback seriously. Think if you can use it for the presentation in order to answer the questions during the talk.

Try to adjust your talk to each audience. Let the people feel like you did this talk just for them. If you’re in another country, put in some local content. Don’t look like a rock star that doesn’t care in which city he is playing. Care about your audience.

5. Be yourself

Maybe the most important thing if you’re doing a presentation. Don’t try to play a role or copy an awesome speaker you’ve just seen at another conference. Tell a honest story from your experience. Also tell how you failed. Don’t look like an untouchable super hero that does everything right. People will feel more connected to you and your content if they see, that you’re a guy just like them. If it comes to Q&A don’t shy away from saying “I don’t know”, if you don’t have an answer to the question.

If you get feedback for your talk, be prepared that not everybody will love you. I like to do talks where I keep pushing the envelope and being a little bit provocative to change peoples mind… Some people are just not prepared to do something new or come out of their comfort zone so they don’t like what I’m saying. That’s alright.

Christian Heilmann has written a blog post with some great advices for people that start to speak in public and want to train in a comfort zone like Power Point Karaoke and regular Lightning Talks.

Effective Feedback – Involve Developers

As a developer I think it’s great if I don’t have to deal too much with customers. They need so much time explaining their complains and most of the time it’s just an issue of wrong configuration, using the software in an unsupported use case or they are not aware of a feature. All these questions can easily be answered by a non Dev person like the support. Of course, we want to fix bugs in the software and get new cool ideas from our customers, so the support can note these and give them in a consistent format to the developers or discuss them in a weekly meeting together with the product owner. That way we developers can concentrate on developing and doesn’t get disturbed by doing support.

The Gmail team is calling this “The Sh*t Umbrella”. They have 4 product managers that protects the 100 developers from customer requests and questions. The developers can concentrate on making Gmail awesome. The product managers take care, that the customers requests get into the product in consistent format. Sounds right?

Well, if you’re doing a product like Gmail it probably makes sense. Gmail has currently 500 million users. That makes 5 million users for one developer. That really wouldn’t work. But do you have 500 million users that uses your product daily and just 100 developers? Do you have a product that is used by your own developers day in and out and you’re able to dogfood with your whole organization? If both answers are “Not really” you should consider to bring developers into the communication with the end users.

DevSups

At Atlassian we have a program called DoS-“Developers On Support”. We put a developer for two weeks into a support team. That helps both sides: The developer get in contact with real customer to learn how to fight at the front line. It’s really important to get the problems first hand from the customer and ask the right questions to understand the root of the problem. The dev becomes a better idea how the software is used in the real world.

But it’s also great for the support people: The developer get to know how the support works. For some problems you probably have work arounds. So the support is telling the customer how to work around a special problem. The development department got a request to fix this ages ago but didn’t hear of the problem anymore just because the support is providing that work around to the customer. Very often developers are saying: “I wasn’t aware that this is still an issue” and will bring it up when he is back in his dev team to fix it. In addition the support can learn from the developers why decisions for the product has been made and can explain that more honestly to the end users.

Direct connection

We also use a public JIRA instance and a community support system that is called Atlassian Answers to connect to the customer. At Atlassian we encourage developers to answer questions through that systems. The good thing: You can do a time box each day (maybe 30-45 minutes) where your developer answer these questions and work without support interruptions the rest of the day. Customer are so happy to get in contact with someone that can fix the issues instead of someone that talks about telling someone who is putting it in the schedule that someone can fix this issue (and most of the time there are even more layers). So it is a win on both sides! The developer get to know what bugs the customer and the customer knows that his issues has made it to the right person. Even if you have to let a customer down on a feature because of technical issues, he will accept the answer better, if it comes from a developer.

The GreenHopper team is discussing all feedback each day in a time box. They come together with the product manager in the morning, looking at all new feedback, maybe set new priorities and answer questions.

Expand the program

But not just developers should be at the frontier line. The management, HR, finance and many more departments should be frequently in direct contact with end users to understand the business better.

Effective Feedback – Blog Series

This is part 4 of my “Effective Feedback” blog series. Here are the currently released articles:

Part 1: Effective Feedback: No barriers 

Part 2: Effective Feedback – Fake it before you make it

Part 3: Effective Feedback – Make it an Experience