Archive | September, 2012

Effective Feedback – No barriers

26 Sep

You want to receive feedback for the work you’re doing to get better. Everybody that read Eric Ries book “The Lean Startup” will realize that short learning phases are essential for the success of a new product or feature. You want to know if you’re developing a stunning functionality or if you’re the only one that thinks this feature is fabulous. This is the start of a new blog series on svenpet.com and it is the first post written in English. I figured out that I’m talking at some big international conferences this autumn so I thought it would make more sense to write my posts in English. I hope you continue reading them. If not, please give me feedback through the comments.

Consistent Feedback

Where do you get feedback if you have no strategy? Sure, you’ll receive feedback through email, via phone or when meeting a user. Where do you capture feedback? Don’t tell me you use Excel, please. You should really use an issue tracker to capture the ideas and issues of your users. Why? Because you want your feedback in a consistent way. You want to know which version the customer is using, which OS or Browser, which menu did he use, when did he experience the problem… These information helps you on one hand, to better reproduce the issue and on the other hand to filter if you have a lot of feedback.

Barrier 1 – Where do I give feedback?

Lots of web pages doesn’t provide a clear guidance for their users to give feedback. You have an issue in one menu but you have to navigate to company/contact/feedback to enter your issue.

Put a feedback button in front of the face of your users. On every page. They don’t have to leave the current menu and will be directly navigated to the feedback page.

Barrier 2 – Way too much work / time!

Here is what happens if you gave feedback from your Confluence instance a few month ago:

  • you were directed to our public issue tracker jira.atlassian.com
  • you needed to sign up for a new account
  • you have entered all your details and created your account
  • you were locked in and have found the “Create Issue” button somewhere
  • you needed to select a project
  • you needed to fill out lots of fields
  • FINALLY you pressed the create issue button

If a user of your software has done all these steps they must love your software a lot or hate your software. And this is the problem: You don’t get feedback from all your customers if you don’t lower the barriers. But let’s be realistic: The most feedback you receive will be negative feedback. You will in most cases just get positive feedback when asking your customers directly.

We have learned and changed the way people gives us feedback. We call the tool the Issue Collector and it is backed into JIRA directly. When the customer wants to give us feedback now he has to do the following steps:

  • pressing the feedback button
  • fill out four fields
  • press “Submit”

Barrier 3 – Too much information!

I wrote  that you want consistent information about the version your customer is using or the OS in order to reproduce the issue or to group issues to see patterns. On the other hand you do not want your customer to enter too much information and most of the time they will not do it in a consistent way. Somebody will write in the OS field “Windows” another one “Windows xp” and another one WinXP”. That’s why we fill in information automatically, like project, component, OS, screen resolution, browser version and so on. This way we have the information in a consistent way.

Removing the barrier for customers is essential to receive feedback and the JIRA Issue Collector can help you with that. But this is just Stage 1 for making your software better through feedback. Stay tuned for the next post!

Effective Feedback – Blog Series

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

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

Part 3: Effective Feedback – Make it an Experience

Part 4: Effective Feedback – Involve Developers

Wie wichtig ist Codequalität eigentlich?

17 Sep

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.

Mini-Sprints gegen das Aufschieben von Aufgaben

11 Sep

Benutzerhandbücher schreiben, den manuellen Testplan einmal ausführen, den Legacy Code mit Tests versehen oder endlich mal gemeinsam Code-Teile refactorn. Dies sind Aufgaben, die die Entwickler gerne an die QA, technischen Redakteure oder studentische Hilfskräfte weitergeben. Fakt ist aber meistens, dass Entwickler diese Aufgaben viel besser erledigen können, als andere Kollegen. Wir erledigen solche Aufgaben in Mini-Sprints.

Was sind Mini-Sprints?

Mini-Sprints sind ein bis zwei Tage, in denen das Team sich einer Aufgabe widmet, die sonst gerne aufgeschoben wird. Das Team trifft sich also einen Tag und arbeitet gemeinsam an einer größeren Aufgabe. Mini-Sprints werden entweder von dem Team selbst organisiert oder von an einer anderen Abteilung, die Unterstützung und die Expertise der Entwickler benötigen. Wenn also das Team gerne mal einen Tag damit verbringen möchte, den Code an einer bestimmten Stelle mit Unit Tests zu versehen, bereiten ein, zwei Entwickler diesen Mini-Sprint vor. Diese Entwickler stellen am Morgen den Mini-Sprint vor, erklären was aus Ihrer Sicht zu tun ist und das Team plant gemeinsam den Tag.

