JIRA is a well-known issue tracking software developed and maintained by a company called Atlassian, that has a rich product portfolio in the field of software development, tracking and collaboration. Next to JIRA, Atlassian is also famous for its wiki software called Confluence. The following sections will focus on JIRA, especially on a plugin for JIRA called GreenHopper.

Functionality

JIRA is an issue tracking software tool and that is its greatest power. It has countless features and it can be stated without hesitation, that JIRA might be THE issue tracking software tool currently available on the market. While issue tracking is certainly a must have, one aspect that makes JIRA interesting especially for Scrum and Kanban teams is its plugin architecture. Currently, 400+ plugins are available. The one that catches our attention (and the most popular plugin right now) is called GreenHopper, that adds an Agile layer on top of the JIRA architecture. With GreenHopper, Scrum and Kanban teams can migrate their product backlog, their taskboard, their burndown charts and other Scrum artifacts to JIRA and create their electronic counterparts. Until recently, the functionality of GreenHopper was comparable to that of many other Scrum tools.

Since version 5.8, GreenHopper goes beyond that by introducing what they call a rapid board. A rapid board is a new approach to guide Scrum and Kanban teams through their corresponding processes. Therefore, two standard presets are available and a third one, which is called DIY where teams can alter processes in a manner that suit them best. In my case, I have chosen the Scrum preset. Before you can start creating your backlog, you have to link your new rapid board to an existing JIRA project – not very intuitive but understandable since JIRA itself is not Agile. After having done so, GreenHopper will present you an empty product backlog (what they call the plan mode), that wants to get filled with user stories. Lets fire up our keyboard and add some stories! By the way, GreenHopper offers you a choice out of five types (blocker, critical, major, minor, trivial) which you can assign to your stories / tasks. I will explain later on why that might be handy.

Did you enter enough stories to keep your team busy for the next sprint? Great, call them in, because right now, the stories needs to get estimated by clicking on each story and filling in the story points. As soon as all story points are entered, the team can choose an amount of stories to commit by simply dragging a sprint marker until they think it is enough. The sprint marker will then automatically show the total amount of committed story points and we can start the sprint by just clicking on the “Start Sprint” button; GreenHopper will automatically redirect us to our well-loved taskboard.

The work view (the taskboard) gives us a basic taskboard design, featuring the obligatory set of „To Do – In Progress – Done“ columns. Interestingly, the stories dont get an own column. Instead, they are placed in the „To Do“ column, with their corresponding tasks just beneath them. Wait – did I say tasks before we actually created them? Yep, and the reason for this is linked to a positive and at the same time negative aspect of JIRA: its flexibility. JIRA is highly flexible, you can alter it in each possible way that suits you best. But that flexibility comes at a cost: the interface is often not very intuitive – I will cover that aspect in one of the following sections. Back to creating a task: We have to click on the generated ID of JIRA (EVAPRO-8 if you look at my provided screenshot), followed by a click on „More Actions“ and then you are finally able to choose „Create Sub-Task“. After finding that somewhat hidden button, the process of creating tasks is much better, mainly due to the ability to leave the create task window open – very time saving when entering multiple tasks. Even more time saving is the ability to perform nearly all the commands by using keyboard shortcuts – your team will love it!

Yet another powerful feature of JIRA is its very own (SQL like) querying language called JQL, with which you are able to perform any search request you can think of. But there is more than just that – team members can customize their dashboard by using JQL so that they see what they want to see. Your team will love you even more!

Back to the columns of the taskboard. You might already have guessed it; it is also flexible and can be altered according to your needs, e.g. by adding a committed column which means that the PO can test the functionality and move the story/task to complete when it satisfies him or her.

JIRA can be used for multi project setups. In fact, you can use multiple projects as input for one rapid board. Interestingly, JIRA does not offer any more hierarchies beyond epic level (and it is rumored that even epics are just relabeled tasks). A plugin called „structure“ helps to create infinite levels of hierarchies, but it is third party and not perfectly embedded within JIRA and GreenHopper.

Still, JIRA is a feature monster: interfaces to other tools? Check. Archival / export functionality? Check. User access control? Check. Event-based notification? Check. Time registration? Check. Support for adding bug stories/tasks? Check. Assign tasks to people? Check. Undo functionality? Uncheck – no undo available, due to use of AJAX (see below).

Usability

When it comes to using JIRA with GreenHopper, the overall impression is twofold. On the one hand using JIRA without a mouse introduces a massive speed up of daily actions the team has to perform. On the other hand you get the feeling that GreenHopper, especially the rapid boards, did not leave beta status yet (which is clearly indicated by Atlassian. Rapid Boards are only available if you enable the „GreenHopper Labs“). Still, I would currently recommend enabling rapid boards, as they make the whole Scrum process more enjoyable.

Atlassian should also try to be more consistent when it comes to naming functionality. When you start the normal planning board, GreenHopper will present you a „New Card“ button. For me as a user it is immediately clear that I can add new user stories by clicking on that button, as user stories are normally written on cards. When using a rapid board, this button is not available anymore. Instead, a much smaller and more hidden „Create issue“ link is presented. Even more confusing, in planning mode the „New Card“ *and* the „Create Issue“ links are available, both offering a completely different interface experience. Where „New Card“ is the much simpler, Scrum-related one, „Create issue“ is the JIRA standard interface, that is much more complex. In the end, it does not matter which interface I use to add a new story – but it is confusing.

Briefly touched in the previous section, it is also not very intuitive that one has to create a JIRA project before using GreenHopper. The same is true for adding a task to a story, which requires way too many clicks. Of course, you can change that interface to make the „Create Sub-Task“ link more visible, but that involves lots of unnecessary work for a feature that should be available by default.

Performance

Performance-wise there is not much to say, JIRA performs quite well. Ok, to be more elaborate: JIRA works much smoother than other tools if the bandwidth available is low. In fact, I have tested JIRA and GreenHopper by setting up my smartphone as a hotspot and the experience is great. One of the reasons for that experience is, that especially GreenHopper (JIRA itself much less) make extensive use of AJAX functionality (where AJAX simplified means that the browser does not have to refresh the whole page when changing an option or clicking a button). As testing platform I have used Atlassians very own cloud service, and I never experienced any downtime nor hiccup. Does this mean that the cloud can be classified as highly-available? Of course not, but exploring that is outside the scope of this article.

Resources

GreenHopper does not require a client software to be installed on each of the team‘s machines since it runs within a web browser, which is standard nowadays. Atlassian claims that JIRA and GreenHopper work on each browser as long as you browser version is high enough. From my point of view, those versions are not cutting edge, so chances are high that it works within your company’s IT landscape. Screen wise, XGA resolution is required (1024 x 768 pixels) – any moderately modern screen should fulfill that. However, there is one barrier that might come at a cost. The current GreenHopper Version (5.9.X) requires atleast JIRA version 5.X – a JIRA version most of the companies will not have running right now. Although GreenHopper (til 5.8.X) does work with JIRA 4.4.X, the much praised rapid Boards were introduced in this very version – chances are high that those boards might be buggy when using GreenHopper 5.8.X.

Interface

Some aspects were already mentioned, nevertheless the interface is much better as one might expect after reading the usability section. First of all, the rapid entry of new stories and task is a big plus, thanks to the large amount of keyboard shortcuts and the possibility to leave the „New Task/Story“ window open after adding a task or a story. Another great aspect is the highly flexible and sophisticated user dashboard. Each team member can change the content he or she wants to see on his dashboard by arranging the available components or by adding a new component, using JQL.

One of these available components is the so-called Activity stream which offers a similar experience as Facebook‘s News-Feed. New Stories/Tasks but also changed states of issues are displayed, each of those items offer the possibility to leave a comment or to add it to the users watch list if he or she wants to track any upcoming changes. Next to its dashboard, the user can also configure the taskboard in such a way as it pleases him or her. For example, he or she can choose to show only recently updated tasks, tasks of high importance or self-assigned tasks. By doing so, GreenHopper allows the user to create an interface that suits his or her needs.

Again, the possibilities of GreenHopper do not stop here. A fullscreen mode is also supported, the same is true for high contrast figures (using the wallboard plugin). Drag & drop is of course also available for moving tasks or stories and last but not least, the website is designed in such a minimal way that its layout does not waste space horizontally or vertically. Although the design looks simple, it is created in a way that enables the use all that flexibility JIRA and its plugins provides.

Motivation

Motivation is and was always the trump card of paper-based taskboards. Only they were able to provide a certain haptic feeling. A feeling, software is not able to give. Unsurprisingly, this is also true for JIRA with GreenHopper. However, Atlassian comes quite close by offering numerous high contrast figures, using the aforementioned wallboard plugin. Recently, a Minecraft Plugin has emerged which offers gamers an innovative new way of solving JIRA issues.

Costs

JIRA and GreenHopper are available as download for installing it on your company‘s dedicated hardware and as on-demand, which basically means that Atlassian hosts JIRA including GreenHopper for you on their server farm. Which option you choose is of course up to you, although most of the companies will favor the first option due to security policies. The minimum fee is 10$ – either as a one time purchase when you want to deploy it on your own server (10 users, the money will be donated to charity(!)) or 10$ a month, if you want to run it on-demand (again 10 users). According to Forrester, JIRA is by far the cheapest option of the Top 10 vendors of Agile Software – twice as cheap than the second cheapest vendor and just 18 times cheaper than the most expensive vendor. That is quite a number. And if one compares the offered functionality with other vendors it becomes clear why JIRA rightfully claims being a rising star.

Advantages

1. Flexibility
2. Costs
3. Own query language

Disadvantages

1. Inconsistency
2. Beta-feeling of rapid boards
3. Flexibility

The curtain falls

This was the first article that evaluates JIRA’s abilities to represent a taskboard. Next time I will evaluate  ThoughtWorks Studios Mingle.

References

West, D., Hammond, J.S., The Forrester Wave: Agile Development Management Tools, Q2 2010, Forrester Research Inc.

Let’s imagine in the situation above the organization is distributed across different locations and the teams each develop software based on a shared data base but with different purpose. Due to some performance issues, Team 1 needs to change the DB schema for some of the data. They communicate this to their PO who in turn lets the PO team know about the need to change the schema. One of the POs realizes the impact it will probably have on his team and informs them about.  This is the red path in the picture above.

However, such communication paths are not a good idea if they become too long. Too much noise on the way will distort the message and even if the message arrives intact, it will arrive with a delay.

To remedy this, shortcuts must be introduced to get more direct communication going.

In other words, the teams should talk directly to one another. But simply drawing such a shortcut in an organizational chart is not going to make the communication happen. Since the teams in our example have little common ground save for the underlying data base, which has been stable for long, they do not know much about each other. Team 1 does not know which team will be impacted by their changes.

It is necessary to identify what the content of the communication is that needs to take place in a more direct form. Does it happen frequently that such messages have to take a long way to reach the proper recipient?  In our example the question would be, how often the organization has data base issues that need to be coordinated across teams.

In many cases the people involved notice the need for more direct communication and self-organize into virtual teams with the same special interest.  In other cases it needs a good leader to identify the missing communication link and help the members of the organization to establish such special interest groups.  The very appropriate nom-du-jour for these groups is communities of practice. Maybe a community of practice (CoP) for DB administration would be appropriate in the example. Such a CoP should have a member from each team that uses the data base in question. They organize themselves, meet on demand or regularly, face-to-face or virtually, set standards pertaining to their topic, make decisions about changes, etc. They communicate directly and do not have to rely on messaging through other persons, particularly not their line managers…

And yet again – there are no managers in the organizational chart. Do we need them at all?  If so, where do they fit into the picture? Watch this space for answers to this and other world shattering questions.

 

Christof Braun, Trainer Management 3.0 & Management Consultant

Related posts:

1. Software Architecture is a Social Activity! Conways Law
2. ScrumMaster and Domainleads – our solution for large organizations
3. 5 min on Scrum | How to do Scrum Scaling with international teams?

In vielen Unternehmen reißen Projekt-Deadlines und es muss nachgearbeitet werden. Eigentlich ist es eher die Regel, dass die geplanten Zeiten nicht eingehalten werden. So weit nicht schlimm. Denn wir sind Menschen und können nicht in die Zukunft gucken. Das gilt auch für den Bau des Willy Brandt-Flughafens. Ein Projekt in dieser Größenordnung ist nur schwer zu greifen – irgendwas vergisst man immer …  Um auf Veränderungen schnell reagieren zu können und Gefahren wie eine Nicht-Fertigstellung möglichst früh erkennen zu können, machen wir Scrum. Iterative und überschaubare Zeiten, in denen man genauer planen kann. Ich möchte mich nicht zu weit aus dem Fenster hängen  und sagen: Berlin hätte sein Bauvorhaben mit Scrum machen sollen. Aber ist doch eine spannende Fantasie … erste Ansätze waren mit dem Passagier-Testbetrieb auch schon da.

Offen kommunizieren!

Ich möchte an unsere Offenheit appellieren. In Scrum bemühen wir uns, offen zu kommunizieren.
Wenn es länger dauert, können wir (je länger das Projekt läuft, desto genauer) bestimmen, wann wir fertig sind. Dass das in der Realität oft schwierig ist, will ich nicht verleugnen. Das Team in Berlin, das den Flughafenbau steuert und den Termin nicht geschafft hat: Verständlich, dass es erst drei Wochen vor Start mit der unangenehmen Wahrheit rausrückt, die Situation ist ärgerlich und die Reaktion der Medien und der Öffentlichkeit schwierig. Wir sollten an dieser Stelle nachsichtig sein, uns an der eigenen Nase nehmen und es in Zukunft besser machen. Wenn wir offen kommunizieren, dass wir etwas nicht schaffen, hat das nichts mit Versagen zu tun. Es hat damit zu tun,  dass wir nicht detailliert in die Zukunft sehen können. Dass es jetzt Konsequenzen für den  Flugverkehr hat, ist ärgerlich und kostenintensiv. Nicht jeder von uns setzt gleich einen ganzen Flughafen in den Sand, klar. Aber Verzögerungen und Schwierigkeiten treten nun mal auf. Es sollte nicht passieren, aber es kann passieren – uns allen, in den unterschiedlichsten Größenordnungen.

Related posts:

1. Scrum als Verteidigungsstrategie
2. Der Product Owner / Story Writing
3. Ein Projektbericht – Die eigene Website

But then comes along the boss

And it is usually not a pointy-haired one that we all laugh about from a well-known comic strip. He (or she) has been the best developer in the organization and was outspoken for a long time, so he naturally got the promotion when the company grew and felt the need to introduce a new management layer of team leaders. Now he has the responsibility for what the team delivers, and, of course, he knows best what to deliver and how to do it. So, he will let the team be agile but when he realizes they are not using the framework of his choice he must intervene! Let’s create a task force to investigate what frameworks to use with a decision due at the end of the sprint. And he will be part of the task force. Guess what the outcome will be? And one of the committed stories of the sprint didn’t get done again!

You get the picture… No, I do not mean to say that all management is evil. Certainly mostly they have the best intentions. But all too often managers cannot rid themselves off the good old “manager knows best – manager must make decisions” logic. And the higher up the manager, the better he knows.

Leadership is necessary. But …

I am convinced, that we need managers around. Leadership is necessary. But we need to curb the inflation of managers in organizations. The natural career path is still to become a manager at some point. But does the organization really need yet another manager? And then there is the hierarchy in an organization where we all automatically think – the higher, the better, the smarter, the more money…

I believe herein lies a big problem for most organizations when they try to become agile. A hierarchical organization implies a command structure top-to-bottom that makes empowered and self-organized teams or departments so much more difficult to implement. So I propose to look at organizations in a different way.

In the following weeks I will put my thoughts on this into a small series of blog posts I will call Blueprints for Agile Organizations. I will examine the necessary minimal structures for organizations of different sizes and I will look into ways on how to describe the structures other than in hierarchical organization charts. I consider this one of many important steps to get away from command & control management to true agile leadership. Also, I want to investigate how such structures can organically grow and shrink over the lifetime of a company. I do not have the answer to all this but I have some ideas and this will hopefully help me to put some more structure into the ideas and get feedback for them.

Christof Braun, Trainer Management 3.0 & Management Consultant

Related posts:

1. Software Architecture is a Social Activity! Conways Law
2. 5 min on Scrum | The Other 3 Roles
3. Organisations need to understand …

Ihr fragt euch, was hier gerade passiert? Hier spielt ein Product Owner Team „Happy Aua“. Das ursprünglich von Bastian Sick entwickelte Bilderspiel aus dem „Irrgarten der deutschen Sprache“ dient leicht abgewandelt als Kreativitätswerkzeug und soll Product Owner auf spielerische Weise dabei unterstützen, das Formulieren von Produktvisionen zu üben. Je origineller und lustiger der Kommentar zur Karte formuliert ist, umso besser. Die Abstimmung, welcher der Kommentare der jeweils Beste ist, erfolgt gemeinsam.

Spiele bei der Arbeit?

Führen und spielen? Veränderung und Spaß? Schließt das eine das andere nicht aus? Aus meiner Sicht sollten Arbeiten, Lernen und Spielen nicht voneinander getrennt werden. Spielen steht für eine Interventionsform, die Menschen in eine Welt entführt, in der alles passieren kann. Auch, wenn noch immer überwiegend die Meinung in der Arbeitswelt vorherrscht, dass Spiele für die Freizeit reserviert oder lediglich Kindern gestattet sind, finden Menschen wie Arne Gillert, Autor des Buches „Der Spielfaktor. Warum wir besser arbeiten, wenn wir spielen“, in Unternehmen immer stärker Gehör. Er behauptet: „Wer spielerisch an die Arbeit geht, gelangt ernsthaft zu neuen Lösungen.“ Trockene Arbeitsthemen oder schier unlösbare Situationen bekommen durch spielerisches Denken und Handeln neue Impulse, weil dabei eine Quelle (fast) vergessener Ressourcen angezapft wird.

Wann habt ihr das letzte Mal Kindern beim Spielen zugesehen?  Kinder lernen in ihrer frühen Entwicklung so viel und so schnell – und seid euch sicher:  Lernen ist Arbeit – wie nie mehr wieder in eurem Leben. Wie tun sie das? Sie spielen. Sie spielen den ganzen Tag lang. Dabei befinden sie sich in einer Welt, in der ihr Geist fokussiert, hochkonzentriert und 100% aufnahmefähig ist. Die gewonnenen Erkenntnisse und Erfahrungen, das Neue, werden so wirksam im Gedankengut verankert. So sind sie für den Rest des Lebens abrufbar und es kann wiederum Neues damit assoziiert werden.

Bürotätigkeiten, Meetings, Seminare, Schulungen, Workshops oder Vorträge – all das ist Arbeit. Und allzu oft beschäftigt sich diese Arbeit nur mit Begriffen von Dingen und eben nicht mit den Dingen selbst und ihren Beziehungen zur Umwelt. Der Mensch aber braucht Entfaltungsmöglichkeiten seines individuellen Lern- und Arbeitsstils. Um dabei jedem auf seine eigene Weise gerecht zu werden und gleichzeitig für den zu vermittelnden Lernstoff Aufmerksamkeit zu bekommen, müssen Möglichkeiten geschaffen werden, die Information in die jeweilige Individualsprache, die Assoziationswelt jedes Einzelnen zu transferieren.

Spielen kann das.

Spielen erhöht nicht nur die Aufnahme- und Lernbereitschaft. Spielen ist uns allen vor allem vertraut. Schließlich waren wir alle mal spielende Kinder. Und Vertrautes schenkt uns die Freude des Wiedererkennens. Freude steuert wiederum Aufmerksamkeit, öffnet unsere Bereitschaft, (Lern-)Energien zu mobilisieren und ein Gefühl zu erleben, das uns im Kontinuum des Arbeitsalltags häufig verloren geht, nämlich die kindliche Gier nach neuen Erfahrungen: die Neugier. Neugierde kompensiert nicht nur die Angst vor Fremdem, sondern ist der Schlüssel zu in uns schlummernden Handlungsräumen wie Kreativität, Experimentierfreude, Freigeist oder Spontaneität.

Spielen braucht Handlungsräume

Spielen findet überall dort statt, wo die Folgen des eigenen Handelns begrenzt sind – also dort, wo ein Fehlverhalten keine Katastrophen oder Repressalien nach sich zieht. Schon die Bereitstellung eines sicheren Rahmens (z.B. Hier darf heute wirklich alles passieren) sorgt dafür, dass Menschen Neues ausprobieren wollen/werden.

Das schönste Spiel im Rahmen eines Sprints ist die Retrospektive. Sicher fragt ihr euch jetzt, ob ich die gleiche Retrospektive meine wie ihr. Ja und nein. Fragt doch mal euer Team: „Was lief gut?“ und fragt es ebenso „Was könnte verbessert werden?“ Allerdings probiert  zum Einstieg mal das „Spinnennetz“ aus (vermutlich kein Scrum-Team, aber hier gibt es ein kurzes Video zu einer Outdoor-Variante):

• Die Teammitglieder müssen von der einen Seite des Spinnennetzes auf die andere Seite gelangen. Dabei darf jede Öffnung des Spinnennetzes nur von einem Gruppenmitglied benutzt werden. Niemand darf über, neben oder unterhalb des Netzes auf die andere Seite gelangen.
• Achtet darauf, dass die Schnüre nicht berührt werden. Berührt ein Gruppenmitglied eine Schnur, klingelt ein in der Mitte des Spinnennetzes befestigtes Glöckchen und das Gruppenmitglied muss von Neuem beginnen. Natürlich dürfen Sie sich gegenseitig helfen.
• Ihr habt nun zunächst fünf Minuten Zeit, um euer Vorgehen untereinander abzusprechen. Dann geht es los. Beantwortet nach dem Spiel die beiden Retrospektiven-Fragen und lasst einen Bezug zum vergangenen Sprint und dem „Spinnennetz“ herstellen.

Sorgt für (Spiel-)Räume, die eine ungestörte Erarbeitung individueller Lösungen ermöglicht und ihr werdet sehen, dass die Teammitglieder dabei bereitwillig Verantwortung übernehmen.

Spielen ist Handeln, Spielen ist nicht Planen

Vor kurzem habe ich ein Kind beim LEGO-Spiel gefragt: „Was wirst du jetzt bauen?“ Ohne aufzusehen, zuckte es mit den Schultern und murmelte: „Das weiß ich nicht.“ Eine halbe Stunde später stand dort ein kleines Kunstwerk. Ich hätte das SO niemals hinbekommen! Das Kind hatte keinen Planungsworkshop belegt, bevor es mit dem Bauen anfing, sondern legte einfach los.

Natürlich ist es wichtig, einen Plan in der Tasche zu haben, weil die Ausrichtung unseres Handelns auf ein größeres Ziel nun mal dazugehört, um so den besten Weg zu diesem Ziel herauszufinden. Aber wie gut sind Pläne wirklich? Eigentlich sollten wir es aus den Erfahrungen der abertausend gescheiterten Projekte, denen scheinbar wasserdichte Pläne zugrunde lagen, besser wissen.

Versteht mich nicht falsch! Spielen bedeutet nicht, dass Planen überflüssig ist. Es ist sogar essentiell. Allerdings geht es darum, über das Maß nachzudenken. Wie viel Planung ist tatsächlich nötig, um anfangen zu können. Nicht selten ist weniger wirklich mehr. Erfolgreiche Beispiele dafür sind die Schätzspiele „Magic Estimation“ und „Planning Poker“. Traditionelle Aufwandsschätzungen funktionieren nun mal nicht und verschwenden nicht nur Zeit, sondern sind relativ zu ihrem Effekt gesehen vollkommen übertrieben. Deshalb traut euch und spielt!

Spielen fängt im Kopf an

Wenn ich in meinen Trainings mit den Lerngruppen spiele, stelle ich – zwar in unterschiedlichen Ausprägungen – aber trotzdem immer wieder das Gleiche fest: Ist das Spiel erstmal angefangen, dann machen die Spielenden kaum bis keinen keinen Unterschied zwischen der Realität und dem, was Spiel ist. Wer spielt, der stellt sich etwas vor und taucht ab in seine (Spiel-)Welt. Die Vorstellungskraft gehört mitunter zu den mächtigsten Denkwerkzeugen des Menschen.

Nehmt das Daily Scrum als Versuchsballon. Schenkt jedem Teammitglied ein Überraschungsei. Die Schokolade ist euer Geschenk an jeden aus eurem Team. Der jeweilige Ü-Ei-Inhalt definiert das individuelles Motto des Tages oder der Woche oder des aktuellen Sprints. Lasst das Team immer wieder einen Bezug herstellen. Analogien, Metaphern, Geschichten lockern die Stimmung im Team auf und sorgen für ein Mehr an Leichtigkeit im Tun.

David Holzer, Trainer & Scrum Consultant

Related posts:

1. Fussball EM und 3 Sprints | Scrum ist überall !
2. Planung ist Zeitverschwendung — Niels Pfläging
3. Schätzen vs. Planen?

Automation

Within big companies (big means 1,000+ employees), Agile automation is an important topic and requires tools. While a simple whiteboard might be enough for small companies to track their project teams status, this does not work for large, multi-project companies due to:

• Sharing the project status quo through paper is time consuming. Imagine a 20th floor company building where employees spend most of their time visiting other teams to get more information about the status of their projects and you get it.
• Release-on-demand requires assembly-line based structures where tools need interfaces to bug tracking, build and testing systems.
• Recording information for retrospectives as team members tend to forget important aspects they want to discuss during such a retrospective (although one can argue whether Agile tools need to support such a thing as employees should be capable of taking notes).

Scaling

Scaling comes together with automation as briefly touched in the previous section. Are there best practices for teams to scale? Yep, there are:

• Change-aware continuous integration. Ask a programmer what frightens him most and he will answer that question with integration (or testing, I will cover that later on). To make this process less painful, integration should be done in a continuous manner. Agile tools can support this process by recording important information, e.g. when is defect X fixed or how many stories did we finish in sprint Y.
• Just-in-time demand management. „The customer is always right.“ Within Agile we have acknowledged this fact. Highly effective teams increase their velocity in such a high-speed that continuous customer integration is not a desire but an obligation, as only they know what they want (…) and for what they are willing to pay.

Quality

Measuring software quality has been proven difficult since day one and in combination with testing, it results in what is widely known as a pain in the ass. Agile tools lift that burden by focusing on what is really useful and for whom it is useful:

• Progress information is recorded on task level as tasks are more tangible for the project team and are thus easier to discuss.
• Getting a true project status by reporting actual information on key artifacts like the code or its building. By enforcing testing, the team immediately gets the proper information regarding the product that it is shaping.
• Real time information not just for the team, but also for the management & customer as they have remote access to the information.

Hybrid approach

Let‘s face it: A 100% theory conform Agile implementation is hardly ever possible  in real life . Agile tools provide a solution by allowing what is called the hybrid approach:

• Customizable workflow that can be adapted beyond “to do – in progress – done”
• Integration with building systems, testing systems, etc.
• Customizable artifacts, e.g. teams can enhance the functionality of a burn-down chart by letting it display additional information that is viable for them.
• Support for deeper hierarchy levels that are more high-level than epics (e.g. product roadmap) or more low-level than tasks (e.g. sub-tasks)

Tools

Now that you know why you might need an Agile tool, Forrester helps you making a choice by having analyzed a bunch of Agile tools roughly two years ago with the help of the insignificant amount of 152 criteria. Those criteria are spread among the current offering (117 criteria), strategy (20 criteria) and market presence (15 criteria) of the Top 10 vendors of Agile tools.

The Top 10 is spanned by the triangle of (a) healthy growth or strong market presence, (b) experience serving large enterprises & (c) a focus on agile development and comprises of Atlassian, CollabNet, HP, IBM, Micro Focus, Microsoft, MKS, Rally Software Development, Serena Software and VersionOne.
The conclusions are based on a methodology including hands-on lab evaluations, vendor surveys and customer calls. To make a long story short, these are their conclusions:

• Atlassian adds to JIRA with comprehensive Agile project management capabilities
• CollabNet extends its platform with strong support for distributed Agile development
• HP builds on its heritage of testing with its Agile Accelerator configuration
• IBM, focusing on collaborative development, adds strong project management and analytics
• Micro Focus could build out an offering that appeals to client-server and legacy developers
• Microsoft provides the most comprehensive platform for .NET development
• MKS provides a robust development management solution
• Rally continues to extend its Agile heritage
• Serena enters the Agile market with a strong focus on Scrum team management
• VersionOne extends its Agile project management capabilities with improved integrations

Making a choice

As all vendors perform quite well according to Forrester, additional criteria can help to make a choice:
How many users does one need and which profiles do they match. Licensing costs vary vastly (starting at $6,100 (Atlassian), ending at $26,400 (MKS) for a small team including 10 daily and 30 casual users)
The pricing policy does not scale on a linear basis. Proper planning is mandatory regarding the team licenses to avoid the cost trap.
Application platform affinity. This should not be underestimated, e.g. if one has access to the Microsoft Developer Network (MSDN), TeamFoundation Server can be quite appealing.

Last but not least

This article is a summary of the Forrester Wave research. Although the publication date of this research is 05.05.2010, the tools evaluated were released in 2007-2009. Therefore, this summary is an introduction to an upcoming series of articles that will provide an up-to-date analysis of current available Agile tools regarding their abilities to present the taskboard electronically.

References
West, D., Hammond, J.S., The Forrester Wave: Agile Development Management Tools, Q2 2010, Forrester Research Inc.

Jan Segers, Scrum Consultant

Related posts:

1. Scrum Tools | tinypm | Review

Mein Vater ist Architekt und von ihm weiß ich, dass Architekten in der Planungsphase nach jeder Anpassung oft stundenlang mit den Bauherren wieder vor den Plänen sitzen. Häufig fallen die Worte: „Ich kann mir das gar nicht richtig vorstellen, ich muss das erst sehen und durchlaufen können.“ Vielleicht werden deshalb auch Fertighäuser immer beliebter. Bei Fertighäusern habe ich noch nie erlebt, dass die Bauherren das Haus erst sehen, wenn die letzte Badezimmerfliese verlegt ist – schlüsselfertig, wie es so schön heißt. Und noch weniger sind alle Beteiligten von Änderungen während der Bauphase – auch nach detaillierter, gemeinsamer Planung – befreit. Sei es wegen unvorhergesehener Schwierigkeiten beim Bauen selbst, wegen Änderungswünschen der Bauherren oder neuen Ideen des Architekten.

Der Kunde darf nerven

An der Softwareentwicklung mit Scrum gefällt mir so gut, dass es von dem Anspruch Abstand nimmt, ein schlüsselfertiges Produkt abzuliefern. Der Kunde darf bei der Entwicklung mit Scrum den Rohbau bewundern, das Richtfest feiern UND sich bei der Teppichauswahl zehn Mal umentscheiden. Und obwohl sie diese Dinge tun, werden die Architekten nicht arbeitslos oder hören gar auf zu planen – ebensowenig wie Entwickler, Softwarearchitekten, Tester oder Product Owner. Ganz im Gegenteil, sie reagieren bestmöglich auf alle diese neuen, veränderten Anforderungen. Ja und manchmal ärgern sie sich auch darüber, dass die Bauherren das nicht früher gewusst haben. Aber schließlich müssen sie darin wohnen, nicht der Architekt selbst. Anders bei Fertighäusern: Da ärgert sich meist nur der Bauherr, weil er im Endeffekt die kleinen Anpassungen doppelt bezahlt – nur dass wir in der Softwareentwicklung selten ein Produkt zwei Mal bauen.

Doch was tun, wenn wir keine Fertighaus-Software einsetzen können oder wollen? Was wenn der User genau wegen der individuellen Anpassungen und Mitgestaltung den Wert der Software erkennt?
Nehmen wir uns ein Beispiel am neuen Willy-Brandt Flughafen in Berlin. Hier wird vor dem Live-Betrieb mit immer größer werdenden Gruppen die Funktionsfähigkeit der Architektur, der Services, der Nutzerführung etc. geprüft. Die Tests fingen so früh an, dass auch grundlegende Änderungen gemäß dem Nutzer-Feedback noch möglich waren. Test-Passagiere sind mit allem ausgestattet,  was es im normalen Betrieb braucht und sollen sich wie ganz normale Passagiere verhalten. Inklusive Beschwerden, Hektik, Mitführen verbotener Gegenstände, Drängeln und Orientierungslosigkeit. Meckern ausdrücklich erwünscht!
Ich warte schon gespannt auf meinen ersten Flug vom neuen Flughafen Berlin aus und werde sicherlich Punkte erkennen, bei denen ich sagen kann: Hätten sie doch nur mich gefragt! Und obwohl ich weiß, dass es viel Nerven kostet, werde ich mich nicht für ein Fertighaus entscheiden.

Kristina Klessmann, Scrum Consultant

Related posts:

1. Scrum User Group Karlsruhe
2. Scrum Alliance mal wieder führungslos – Donna Farmer geht
3. Wo ist der Certified KANBAN Master?

Natürlich sind die wenigsten Produkt-Entwicklungsteams so aufgebaut wie ein IDEO-Team, aber welche Elemente können wir dennoch nutzen und was können wir von IDEO lernen? Hier meine 10 Tipps:

• Involviere das gesamte Team. Wieso auch nicht? Schließlich nehmen wir auch im “richtigen” Leben Menschen unterschiedlich wahr. Alle im Scrum-Team sollten dazu beitragen, die Personas zu kreieren. Jeder hat Ideen und durch die gemeinsame Vorstellungskraft werden unsere Personas lebendiger und greifbarer.
• Erstellt die Personas gemeinsam auf Flipcharts und nutzt dabei Fotos von realen Personen oder schneidet Bilder aus Zeitschriften aus.
• Geht bei der Erstellung der Personas am Anfang ruhig ins Detail. Informationen können später  wieder reduziert werden.
• Findet heraus, welche Ziele diese Persona verfolgt.
• Welche Usability-Bedürfnisse hat diese Persona?
• In welchen Lebensumständen befindet sich dieser Mensch?
• Wie sieht der Job der Person aus?
• In welchem Kontext nutzt diese Persona euer Produkt?
• Wenn das alles gemeinsam erarbeitet worden ist: Geht raus und überprüft eure Ideen.
• Dann verfeinert die Persona.

Lasst die Personas auch an eurem Entwicklungsprozess teilhaben! Sie sollten bei Meetings – dem Sprint Planning 1 und 2, während der Reviews, aber auch bei allen Design-Entscheidungen – mit im Raum sein.

Fragt euch immer: Wie würde die Persona das Feature sehen, das ihr gerade entwickelt bzw. entwickeln lasst?

Related posts:

1. Die User-Rolle ist tot, es lebe die Persona
2. Die drei weiteren Rollen in Scrum
3. Die Skills eines guten ScrumMasters

Zu Erinnerung:

Als User-Rolle
möchte ich eine Funktionalität
so dass ich den folgenden Nutzen habe. [1]

Eine super Idee, die dann von Mike Cohn aufgegriffen und durch sein Buch „User Stories applied“ populär gemacht wurde. Die Idee war so einfach, dass sie die damals gängigen Use Cases als Analysetool sofort überholte. Das Tool ist aber so einfach wie schwierig. Funktionalität aus Anwender-Sicht zu beschreiben, fällt vielen sehr schwer. Noch spannender ist zu beobachten, dass es tausende User Stories gibt, die im folgenden Format formuliert werden:

Als User möchte ich XX

Also wird zum einen einfach aus User-Rolle = User und die Frage nach dem “Wozu” wird oft weggelassen.

Echte Menschen für echte Rollen – die Persona

Heute möchte ich kurz über den User reden. Es ist wichtig zu sehen, dass User-Rolle gemeint war, nicht User. Es geht darum, dass sich der Product Owner und das Team eine echte Anwenderrolle überlegen und mit dieser arbeiten. Das Konzept der User-Rolle ist hier aber offenbar nicht griffig genug. Daher schlage ich vor, das Konzept der User-Rolle aus den User Stories zu streichen und durch das Konzept der Persona zu ersetzen. Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Applikationen, unsere Anwendungen, unsere Produkte benutzen.

Eine noch schönere und ausführlichere Beschreibung einer Persona findet ihr auf dieser Website, zusammen mit der folgenden Beschreibung, was eine Persona ist:

“Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. They act as ‘stand-ins’ for real users and help guide decisions about functionality and design. Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo.
Although personas are fictitious, they are based on knowledge of real users. Some form of user research is conducted before they are written to ensure they represent end users rather than the opinion of the person writing the personas.“

Wir machen also aus der Rolle Administrator zum Beispiel: Hans Müller, 35 Jahre, IT-Fachmann, lebt in München, fährt morgens mit der U-Bahn zur Arbeit. Er hat zwei Kinder, ist Studienabbrecher und faszinierter Science Fiction Fan. Er liebt es, mit seinen Kinder Lego zu spielen.

Diese Person ist aber erforscht. Das heißt, wir reden mit einigen Admins, finden heraus, wie die wirklich leben, wie sie unsere Applikation tatsächlich nutzen werden. Hat man mit seinem Team diese Personas identifiziert – und davon gibt es natürlich einige, ihr könnt auch mehr als eine Persona pro User-Rolle definieren -, dann kann man anschließend die User-Rolle durch die Persona ersetzen. Auf diese Weise entsteht eine wesentlich lebendigere Vorstellung davon, für wen man die Applikation erzeugt, als durch die User-Rolle. Zumal dann per se klar wird, dass es nicht nur einen User gibt.

Viel Spaß beim Erstellen von Personas!

[1] Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2010

Related posts:

1. Wie erstellt man eine Persona?
2. Scrum Rollen | Andwender | End-User
3. Scrumlies | Der End-User

Folgende Situation: Eine vergessene Ausschreibung trudelt auf dem Tisch eines Mitarbeiters ein. Plötzlich müssen Kundenwünsche „schnell“ oder „mal kurz“ vom Entwicklungsteam umgesetzt werden. Untermalt von der Aussage:

"Leute, es muss schnell gehen, heute machen wir kein Scrum!" Ein Gehetzter

  Und dann setzt man sich (im besten Fall) noch einmal zusammen und bespricht im Schnellverfahren, was zu tun ist. Dann hauen alle in die Tasten und die Abstimmung, die in Scrum eigentlich mehr Raum hat und sonst so gelobt wird und zum gewünschten Erfolg führt, wird ausgesetzt, weil sie angeblich zu lange dauert. Was bedeutet das? Dass Scrum nur toll ist, wenn man lange Planungsphasen hat? Wenn es aber schnell gehen muss, gibt es keine Zeit für eine richtige Abstimmung?

Was will Scrum?

Scrum möchte weg vom schnellen Dazwischenschieben von Aufgaben, hin zu einem strategischen Agieren und Planen. Dazu ist ein Product Owner nötig, der alle Termine im Blick hat und auch einmal Nein zu unerwarteten Kundenanforderungen sagen kann. Und hier spreche ich nicht vom Stillstand beim Kunden – dass es hier eine Ausnahmesituation braucht, ist selbstredend. Hier sind wir schnell bei den Verantwortlichkeiten und Aufgaben des PO: Er oder sie muss die Kundentermine im Blick behalten, sie priorisiert in das Backlog bringen und die Kundenanforderungen dann von den Entwicklern abarbeiten  lassen. Keine leichte Aufgabe, denn meist ist es ja nicht nur ein Kunde, dessen Wünsche und Bedürfnisse gestillt werden müssen. Einen guten Product Owner zeichnet ein gutes Organisationstalent aus. Und nicht nur das: Er hält den Kontakt zum Kunden, um rechtzeitig Anforderungen einzusammeln und den Entwicklern periodisiert zur Verfügung zu stellen.
Gelingt das dem Product Owner gut, dann ist es eine Arbeitserleichterung für die Entwickler. Sie müssen dann nicht mehr im letzten Moment auf den Plan gerufen werden, um das Feuer am Dach zu löschen.

Gilda Feller, Scrum Consultant bei bor!sgloger

Related posts:

1. Commitment des Product Owners
2. Scrum Rollen | Der Kunde | Customer
3. Wissen, was am wichtigsten ist…