Installing TFS2010 Beta2 with a FQDN

Wow, it took me three four days to figure out how to properly install TFS 2010 Beta2 using a Fully Qualified Domain Name (FQDN).

Perhaps you can save some time seeing which steps are necessary to get it up and running.

As a basis for the installation Keith Patton provided a good bunch of information so feel free to have a look at his blog to find some more information. I think that some steps are missing in his description due to the fact that it did not work properly following the mentioned steps.

I advise you to print his blog entry and use it as the guideline for the configuration. Compare every step with my screenshots to proof, where to fill in the FQDN and where to use the netbios server name.

Now start the configuration. The scenario was based on a server which was part of an Active Directory domain. Though it is a single server installation, we need to use advanced setup due to the reporting services account which needs to be split from using a domain account at Sharepoint level.

 

 

 

 

Click to enlarge the setting overview.

If you have no existing Report Server database, you can create one using the Reporting Services Configuration Manager. If you have a clean installed Reporting Services, there will probably be one already.

You will have to use Native mode. Check this on your installed reporting server database.

Click to open the configuration summary shown in TFS Admin Console.

We have to add an Sharepoint mapping in Central Administration now (have a look at the linked blog entry by Keith) how to get there.

Change the URLs as described by Keith in TFS Admin Console.

Modify the reporting services settings in the TFS Admin Console:

The result should look like this.

Now edit the access rights as mentioned by Keith.

Now, a good bunch of configuration work is done. Create a new team project. You should be able to open the portal website from a remote pc:

http://ksimons01.letsgetagile.de/sites/MyCollection/Test123/Dashboards/ProjectDashboard_wss.aspx

Some reports could be missing due to the fact that TfsRedirect.aspx will still provide the netbios name using a misconfigured ReportServerUrl which is cached.

Have a look at the Redirection settings at the bottom of the debug page:

Test link: http://ksimons01.letsgetagile.de/sites/MyCollection/Test123/_layouts/TfsRedirect.aspx?tf:Type=WebAccess&tf:Test=1

To fix this issue, clear the redirector cache:

http://ksimons01.letsgetagile.de/sites/MyCollection/Test123/_layouts/TfsRedirect.aspx?tf:Type=WebAccess&tf:ClearCache=1&tf:Test=1

Check again using the test link above. If it did not work try the last link with one of the tf:Type settings: Report, Reports, ReportLists. Ignore shown exceptions. Check again by using the test link.

The only issue I could not yet fix is, that some provided Excel Workbooks have invalid connection information stored within. You will have to fix them using the Connection command under the Team tab in Excel.

I am really looking forward to the final release and hope Microsoft will provide some more technical information on this topic. The manual clearing of the cache should be done automatically when changing the Reportserver Url in TFS Admin Console at least.

Update: If you have any problems related to some links (like the portal home link) still pointing to the netbios name of the sharepoint server in the project portal, your AAM is configured wrong.  You need to extend your website properly (read this entry, and topic “Mistake #3” here).

Cross Functional Teams in Scrum

Viele Projekte verwenden die weit verbreitete drei Schichten-Architektur. Oft sind in diesen Projekten je ein Entwickler für je eine Schicht zuständig . Doch solche nicht “cross-functional” Teams haben einige Nachteile:

In Scrum Teams sollten alle Teammitglieder in der Lage sein, an beliebigen Anforderungen des Product Backlogs zu arbeiten. Was passiert, wenn das Teams nicht können, habe ich erlebt:

• Eine Umverteilung von Arbeit ist nicht möglich, da diese konkret an Personen gekoppelt ist
• Komplette Sprints können (im Sinne des Business Value) ergebnislos bleiben, wenn ein Teammitglied ausfällt, da es eine vollständige Schicht betreut. Somit kann nahezu keine Anforderung umgesetzt werden
• Es entsteht manchmal ein schwächeres Team Commitment, da die Teammitglieder selbst den Fortschritt nur wenig beeinflussen können, auf Grund der nicht möglichen Umverteilung von Arbeit.

Tja, wie sieht die Wirklichkeit an diesem Punkt aus? Gibt es Entwickler, welche alle schichtrelevanten Technologien beherrschen? Ist das Utopie?

Ich glaube, das hängt vom Kontext des Projekts ab. Projekte haben unterschiedliche technologische Tiefen. Abhängig von diesen Tiefen ist das notwendige Wissen, um sinnvolle und qualitativ hochwertige Änderungen zu machen.  Wenn die Spannbreite über alle Technolgiebestandteile sehr hoch ist, mag dieses Vorgehen nicht möglich sein. In größeren Teams können Entwickler aus gleichen Schichten Fluktuationen besser abfangen.

Cross-functional Teams bleiben weiter ein Diskussionspunkt. So habe ich sie auch bisher wahrgenommen.

Erste Schritte in Scrum Prozessen

Seit ich mich mit Scrum beschäftige und es bei Kunden etabliere, habe ich bemerkt, dass es manchmal starke Widerstände gegen Neues gibt.

"Scrum ist wie Ihre Schwiegermutter," hat Ken Schwaber letztens auf der Agile Vancouver Konferenz gesagt. "Es zeigt Ihnen permanent Ihre Unzulänglichkeiten."

Vielleicht möchte nicht jedes Unternehmen diese Unzulänglichkeiten sehen oder nimmt sie in Kauf, da es sich handlungsunfähig in manchen belangen fühlt.

Als erstes ist es ein Problem des Prozesses, ein Problem von Scrum selbst. Der Prozess ist häufig schuld. Vielleicht sollten wir ihn abändern? Wir können diesen Prozess nicht so abbilden, wie er im Buch steht.  Und wir können gerade jetzt keinen Prozessoverhead gebrauchen sondern müssen produktiv arbeiten und voran kommen...

Wenn man den Projektverlauf und die Arbeitsorganisation dann betrachtet, stellen sich Mängel heraus. Mängel, welche nach Veränderung rufen und bei einer guten Lösungsidee dann auch von allen gewollt und getragen werden. Die Einführung von Scrum ist ein permanenter Prozess, der Zeit und vor allem die gemeinsame Erfahrung aller Beteiligter braucht. Wichtig ist, dass jeder Änderungen nachvollziehen kann und selber mitträgt. Sonst kann ein Prozess nicht funktionieren.

Vor einer erfolgreichen Scrum-Einführung muss immer der Willen des Unternehmens existieren, Veränderungen zu benötigen und zu wollen.

Nicht zuordnebare Tasks

Haben Sie von einem Teammitglied schon mal gehört, dass notwendige Tätigkeiten (z.B. Infrastruktur) eigentlich keinem Product Backlog Item zuordnebar sind?

Auf Nachfrage ergab sich, dass zur direkten Zuordnebarkeit eine Abstimmung mit einem anderen Teammitglied notwendig sei, damit der konkrete technische Bedarf geklärt wird.

In einer getimeboxten Session von 3h kann  hier eine detailliertere Klärung durchgeführt werden und es entstehen direkt zugeordnete Tätigkeiten.

Diese Klärung sollte im Planungsmeeting erfolgen oder - sofern nicht fertig geworden - während der Sprintzeit fortgesetzt werden. Die Abstimmung muss so oder so zwischen den Teammitgliedern erfolgen.

Man bemerke: Wenig von dem, was als nicht zuordnebar dargestellt wird, ist es de facto auch.

Als Product Owner interessiere ich mich nur für die Umsetzung meiner Anforderungen, daher sollten auch alle erbrachten Aktivitäten genau dieser Umsetzung dienen. Bei technisch notwendige Aktivitäten frage ich mich häufig, worin ihr Mehrwert besteht und auf diese Frage gibt es sehr häufig dann auch konkrete Antworten, welche mich auch als Product Owner überzeugen.

Zuständigkeit für Sprint Backlog Items

Was passiert eigentlich, wenn eine Person Sprint Backlog Items für alle anderen Teammitglieder im Vorfeld anlegt, um eine Planungssitzung zu verkürzen?

Die Erfahrung, die ich gemacht habe: In der Planungssitzung herrschte nur geringe Beteiligung des Teams. Jeder akzeptierte die Sprint Items, welche auf sehr hohem Niveau erstellt waren ("Erstellen der GUI"), da dem Ersteller kein weiteres Detailwissen vorlag. Während des Sprints entstanden Unklarheiten, wer jetzt was zu bearbeiten hat, was dieser oder jener Task überhaupt bedeutet. Des Weiteren fehlten viele Sprint Backlog Items. Andere blieben unangefasst.

Kurzum: Wenn die Teammitglieder nicht selbst die Tasks anlegen, identifizieren sie sich nicht mit den Aufgaben und verstehen diese nicht zwangsläufig. Finger weg von "Vorgaben von oben" bei einem Scrumprojekt.