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

Advertisements

Effective Feedback – Make it an Experience

Can you remember the last time you ran into a problem or saw a bug in the software and actually filled out the feedback form? Have you done it more than once? The last blog post was about removing barriers, letting people easily submit feedback. This post is about how to encourage people to finish the feedback in a way that your users wants to do it again.

How to demotivate for feedback

I found an example how to demotivate people to give feedback again and I’m not surprised that it is Microsoft. I just wanted to see how different vendors encourage people to submit feedback and the first application I picked was Word. It was very easy to find the feedback option in the menu. I pressed the button and was directed on a webpage. Well that is still OK, but I left Word for that… so it’s not good in terms of context switching. The feedback form is very simple: Select product and version (even though this could be done automatically) and write feedback. But it is so demotivating for the user that he has to tick the box “I know that I will not be contacted by Microsoft in response to my feedback”. Now the user asks themselves what happens with the feedback? Will somebody from Microsoft have a look at it at all? Why is it so hard to reply to the user with a follow up ticket number or a short comment that there’s somebody looking into the feedback? There will be not many users submitting feedback more than once, if they never hear anything, that Microsoft received it or even will do something about it.

What you want

You actually want people to submit feedback. It is the best way to get an idea, what you’re users are doing with your software and what they are missing. You do want them to come back and submit feedback a second and a third time. So you should make it an experience and help the users wherever you can. Make it fun, so users come back and love to go through the feedback process.

Good user experience

Wikipedia encourages users to rate pages. You can very easily rate how trustworthy, objective or well written a page is. You just need to decide how many stars you want to give each criteria. That’s it. The same applies to rating applications in the App-Store and books at Amazon. Let people rate the usability of your software and other things, that you would like to have feedback for. Don’t get in the way of the user and put annoying pop up windows on top of the application. Make it a side task.

Great user experience

The real fun comes with Google feedback. If you want to provide feedback to Google, you have to enter a sentence, then you can add a screenshot and highlight or blackout data. This way users don’t have to explain too much. It’s fast to give feedback if you just say: “I want to be able to add pictures to my comments”, highlight the comment area and press submit. Google is adding data automatically like OS, browser version, installed plugins,etc. That way it is fun to submit feedback and I definitely want to do it again.

At Atlassian we use Bonfire for getting fast feedback with a great user experience. Bonfire comes with a browser plugin that needs to be installed. That way you get a lot of possibilities to annotate the screenshot with circles, text and blur effects. Bonfire was developed by our QA to help and encourage internal users to submit issues when actually working with the tool. No context switching and you get addicted by the cool annotation features.

The same surprising effect has JIRA Mobile Connect. It’s actually similar to Bonfire, but runs on an IOS device. The best thing with this tool is, that your developers can write messages directly to the user who gave feedback. This way the user knows, that somebody cares about his problems.. not like Microsoft.

Make it fun

If you want to have lots of feedback for a new product, make a funny competition. Ask people to give feedback and let a jury or the community vote for the 10 best improvement advices. Give away some t-shirts. Let people send feedback via twitter and give a free license each day. Use your own imagination.

 The feedback experience

Care about the experience during the feedback process. Make the user feel good and get in contact with your user when they submit feedback. Even if it’s just a ticket number to follow up. If the user has fun giving feedback he will come back. You should care about your feedback experience if you seriously want to improve your software.

Effective Feedback – Blog Series

This is part 3 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 4: Effective Feedback: Involve Developers

Effective Feedback – Fake it before you make it

Building great user interfaces can take some time. You want to be sure that your first released version points in the right direction. How can you get feedback from your customers before you deliver a real product or a working prototype? What is the best way to try things out and be able to throw them in the garbage can afterwards? People tend to have problems throwing things away if they have already invested some time and this is exactly the reason why you should try out your ideas in an easy and cheap way.

Stage 1: Paper Prototypes

Probably the cheapest way to test the usability of an idea is to create paper prototypes. You don’t need a lot of things do produce your design:  some sheets of paper, a scissor  a pen, some glue and imagination! At Atlassian we’re using this technique to try things out. We’re doing one or two day design sessions when we’re trying to create the interface for a new feature or change the usability of an existing one. Our designers are sketching the interfaces on paper and trying them out by using there fingers to virtual click on drawn buttons or drop down menus. Take a look at this video to find out how a paper prototype works.

Your sessions are getting even better when you involve customers at a later state. If come up with 5 alternatives you should do some sessions with existing customers to receive feedback.

 Stage 2: Sketching Tools

