Agile Werte

Mein Team führt schon seit geraumer Zeit eine Diskussion darüber, wie man den Prozess verbessern kann. Und das ist auch gut, denn ständige Verbesserung ist ein zentraler Bestandteil jeden agilen Handelns.

Allerdings liegt die Antwort auf die Frage nie in Werkzeugen und deren Möglichkeiten. Um das Problem zu lösen muss dessen Ursache verstanden werden. Jira bietet sicher viele Möglichkeiten, noch ein Feld einzuführen. Wenn die Diskussion sich darum dreht, welches Feld am besten ergänzt wird und wie ein Zustandsübergang abzubilden ist, ist das agile vollkommen aus den Augen verloren.

Eine unmittelbare Konsequenz von Werkzeugen ist, dass sie es Teammitgliedern erlaubt, Verantwortung abzugeben. Der Zustand wird möglicherweise richtig abgebildet, das Feld richtig gefüllt. Nun ist es an jemand anderem das technische Problem zu identifizieren, die Person weiss möglicherweise nicht einmal über den Zustand Bescheid.

Agil soll heissen, das Vertrauen aller Mitglieder im Team soweit herzustellen, dass notwendige Arbeit in Standup Meetings oder spätestens im Review transparent gemacht wird. Dabei kann kein Tool helfen.

When a Project dies

When is a project dead?

One question that somebody asked me a few days back keeps me thinking for a while now. Mostly, because it should not have a clear answer. Have you ever had to ask yourself, what to do when your heart-project is at risk to coHantelnme to an end? A project that just dies, has had some serious problems.  A dead-end, that leaves no next steps, along a final decision. In a way that no project goal materialized and no other milestone is reachable? If that is looming to happen, one should consider to check the project plan and answer a couple of questions about the failure. How did all the tasks and work packages depend on each other, that they made an entire project fail? Were some assumptions to optimistic? Was budget too tight? Was the project to ambitious?

The show must go on

KabelDepending on size, no project is barely ever dead. Typically, a project consists of multiple components. Milestones, Tasks, Work-Packages, are just common terms for break downs structures of a project. Such fragments, re-used or re-arranged, can help achieving a modified goal. There are reasons, one or another milestone had difficulties. There are hard facts, like budgets, technical dependencies or necessities, required skills, availability of material or combinations of anything. And there are soft facts, like project team engagement, stakeholder opinion, even hubris may result in milestones not being reached.

Failure

A roadblock, identified early enough, allows to realign a project plan, to cope with any trouble, endangering tasks and milestones. In an iterative project approach, the project lead can change a goal, aligning with changing requirements. This way, the project may not reach it’s initially intended goal, but it will not fail in its totality. When a project dies, it will leave bad feelings with the budget owner, with stakeholder and the team. A goal that the team reached, maybe through a more creative approach, will still be a goal reached.

Why monitoring is hard

(and why your vendor will only sell you tools, not solutions)

https://www.flickr.com/photos/nnova/2923863893/in/photolist-5snySr-jeSGCg-eXcWqz-geQjsH-anmVGs-qedFb-nDbeu-5cyqbZ-5Utz4K-dmQRo-niwwp2-ngu4D5-3FkH1H-9M5SRv-61eVuz-5aWZm4-7EGNmd-iQPUJ-h69bVu-gGLPDU-i5yXU-cNtg63-6VbuRr-gGLP4f-3eNSrQ-4J8zy8-ynoqx-5prCky-cCU7a-6dCwzA-7GiFib-8Ya1fz-4bbgRN-7ddyJ-6zQC9V-btU3pv-6zz5rH-gGMbdw-bnZkqK-8idtba-62z3jS-ejFXkL-8F4KAM-a6uDj-bg2uJH-dxoB9N-jbjCu-gGM5RD-gGLMjy-5Dzd6b

Intro

Monitoring infrastructure in a meaningful way is important to any IT operations, yet it is hard to realize. Many vendors adress this problem and promise a silver bullet.

Continue reading “Why monitoring is hard”

Complex Processes

Observation

Organizations have to become more mature in their processes while they grow. While this is true for all types of organizations, my perspective is an IT and IT related one alone, also being part of other organizations. With complex technologies coming into every aspect of business, individual solutions are being provided by increasingly specialized vendors. With this, the number of service providers, managing products and – more importantly – solutions, the number of involved parties rises, which in turn increases complexity.

Problem

Now that setup of multiple parties involved requires organization to make it work properly. Processes need to be introduced, to track progress, make sure the right parties get the right information at the right time, and progress and outcome are trackable and manageable.

All of the requirements are clear to justify a strict process. Provided they are viewed from the right angle. Participants in the process, staff executing individual steps, have difficulties seeing the purpose.

Improvement

A transparent process is easier to follow for individual contributors. Management needs to feed back outcome of work, results to their staff. When everybody understand what he is doing, less steps will be done wrong. Eventually it will even take out complexity out of some processes, because transparency can help avoid the need for exceptions to be built in.

Please share your thoughts!

 

Lessons Learneds – Flight Projects Directorate Code 400

Raum- und Mondmissionen sind berühmt für hervorragendes Projektmanagement und so finden sich bei der NASA auch schöne Dokumente zu dem Thema. Besonders schön zu lesen sind die 128. von Jerry Madden, Retired Associate Director (400), niedergeschriebenen Erfahrungen (Lessons Learned) zu lesen. Bezüglich Meetings hat er eine ganze Reihe von Ratschlägen. Einer hat meine ganz besondere Aufmerksamkeit gefunden.

115. Reviews, meetings, and reality have little in common.

Continue reading “Lessons Learneds – Flight Projects Directorate Code 400”

IEEE TMC Workshop on Integrated Project and Quality Management 21.06.2013 Munich

Das Technology Management Council der deutschen Sektion des IEEE veranstaltet am 21. Juni einen Workshop zum Thema “Integrieres Projekt und Qualitätsmanagement“. Ziel des Workshop ist den Zustand der gängigen Methoden zu bestimmen und praktische Beispiele zu liefern, wie Qualitätsmanagement eine schnelle und zuverlässige Daten-Quelle zur Entscheidungsfindung sein kann.

Veranstaltungsort ist die TU München, Arcisstr. 21, München, Raum 0999, Nähe Audimax.

Zeit: 21. Juni 2013, 13:00-18:00

Program als PDF.

Anmeldung über Aminado: IEEE TMC Workshop on Integrated Project and Quality Management 21.06.2013 Munich.