svenpet.com

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

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

Some 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

The 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.

The 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.

 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

• Testers 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.

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.

Die meisten Leute denken, dass ein erfolgreiches Softwareprojekt direkt mit der eingesetzten Technologie oder der Qualität des Quellcodes zu tun hat. Das ist ein falsche Annahme!

Es gibt nur sehr geringe Zusammenhänge zwischen der Codequalität und der Popularität der Software. Im Gegenteil: Je erfolgreicher ein Softwareprojekt ist, desto weniger wichtig ist die Beziehung zur Qualität des Quellcodes.

Warum? Weil erfolgreiche Softwareprojekte mehr Entwickler zur Verfügung stellen können, um Fehler zu fixen und Benutzer, die diese Fehler aufdecken. Das macht das Thema Codequalität irrelevant, wenn man nur die Benutzbarkeit der Software betrachtet.

Das Facebook Phänomen

Die gleiche fehlerhafte Annahme führt auch dazu, dass man Sachen sagt, wie PHP sei eine gute Programmiersprache, weil sie für Facebook verwendet wird. Das ist natürlich Unsinn: PHP ist eine fürchterliche Programmiersprache ( Wer kann mich vom Gegenteil überzeugen?). Aber wenn das stimmt, wie hat Facebook es dann geschafft, mit PHP so ein erfolgreiches Geschäft aufzuziehen? Weil Facebook viele Programmierer eingestellt hat, ihren eigenen Compiler geschrieben haben und vieles mehr. Und wie wir alle wissen, geht auch mal was bei Facebook nicht mehr. Aber es macht ja auch eigentlich nicht wirklich was, wenn Millionen Benutzer für ein Weile eine merkwürdig gerenderte Timeline sehen oder man für ein paar Stunden bei Kommentaren nicht den “gefällt mir” Knopf betätigen kann.

Ist die Qualität des Quellcodes überhaupt relevant?

Die Codequaltät ist dann wichtig, wenn etwas geändert oder erweitert werden soll. Wie schnell findet man die Stelle, die den Fehler verursacht hat? Wie einfach sind die Änderungen vorzunehmen? Bin ich sicher, dass meine Änderung keine nicht gewollten Seiteneffekte hat? Der Wert steckt also nicht in dem was wir entwickeln, sondern in dem Entwicklungsprozess selbst. Vielleicht ist die Qualität doch für das Produkt relevant, wenn man die Änderung auch einfach Weise auf ältere Versionen anwenden kann. Dann wird Codequalität auch für das Produkt selbst wichtig.

Wer also nicht nur ein Produkt entwickelt, dass nie mehr geändert werden muss, oder man unendliche Ressourcen besitzt, ist die Qualität nicht wichtig. Aber Achtung: Auch wenn man der Meinung ist, dass man gerade an einer kurzlebigen Software arbeitet, die bald von einem neuen, besseren System abgelöst werden soll, sollte man sich zwei mal überlegen, ob man keinen Wert auf die Qualität legt. Ein solches Projekt habe ich nämlich noch nie gesehen!

Thanks to Jed Wesley-Smith for the inspiration! Jed wrote a post with this content on our internal blog. I added my own conclusions but this post contains his thoughts on quality vs. popularity. Great idea.

Hast du nicht schon einmal gedacht: Ich bräuchte nur ein bis zwei Tage, um mal kurz den Quellcode an der einen Stelle hübscher zu machen? Oder wolltest du nicht schon mal gerne ausprobieren, ob die neueste Version der Bibliothek wirklich schneller ist? Ich habe solche Aufgaben normalerweise immer zwischendurch reingeschummelt. Wenn es so aussah, als würden wir das Iterationsziel locker erreichen, habe ich schon mal ein hübscheres (aber nicht notwendiges) Design einer Maske ausprobiert. Ich hatte dabei meistens aber ein schlechtes Gewissen, da ich Arbeit gemacht habe, die nicht mit meinem Chef oder dem Team abgestimmt ist… Dabei haben die daraus entstandenen Veränderungen meist ein großen Impact gehabt. Teilweise wurden daraus auch größere Projekte. Wie wäre es aber, wenn es vollkommen OK ist, für einen Tag die Woche eine sogenannte Slack Time vom Arbeitgeber zu bekommen? Cool, oder? Wir nennen es 20% Zeit bei Atlassian. In dem Video spreche ich noch einmal über die Einzelheiten:

Was wollen Softwareentwickler? Richtig: Software entwickeln. Was nervt Softwareentwickler? Richtig: Excel und Word. Wenn es zu Projektberichten kommt, kommen wir aber leider meist nicht um diese Tools herum. Wir müssen Daten aus den verschiedensten Tools zusammensammeln. Leider bietet jedes Tool ein anderes Exportformat an und manche Daten kann man nur manuell abschreiben. Und dann? Dann müssen wir doch Word oder Excel öffnen und Diagramme für das Management erstellen. Versteht mich nicht falsch: Es ist extrem wichtig zu verstehen, wie unser Team und das Projekt performt. Man kann so viele Dinge aus den Daten ablesen und schnell reagieren, falls was schief läuft. Was können wir also besser machen, damit die Aufgabe nicht eintönig und nervig wird und wir weniger Zeit darauf verwenden, an Berichten zu schreiben? Die Lösung heißt: ROBOTER. Was das bedeutet, erkläre ich im Video:

Wer hört nicht gerne ein Lob auf der Arbeit? Leider machen wir das viel zu selten! Wir sollten viel öfter zu einem Kollegen gehen und sagen: ” Das hast du echt gut gemacht”. Genau das zeigt demjenigen, der das Lob empfängt, dass Kollegen die Leistungen beachtet und anerkannt haben. Wenn man beispielsweise an einem Feature bis spät abends programmiert hat, damit es noch in das nächste Release kommt, ist es Zeit für Kudos. Oder wenn ein Mitarbeiter sich endlich einmal die Zeit genommen hat, die hygienisch vernachlässigte Küche aufzuräumen, vergeben wir Kudos. Kudos gibt es bei Atlassian für außergewöhnliche Arbeiten. Bei Lösungen, die unsere Erwartungen übertroffen haben oder die uns überrascht haben. Aber was sind Kudos und wie bekommen die anderen Mitarbeiter mit, dass jemand außergewöhnliches geleistet hat? Schaut euch das Video an:

In meinem letzten Blogpost habe ich die Bilder von unserem absolut atemberaubendem Büro in San Francisco gepostet. Meine Erfahrungen nachdem ich eine Woche dort gearbeitet habe: Absolut motivierend… mehr Arbeitszeit dort zu verbringen. Ja, das ist wahrscheinlich der Nachteil dieser Arbeitsumgebung: Man arbeitet mehr, da es einfach cool ist im Dschungel in der Hängematte zu liegen und die neusten Tweets zu lesen. Durch Massagestühle und kostenlose Verpflegung schafft Atlassian auch eine  Bindung mit dem Mitarbeiter. Wer möchte den gerne wieder zurück in ein 30 stöckiges anonymes Bürogebäude, um dort eine Kick Ass Software zu programmieren? Hier also noch einmal das neue Büro als Video: