Jobwechsel und viele Jobs zu vergeben mit Empfehlungsboni

31.08.2011

Ende Juli habe ich bis auf das Blog und Quality Reviews für das PMI® meine Selbständigkeit zugunsten der Rolle des CTO bei DailyDeal an den Nagel gehängt. Geplant war der Wechsel in eine solche Rolle schon länger, aber entscheidend ist am Ende, ob man sich in einer Firma wohl fühlt.

DailyDeal hat in der Anfangsphase meine gesamte Zeit beansprucht und so hat das Blog zurückstecken müssen. Ich habe tolle, hochmotivierte Teams: Produktmanagement, Software Engineering, Qualitätsmanagement und IT Operations. Innerhalb von weniger als zwei Jahren sind wir auf weit über 200 Mitarbeiter gewachsen und haben hervorragende Aussichten. Entsprechend baue ich die Teams weiter aus und suche Sie:

  • Head of IT Operation
    Im Rahmen der Vervollständigung meines Management-Teams möchte ich die Verantwortung für die IT Operations-Teams in die Hände eines erfahrenen Experten legen.

  • Scrum Master
    Start ist die Stärkung von Scrum in den Entwicklungsteams und dann die weitere Agilisierung des gesamten Unternehmens.

  • Projektmanager
    Große Projekte stehen an, die professionell gemanaged werden wollen einschließlich Einführung einer PM-Methodik.

  • Senior Produktmanager
    Zur Vervollständigung unseres Produktmanagement-Teams suche ich erfahrene Produktmanager mit hervorragendem Methodikwissen.

  • Senior Software Developer
    Unsere Teams werden mit Ruby- und PHP-Experten ausgebaut, insbesondere um in Kürze neue Technologien an den Start zu bringen.

  • Senior Linux Administrator
    Wir sind mitten in der Einführung und Auswahl neuer Technologien, um noch schneller wachsen zu können. Seien Sie dabei!

  • Senior Network Administrator
    Wie die Linux-Server, muss auch das Netzwerk im Datacenter und im Office weiter ausgebaut werden.

  • Werkstudent Administration
    Die Evaluation neuer Technologien und der Bau von Prototypen sind im Fokus, eine spätere Festanstellung das Ziel.

  • Praktikanten für die Interne IT
    Starten Sie bei uns, bewähren Sie sich und verstärken Sie unser Team später in Festanstellung.

Der Ausbau der Teams hat für mich höchste Priorität, deshalb aus meiner Tasche jeweils ein Amazon-Gutschein über € 200 für die Empfehlung eines Managers aus der obigen Liste, wenn er bei mir anfängt, € 100 für einen Mitarbeiter und € 50 für einen Werkstudenten oder Praktikanten.

Wenn Sie jemand in Ihrem Netzwerk kennen, der in einer coolen Firma in Berlin anfangen will, nehmen Sie Kontakt mit mir auf.

Derweil habe ich dann den 3. Bloggeburtstag am 16.08. verpasst und hätte es mit 957 Artikeln auch fast geschafft nach drei Jahren die 1.000er-Grenze zu knacken…aber Prioritäten sind Prioritäten.


Nachlese zu den Änderungen am Scrum Guide 2011

15.08.2011

Nachdem der neue Scrum Guide 2011 vor 3 Wochen erschienen ist, hatte ich bereits die wichtigsten Änderungen gepostet (Teil 1 und Teil 2). Inzwischen gibt es diverse Postings aus anderen Blogs, die die Änderungen kommentieren bzw. ergänzen:

  • Definition von ScrumBut
    Ken Schwaber hat in seinem Blog die bisher harte Einschränkung von ScrumBut relativiert. D.h. durch die Entfernung einiger Scrum-Praktiken wie Burndown Charts und Releaseplanung aus dem Scrum Guide, werden die Grenzen dessen aufgeweitet, was noch als Scrum gezählt wird. Alternative Praktiken zu Releaseplanung etc. haben in der Vergangenheit ebenfalls zum Erfolg geführt. So liefert der neue Guide nun den minimalen Kern, um den herum Ken inzwischen sogar empfiehlt, seine eigene Lösung aufzusetzen.

  • Ordered vs. Prioritized
    Jim Coplien hat sich u.a. des Themas Nikoläuse auf Webseiten im Sommer angenommen. Er argumentiert, dass eine einfache Priorisierung des Backlogs durch jeweils paarweisen Vergleich von Stories ungünstig ist da mehr Faktoren berücksichtigt werden müssen, wie beispielsweise der Zeitpunkt, zu dem eine Story live geht.

  • Chicken & Pigs
    Steve Porter argumentiert in seinem Gastbeitrag auf scrum.org, dass der Entfall der beiden Schubladen Chicken und Pigs vorteilhaft ist. In der Vergangenheit haben sich Stakeholder als “Chicken” gerne zurückgezogen, da sie lt. Scrum nichts zu sagen hatten. Die neue Aufteilung in “Organisation”, “Mitarbeiter” und “Stakeholder” ist hier weit hilfreicher.

  • Kritik von Boris Gloger
    Boris hat sich den neuen Guide ebenfalls vorgeknöpft. Er sieht einen Verlust essenzieller Scrum-Werte und die verpasste Chance nachzuschärfen, beispielsweise beim Sprint Plannung als Dialog und nicht als Planung. Im Rest des Postings rechnet er mit Problemen und Fehleinschätzungen von Scrum ab, die er aus seiner Sicht gelöst hat. Teilweise hat er Recht, auf der anderen Seite gibt es hier mehr als einen Weg zum Erfolg. In einem vorhergehenden Posting hat er den Wert von Commitments verteidigt.

  • Commitment vs. committed team
    Jan Gentsch geht im oose Teamblog der Frage nach, was es denn mit dem Commitment auf sich hat. Letztlich geht es weniger darum, mit einem Commitment den Verdacht eines Vertrages zu erwecken, sondern um die Übernahme von Verantwortung durch das Team, um ein Ziel zu erreichen.

Das Foto stammt von SaZeOd.


Scrum Pattern: Stable Teams

01.08.2011

 

  
ContextA Development Team is formed and is to be changed.
ProblemThe Velocity will decrease.

When changing members of a development team, at least these two laws apply:

  1. Brook’s law
    “Adding manpower to a late software project makes it later.”
  2. Tuckman’s stages of group development
    “Forming – Storming – Norming – Performing”

Furthermore, common traps are waiting like

  • work queuing up for specialized teams (e.g. a database team),
  • shifting team members around, triggering the Tuckman stages from the beginning,
  • multitasking on several projects drastically reduces productivity,
  • detailed models for team members from different teams assigned to the same project usually fall short,
  • the required knowledge and skills may not be available when required and
  • failing teams being staffed with team members from successful teams usually do not lead to improvement.
Forcestoo little/too much organizational overhead
too little/too much flexibility in team composition
too little/too much specialization of a team
too little/too much multitasking
SolutionKeep Development Teams stable

Guide the Development Team through the Tuckman stages and keep it stable afterwards. Feature Teams have the best chance to be productive without the need for changes in their composition. When a new task has to be done by the Development Teams and skills or knowledge are missing, the issue can be fixed without changing the team. Team members do not need to be shuffled from crisis to crisis, but can improve the velocity of the team as the members know each other and can improve productivity step by step.

Resulting ContextThe Development Team is kept stable and improves its velocity.

Scrum Pattern: Committed Dependencies

01.08.2011

 

  
ContextA Scrum Team is in the Sprint Planning meetings.
ProblemThe Development Team needs deliverables or services from collegues outside the team but the same organization to realize the Sprint Goal.

If a self-organized Development Team has successfully negotiated a Sprint Goal with the Product Owner and requires support, deliverables or services from outside collegues, the team cannot rely only on itself anymore. These collegues are called “dependencies”. If the dependencies are not committed on the forecast of the Development Team for the Sprint, the chances to reach the goal are reduced.

Forcestoo little/too much organizational overhead
SolutionThe dependencies commit on the Sprint Goal

Build a second group of people around the Development Team for the Sprint consisting of those collegues, which need to contribute to the Sprint for the Sprint Goal to be reached. They need to be part of the Sprint Events and fully support the Sprint Goal as well as the forecast. These “Committed Dependencies” will organize their work around the commitment to support the Sprint Goal and become part of the Sprint instead of creating the need for additional management effort. The Development Team needs to plan the forecast with the dependencies, so that they can commit.

Resulting ContextThe Scrum Team and the Committed Dependencies can meet the Sprint Goal by relying on self-organization.