Paper prototypes are good to collaborate if you’re in the same room. It tells you something about the interaction with the new feature. But what if your team is distributed? Tools are made for this. You can send your design by email or work together in an application on a prototype. If you want to ask a broader audience it is also way easier using tools to show your ideas remotely and collect feedback.

I would use a tool when I have three to five favorites to ask more stakeholder for feedback. There are pretty good sketching applications out there. My favorite is balsamic mock ups. It looks like you’re just sketching the feature. You’re not designing a polished interface, it just looks like a sketch. That way people are not expecting that this will be the final design and concentrate much more on the big things than on the details. You can also do interactions like drop down boxes and define actions when clicking on buttons. Use a VNC app or the Skype / Google HangOut desktop sharing feature to look at the screen of your stakeholder. Record the session to discuss the results with the rest of the team.

 Stage 3: Nice looking empty software

That way you should be able to have two favorites. Now you can make them nice. With some HTML / CSS knowledge it’s not that complicated to create a nice looking interface. Mock some functionality just to show how the final design would feel and look. At Atlassian we have created our design elements like menus, fields and buttons with Keynote (Apples Power Point). That way everybody can make a nice looking screen to try the final designs. It is a little bit harder to show interactions but also keynote has some nice animations. Don’t use them too intensive, it will give your programmers a hard time when they should make the real app 😉

Faking before making!

So fake it before you make it. That way you’re not so connected to designs that will be thrown away again. Ask as many different stakeholders for feedback as you can get. But be careful just with all the feedback you get: If you’re doing something totally new and revolutionary, most existing customers and some managers will be afraid of the change. Sometimes you need to risk things to get better.

Effective Feedback – Blog Series

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

Part 1: Effective Feedback: No barriers 

Part 3: Effective Feedback: Make it an Experience

Part 4: Effective Feedback: Involve Developers

Effective Feedback – No barriers

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?

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

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.

Was können Softwareteams von Fußballteams lernen? Das Spiel

Das Spiel dauert 90 Minuten und für professionelle Teams findet es mindestens einmal die Woche statt. Softwareteams dagegen machen keine Pause ein Sprint dauert typischerweise zwischen einer und vier Wochen. Trotzdem können wir Entwickler noch einiges über Agilität von den Fußballern lernen. Im Fußball sind die Feedback-Zyklen viel kürzer, aber dazu später. Fangen wir mit dem Ursprung des Fußballs an, der in England stattfand:

1. Kein Kick and Rush

Früher wurde in England “Kick and Rush” gespielt, also schießen und stürmen. Das war die Taktik. Damit kommt man heute im Fußball nicht mehr durch. In der Softwareentwicklung sollten wir ja nicht ungefragt nur den Anforderungen der Person hinterherlaufen, die am lautesten schreien kann. Dadurch geraten ältere Backlog-Aufgaben, Fehler, Anforderungen von anderen Personen und eigene Produktvisionen aus dem Blick. Das Team sollte gemeinsam alle Aufgaben im Blick haben und gemeinsam mit allen Stakeholdern die Wichtigkeit einzelner Aufgaben erkennen und die eigenen Ideen nicht vergessen. Ein Komitee hilft dabei.

2. Taktik während des Spiels anpassen

Fußballer haben keine Probleme ihre Taktik während eines Spiels anzupassen. Der Trainer entschiedet, dass es in der aktuellen Spielphase besser ist, den Sturm zu stärken, also spielt man einfach offensiver. Nur so kann man ein Spiel gewinnen: Measure, Learn, Adapt. Auch im Softwareprojekt sollten wir schnell reagieren können. Wenn unser neues Feature nicht vom Kunden angenommen wird, sollten wir es verändern, schauen ob es damit besser geht und weiter verbessern. Es gibt aber immer noch genug Menschen in der Softwarebranche, die glauben, dass man durch eine lange Analysephase genau weiß, was man entwickeln soll. Das klappt weder in der Softwareentwicklung noch im Fußball. Zugegeben: Beim Fußball ist das Feedback viel schneller und direkter (Wenn wir beispielsweise den Sturm stärken, erkennen wir eventuell schnell Schwächen in unserer Abwehr). Wir sollten also Mechanismen in unser SOftware oder unsere Entwicklung einbauen, um schneller Feedback zu erhalten. Ich werde dazu in den nächsten Wochen hoffentlich noch mehr schreiben. Der JIRA Issue Collector oder JIRA Mobile Connect sind aber gute Beispiele dafür, wie man auf einfache Weise schnell Feedback einsammeln und in die Entwicklung rückkopplung kann.

3. Neue Ideen in Freundschaftsspielen testen

Will ein Trainer eine Taktik ausprobieren, wird diese im Freundschaftsspiel getestet. Auch wenn es hierfür keine Punkte in der Bundesligatabelle gibt, sind diese Spiele doch sehr wertvoll. Ob die Änderungen im späteren Punktspiel verwendet wird, ist dabei nicht wichtig. Auch die Erkenntnis das etwas nicht funktioniert, hilft dem Trainer und der Mannschaft. Warum gönnen wir den Softwareentwicklern keine oder wenig Zeit neue Sachen auszuprobieren? Es gibt wenige Unternehmen, die Ihren Mitarbeitern Zeit geben, neue Ideen in Prototypen umzusetzen. Xing führt beispielsweise unternehmensweite Prototype Tage durch, Atlassian macht jedes Quartal ein Ship-It Tag. Ohne Innovationen können wir nur auf das reagieren was andere machen.

4. Die Besprechung nach dem Spiel

Beim Fußball gehört die Spielanalyse zu jedem Spiel dazu. Am nächsten Tag wird das Match gemeinsam mit allen Spielern noch einmal analysiert: Was ist gut gelaufen, was können wir im nächsten Spiel verbessern? Nur so steigert man sich als Team! Ich habe das Gefühl, dass Retrospektiven oder Kaizen immer noch nicht regelmäßig und ernsthaft in Teams durchgeführt werden. Warum gehört es nicht am Sprintende dazu, noch einmal darüber zu sprechen, was gut gelaufen ist und was man im Ablauf besser machen kann? Hier können wir sehr viel von Fußballteams lernen!

5. Feier den Sieg

Hat man den Klassenerhalt geschafft, die Champions League Qualifikation erreicht oder vielleicht auch die Meisterschaft gewonnen, wird gefeiert. Es ist Zeit, sich selbst und das Team für die harte Arbeit zu belohnen. Wenn eine Softwareversion oder ein größeres Feature released oder deployed wurde, sollten wir auch eine kleine Feier organisieren. Mal locker als Team zusammensitzen und auf den Erfolg blicken. Wir machen das viel zu wenig. Nach einem erfolgreichen Release schauen wir viel zu schnell auf das nächste, anstatt mal kurz anzuhalten und den Moment zu genießen.

Lust auf noch mehr Parallelen zwischen Fußballspielern und Softwareteams? Hier ist mein Team-Vergleich-Post.

Was können Softwareteams von Fußballteams lernen? Das Team

Seit der EM im Juni, habe ich über Fußballteams nachgedacht und einige parallelen zur agilen Softwareentwicklung entdeckt. Es gibt einiges, was im Fußball gang und gebe ist, wir aber in der Softwareentwicklung noch nicht alle begriffen haben. Die ersten 5 Punkte behandeln das Team. In einem folgenden Blogpost geht es denn um die Taktik vor und während eines Spiels:

1. Spezialisierung auf Sturm macht Sinn, ist aber kein Zwang

Wenn ein Abwehrspieler alleine mit dem Ball vorm Tor steht, sollte er schießen!  Ja es gibt Spezialisten dafür (die Stürmer). Was aber, wenn der gerade nicht da ist? Im Fußball ist die Entscheidung klar: Schießen! Wie sieht’s in der Softwareentwicklung aus? Sollten wir nicht auch der QA helfen, wenn Not am Mann ist? Natürlich! Auch wenn jemand sich hauptsächlich um das Design kümmert, nützt es doch nichts, wenn die Software aufgrund eines Aufgabenstaus bei den Testern nicht released werden kann. Wir müssen dabei genau wie auch beim Fußball nicht gleich alle Generalisten werden. Das Fußballteam will gewinnen und wir wollen gute Software ausliefern.

2. Der Torwart ist ein Spezialist

Genau das widerspricht sich mit Punkt 1, erinnert mich dennoch an die QA-Rolle bei Atlassian. Der Torwart organisiert die Abwehr. Er ist eigentlich der spielende Coach für die Abwehrspieler. Er greift als letzter Mann ein, wenn seine Abwehr den Ball nicht unter Kontrolle bekommt. Er ist also der letzte Mann, der uns vor der Niederlage bewahren kann. Bei Atlassian sind es auch nicht die QA Mitarbeiter, die ausschließlich testen. Sie koordinieren und helfen den Entwickler, die dann letztendlich die Tests durchführen. Wenn es aber ein wenig schwieriger wird, oder bei Ressourcenmangel, springen die QA-Mitarbeiter ein, und führen die Tests selbst durch. Genau wie beim Torwart, der auch nur in den brenzlichen Situationen eingreifen muss.

3. Das Team hat das gleiche Ziel

Gute Teams wissen, wo Sie hinwollen. Im Fußball kann man die Teamleistung gnadenlos sehen. Anhand der Tabelle. Schwarz auf Weiß. Das Feedback, ob ein Spiel gut war oder nicht, bekommt man sofort nach dem Spiel. Das hilft, das Fußballteam auf das Ziel Klassenerhalt, Meisterschaft, Champions-League oder was auch immer, einzuschwören. Alle müssen ihren Teil dazu beitragen, das Ziel zu erreichen. In der Softwareentwicklung sind die Ziele meist nicht so klar und eindeutig auszumachen. Jeder Entwickler sollte die Vision eines Produktes kennen. Jeder sollte sofort wissen, wie nah man der Vision schon gekommen ist und welche Featureideen uns eher von der Vison abbringen. Ändert sich das Ziel, muss das Team dies wissen. Alle User Stories, die in der Sprintplanung besprochen werden, sollten auf das Erreichen der Vision ausgerichtet sein.

4. Der Trainer ist für die Vision verantwortlich

Das Fußballteam konzentriert sich auf das nächste Spiel. Es kennt zwar die Vision des Vereins und hilft dabei dies zu erreichen, allerdings richtet der Trainer die Taktik der Mannschaft aus: Er schont Spieler vor einem schweren Spiel oder trainiert Standards, da das nächste gegnerische Team damit Probleme hat. Auch in agilen Teams sollten die Entwickler das Ziel kennen, es ist aber meist der Produktmanager oder Product Owner, der den Überblick behält. Sie legen fest, was für den nächsten Sprint geplant wird. Somit können sich die Entwickler auf die Fertigstellung der Aufgaben und wie sie diese umsetzen wollen, konzentrieren.

5. Für jede Position, sollte es einen Ersatzspieler geben

Der Trainer macht die Mannschaftsaufstellung. Für jede Position setzt er einen Ersatzspieler auf die Bank. Wenn während des Spiels der Stürmer verletzungsbedingt ausfällt, kann er den Ersatzstürmer von der Bank einwechseln. Auch bei der Softwareentwicklung ist es immer gut nicht nur einen Datenbankspezialisten im Team zu haben.  Verlässt dieser das Unternehmen oder ist aufgrund von Krankheit oder Urlaub nicht da, hat man ja noch Ersatz. Auch wie bem Fußball ist es immer schwierig Starentwickler zu ersetzen, aber letztendlich geht es um das Team.

Anforderungen, Epics & User Stories festhalten – The Atlassian Way

Ich werde oft (meist von größeren Firmen) angesprochen, wie wir uns denn das Aufschreiben von Anforderungen mit JIRA vorstellen und wie wir das bei Atlassian handhaben. Jetzt  ist es so, dass bei uns die verschiedenen Teams auch verschiedene Vorgehensweisen haben, deshalb kann es sein, dass man auf bei Atlassian auf Teams trifft, die eine andere Vorgehensweise bevorzugt… und das ist völlig in Ordnung (Agiles Manifesto: Individuen und Interaktionen über Prozesse und Werkzeuge)

User Story Doku – so machen wir es

Wir schreiben meistens nur einen Einzeiler als User Story auf (Als (A) möchte ich (B) machen, so dass (C)…). Dann erzeugen wir damit einfach einen Issue in GreenHopper/JIRA  und bauen darauf auf. Wir vermeiden es, Spezifikationen zu schreiben. Wenn man das Problem in kleine Häppchen zerteilt und Einzelheiten dokumentiert, fällt meistens auf, dass man ziemlich offensichtliche Sachen dokumentiert, die entweder für jeden im Team klar sind oder die viel einfacher durch ein Mockup beschrieben werden können.

Aber gerade wenn man mit einem größerem, nicht mehr ganz frischen Softwareprojekt zu tun hat, muss man mehr Sachen berücksichtigen, als in einer Zeile in einer User Story steht. Also packen wir mehrere User Stories in eine Wiki-Seite und diskutieren diese.