Tipps:

  • Ungestörtes Arbeiten: Es dürfen also keine Teammitglieder an Meetings teilnehmen oder alltägliche Supportanfragen annehmen.
  • DenTag besonders machen: Gemeinsam mittags Pizza essen, eventuell nicht im Büro arbeiten, sondern zusammen in ein Meetingraum coden und/oder den Abend mit einem Bier ausklingen lassen. So ein Mini-Sprint soll etwas besonderes sein.

Bei Atlassian machen wir auch Mini-Sprints, die von anderen Teams für die Entwicklung organisiert werden:

Benutzerdokumentation auffrischen

Unsere technischen Redakteure sind verantwortlich für die Auslieferung der Dokumentation. Die Dokumentation soll einheitlich aussehen und formuliert sein. Wenn es aber um Dokumentation zur Benutzung unserer Schnittstellen  geht, kennen sich die Entwickler natürlich inhaltlich viel besser aus. Es wird also ein Mini-Sprint zum Erstellen eines User Guides der API organisiert. Die technische Redaktion organisiert alles um diesen Tag herum. Die Entwickler kerstellen die Doku, die technischen Redakteure überarbeiten diese später und wir haben eine korrekte Beschreibung, wie man unsere Schnittstellen benutzt.

Gemeinsam Testen

Es gibt wenig Entwickler, die manuelles Testen der gesamten App mögen. Dafür haben wir ja zum Glück die QA… Aber wir wissen ja eigentlich, dass die QA nicht für die Qualität unserer Software verantwortlich ist. Softwareentwickler kennen Funktionalität viel besser und haben ein ziemlich gutes Gefühl, wo etwas schief gehen könnte in der Software. Bei Atlassian gibt es wenige QA Mitarbeiter. Bei uns gibt es sogenannte DOTs (Developer on Tests). Die Entwickler sind also mit fürs Testen verantwortlich. Um jetzt aber vor einem Release die gesamte Software einmal manuell durchzutesten, führen wir sogenannte Blitz Tests durch. Das gesamte Team oder sogar Mitarbeiter aus anderen Teilen des Unternehmens nehmen an diesem Mini-Sprint teil. Auch hier übernimmt unsere QA die Organisation und die Nachbereitung dieses Mini-Sprints.

Aber… das muss doch in die Sprintplanung

Es gibt immer Aufgaben, die aufgeschoben werden, wie den Code aufräumen, auf eine neue Java Version wechseln oder Performance Tests schreiben. Die diese Aufgaben nicht gut in die Sprintplanung passen, kann man regelmäßig Mini-Sprints durchführen. Ich weiß, viele meinen das dies zur Iteration dazugehören sollte. Ich habe aber viel zu oft gesehen, dass solche Aufgaben gerne verschoben werden, auch wenn Sie wichtig sind. Warum also nicht alle 2-3 Wochen solche Aufgaben in einem Mini-Sprint erledigen?

Tripple Win

Win 1: Eine unliebsame Aufgabe wurde erledigt. Geteiltes Leid ist halbes Leid. Es kommt aber auch ziemlich oft vor, dass diese Aufgabe gar nicht so nervig ist, wenn man erst mal mit ihr beginnt. Manchmal sehen Dinge einfach aus näherer Distanz nicht mehr so Schlimm aus.

Win2: Man hat am Ende das Gefühl, etwas gemeinsam geschafft zu haben. Auch kommt man aus der täglichen Sprint-Routine mal raus, macht was besonderes, die Arbeit wird nicht eintönig und ein Mini-Sprint erweitert den Horizont.

Win3: Wir entlasten andere Abteilungen. Ich fand es schon immer unfair, wenn die technische Dokumentationsabteilung als Flaschenhals für ein Release angesehen wurde, man diese aber kaum unterstützt hat. Man bekommt eine gemeinsame Verantwortung für das gesamte Produkt… Ja die Dokumetation ist wirklich ein Teil des Produkts.

Follow

Get every new post delivered to your Inbox.

Join 28 other followers