Hier sind die Vorteile, die wir mit diesen Ansatz sehen:

1. Eine Seite, eine Quelle, ein Problem

Keep it simple! Normalerweise haben wir eine Seite mit dem Epic. In dieser Seite werden alle User Stories zu diesem Epic aufgeführt. Alles auf einer Seite zu haben, hilft dem Auffinden von Informationen ungemein.

Zusätzlich pflegen wir noch eine “Machen wir nicht”-Liste auf dieser Seite. Dies ist extrem wichtig, damit alle den Umfang des Epics verstehen. Dadurch versuchen wir zu vermeiden, dass falsche Erwartungen geweckt werden und es hilft dem Team beim Fokussieren und dem Management besser zu verstehen, was gemacht wird und was nicht!

2. Flexible Struktur

Der Vorteil von einem Wiki gegenüber einem Tool zum Anforderungsmanagement, ist die Agilität in der Dokumentation. Man muss nicht immer alles machen, was ein Tool einem vorschreibt. Mach, was du auch wirklich nur benötigst und sei agil!

3. In Details eintauchen

Verlinken ist eine Basisfunktion eines Wikis. Wir benutzen es häufig. Man könnte beispielsweise zu folgenden Details verlinken:

  • Kunden Interviews, um den Kontext darzustellen
  • Seiten und Blogposts von ähnlichen Ideen
  • vorausgegangene Diskussionen oder technische Dokumente
  • Links auf externe Informationen

Damit kann man ein einfaches Dokument erstellen und der Benutzer kann in die Tiefe der Informationen eintauschen.

4. Lebendige Dokumentation = Lebendige Stories

Auch unsere Kunden nutzen dieses Feature häufig: Ist erst mal das Gerüst für ein Story fertig, wird oft die JIRA Integration von Confluence genutzt: Aus der Seite heraus werden GreenHopper Stories erzeugt. Diese werden dann automatisch in Confluence angezeigt und man kann den Fortschritt von hier aus beobachten. Wenn also die Entwickler die Storie fertig haben, kann man das direkt con der Wiki Seite aus sehen.

5. Die Weisheit der Masse

Gerade in größeren Unternehmen erreicht man mit einer Dokumentation in einem Wiki, dass Mitarbeiter aus anderen Abteilungen an Diskussionen teilhaben und ihre Ideen teilen können. Es ist immer wieder faszinierend zu sehen, dass Kollegen aus anderen Teams tolles Feedback geben und Anregungen einbringen, an die man noch gar nicht gedacht hat.

6. Zusammenarbeit!

Der wahrscheinlich wichtigste Aspekt an dieser Vorgangsweise ist der, dass alle involviert sind. Schreibe niemals eine Spezifikation allein. Teile deine Ideen mit dem Team und sammle das Feedback. Kommentiere, stell Fragen, involvier andere in die Diskussion. Besonders wichtig ist dies für verteilte Teams!

7. Gestalte deine Stories ansprechend

Benutze Tools wie Gliffy oder Balsamiq, um besser Probleme darzustellen oder füge Bilder, Videos oder anderen interaktive Inhalte hinzu. Tu was immer notwendig ist, um das Problem klarer mit deinen Team zu kommunizieren.

Herausforderungen – das haben wir gelernt

Und jetzt einige Herausforderungen, die wir mit dieser Vorgehensweise haben:

1. Dokumentation hat die Tendenz veraltet zu sein

Was passiert, wenn du Feddback für ein Feature bekommst und du es daraufhin änderst. Passt du die Dokumentation an? Das ist ein große Herausforderung mit jeder Art von Dokumentation.

2. Eine offene Diskussionskultur

“Wie schaffe ich es, dass Leute meine Seite kommentieren?”, “Wie motiviere ich Mitarbeiter, mehr Spezifikationen und Stories im Wiki festzuhalten?”. Dies kann wirklich schwierig sein. Wir haben eine Seite mit Tipps, die vielleicht helfen können, eine bessere Akzeptanz für das Wiki zu generieren.

3. Fang an

Auch wenn wir dazu raten, dass jeder sein eigenes Format wählen sollte, brauchen einige Leute doch manchmal ein Richtlinie oder ein Template. Also fang an und schreib eine Anleitung oder auch schon das erste Beispiel-Epic ins Wiki und versuch deine Kollegen bei der Erstellung zu beteiligen.

Vielen Dank an Sherif Mansour für die vielen internen Infos.

Video: Arbeitszeit für eigene Projekte

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: