Scrum?!? Das geht bei uns nicht!

Im Rahmen des Scrum Breakfast in Zürich, ein Event der von der namics ag gesponsert wird, gab es bereits viele Kommentare und angeregete Diskussionen mit Lösungsansätzen, wie man diese Frage beantworten - oder besser sorgar umgehen kann. Beim kommenden Scrum Breakfast am 02. Juli 08 wird Francois Bachmann von SPRiNT-iT Suisse SA das Thema aufgreifen und Antworten geben können.

Titel: Scrum Breakfast: Scrum?!? Das geht bei uns nicht!
Ort: namics Zürich, Konradstrasse 12/14, 8005 Zürich (map)

Anmeldung: per xing.com Event.

Im Rahmen des Scrum Breakfast war Prof. Stuart Read der IMD in Lausanne bei namics zu Besuch. Er moderierte eine angeregte Diskussion über die von Ihm verfasste Fallstudie der Firma Guidewire [pdf, 216KB], welche Scrum als Organisationsprinzip für die ganze Firma umgesetzt hat.

Stuart startet sofort den Dialog und lässt die Fallstudie von einem Teilnehmer zusammenfassen. Danach führten vier Fragenkomplexe durch die 2 Stunden und erst in den letzten 15 Minuten zückt er eine Powerpoint, von der er nur ein Slide zeigt (und des Rest als Handout abgibt). Sehr aktiv, spannend und eloquent. Seybold, der Firmengründer von Guidewire, war zusammen mit Stuart im College und daher gab es viele weitere Details die nicht im Papier drin sind (Management lese halt nicht mehr als 5 Seiten). Die zentralen Fragen der Diskussion waren:

1) Würden Sie bei Guidewire arbeiten wollen?
2) Wie muss eine Firma "für Scrum" rekrutieren?
3) Würden Sie Guidewire-Produkte selbst kaufen?
4) Soll Guidewire diesen Ansatz trotz der Grösse (300 Mitarbeiter, stark wachsend) und einem geplanten Börsengang weiterführen?

Im Raum sassen etwa 30 Leute mit Scrum-Erfahrung und auf der anderen Seite brachte Stuart seine Erfahrungen mit ein, wenn er die Fallstudie bei grossen Firmen zur Diskussion stellt.

Die erste Frage wurde im Raum mit einem klaren ja beantwortet, führt bei Firmen aber zu einer starken ja/nein-Polarisierung. Weshalb würde jemand nicht in einer mit Scrum geleiteten Firma arbeiten wollen, obschon es Wert schafft? Möglicherweise ist es einigen Leuten zu transparent und zu kompetitiv und somit zu anstrengend; Oder gar schlecht für die Karriere. Stellen Sie sich vor, der "verdiente" Titel ist weg und jeder muss sich im Arbeitskontext täglich beweisen. Nun ja, für namics normal, für andere Firmen halt nicht.

Wie rekrutieren? Die Antwort in der Essenz wohl: "The Scrum Way" resp. lasst das Team entscheiden. Also die Bewerber in den Arbeitskontext tun und dann die Mitglieder des Teams fragen, ob sie die Person als Verstärkung wollen. Spannend, denn genau so macht es namics. Interessant auch die "Gegenaussage" von Seybold "don't hire for expertise" wohl ergänzt um "but for personality". Trifft den Punkt!

Eine längere Diskussion fand um den Punkt statt, ob jemand die agil produzierte Standardsoftware kauft oder die Wahrnehmung von aussen zu chaotisch ist. In Essenz muss der Käufer Vertrauen in den Verkäufer haben. Und wie stelle ich dies sicher? Die richtige Sprache (Geschäft verstehen), immer liefern was ich verspreche, gute Referenzen, nicht mit den Controllern sprechen ;-) u.s.w. Dieser Punkt ist der zentralen Punkt in der namics Einführung, nämlich die Erklärung, dass Professional Service immer so funktioniert (resp. wie entscheide ich, ob ich einem Arzt trauen kann). Basis sind unsere verbindlichen "namics Professional Ethics Principles" mit elf einfachen, aber essenziell wichtigen Regeln wie "Respect for the Individual" (keine fachliche Hierarchie und Anerkennung der Leistungen der aller Disziplinen), "Accepting Projects" (nur Projekte annehmen, welche wir auch wissen, dass wir diese exzellent liefern können) oder "Internet Principles" (nichts tun, was gegen Internet-Prinzipien verstösst). Für die Leute im Raum war es klar: Wir kaufen. Für Manager grossen Firmen evt. nicht.

Und schlussendlich ein spannender Aspekt, zusätzlich zum Wachstum von Guidewire. Die Firma plante einen Börsengang... Wie soll sie dem Kapitalmarkt erklären, dass die Bereichsleiter jeden Monat wechseln etc. Die Realität vorweg: Der Versuch einen "gray hair" CEO von IBM zu sich zu nehmen um den Börsengang vorzubereiten, endete in einer Entlassung desselbigen. Und Guidewire ist immer noch 100% Scrum, heute mit 500 Mitarbeiter und sehr kleinen Scrum-Teams mit 3-6 Leuten (pods genannt).

Und zm Schluss noch das PPT-Slide resp. eine die empirische "Hammerstudie" von John F. Helliwell and Haifang Huang, welche den IMD-Kunden wohl zu denken gibt: Well-Being and Trust in the Workplace [pdf, 152KB]. Darin wurde die Frage gestellt, wieviel die folgenden Faktoren der Arbeitszufriedenheit in % des Lohnes wert sind.

- Enough time to finish: 11%
- Using high skills: 19%
- Variety in your job: 21%
- Trust in management: 36%

Spannend! Und vielen Dank Stuart und Peter für die Organisation.

Gestern durfte ich am FASTforward Summit 2008 als Keynote direkt nach dem CTO von Fast, Bjørn Olstad sprechen. Im Programm hiess es trotz der langfristig zuvor abgestimten Agenda "Analyst on user and search". Nun ja ich bin kein Analyst aber Dienstleister und Search heisst bein mir auch eher "Find" oder um ganz korrekt zu sein "Information Retrieval". Und weil alles auf Englisch war, wechsle ich nun auch.

Enterprise information retrieval is complex, that we are tempted to tackle the project using a very structured approach… But contrary to many other ventures, the problem domain is tricky and the somewhat moving. Searchers learn while searching, results can be presented differently or some users know the collections and others don’t. The presentation proposes an agile approach based on Scrum to project success.

In my eyes, an agile approach is very well fitted to a retrieval project, because many parameters change in the course of the project by definition. This includes domain knowledge of searchers but also the data accessed.

Here you find the presentation: Can enterprise search profit from rugby? [pdf, 868KB]

An der kommenden Internet-Briefing Entwickler Konferenz 28.-29. Mai 08 in Zürich werden an zwei Tagen Vorträge zu folgendenden Themen gehalten:
- Projekte erfolgreich führen, nachhaltig entwickeln
- RIA: Next Generation Internet Webseiten

Im Themenbereich "Projekte erfolgreich führen" geht es neben LEAN und einem Vortrag von Google über Gmail auch um Scrum. Jean-Pierre König, Software Engineer wird der Frage "Wie funktioniert agile Software-Entwicklung?" nachgehen und dabei aufzeigen, wie eine agiles Team aussieht, wie man einen Sprint abwickelt und welche Tools man dazu einsetzt.

Den Vortrag "Wie funktioniert agile Software Entwicklung" kann mal als PDF hier runterladen.

This month we are honored to have a special guest to the Scrum Breakfast in Zürich: Stuart Read, Professor of Marketing at the IMD in Lausanne.

You already know Scrum. You have likely seen it at work. In this discussion, we will investigate a firm built completely on Scrum. Not only does the firm use Sprint teams for every function in the company, the firm has used Scrum since its founding day. I encourage you to review the case study so we can have a focused discussion on the issues around such a complete adoption of the methodology, especially as the firm expands beyond 500 employees.

Stuart Read is Professor of Marketing at IMD. He is currently developing cases and research in the following areas:

* New ventures and innovation
* Specifically investigating expertise in the entrepreneurial domain
* Marketing of innovations with network externalities
* Non-predictive strategies that enable managers to effectively make decisions in situations of true uncertainty

His academic credentials include a Ph.D. in marketing from the University of Washington and a Bachelor's degree in computer science from Harvard University. He has nearly 20 years of industry experience, having participated in the creation of six high technology start-up firms. Four of those firms were acquired by industry leaders including Sun Microsystems and Lotus Development Corporation. Two are publicly traded. Stuart also spent 6 years with enterprise database software provider, Oracle Corporation.

The Scrum Breakfast in Zürich is a monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO's, executive and operational project managers. The Scrum Breakfast takes place the first Wednesday of each month. The program starts with a short presentation about on an in interesting topic around Scrum. Then follows a moderated discussion among the participants to encourage an exchange of know-how and experiences.

The talk will be held in English.

Attendance is free and our sponsor namics provides the coffee, gipfeli (croissants) and orange juice.

Date: June 4, 2008
Time: 10:00 to 12:30 (Special Case!)
Location: namics ag, konradstrasse 12, 8005 zürich (map)

Registration for the Scrum Breakfast via xing or via comment (won't be published). If you wish to join us for lunch, please register separately at xing.

Heute spreche ich zusammen mit René Doldt von der Swisscanto Management AG am Swiss Intranet Summit über den Einsatz von SCRUM als Projektmethode für komplexe Intranetprojekte.

Titel: Effiziente Realisierung eines Intranets mit der agilen Projektmethode SCRUM

René stellt die Herausforderungen von Intranetprojekten vor und zeigt, warum sich eine agile Methode zum Management solcher Projekte gut eignet. Ich zeige danach die Entstehung und die wichtigsten Eigenschaften der SCRUM Methode auf. Gemeinsam beschreiben wir zum Abschluss, welche Erfahrungen wir mit dieser Methode bei der Entwicklung des Swisscanto Intranets gemacht haben und welche Anforderungen an die Organisation des Unternehmens gestellt werden.

Und hier gibt es die Präsentation:
Effiziente Realisierung eines Intranets mit der agilen Projektmethode SCRUM [pdf, 1 MB]

Scrum bringt Erfolg in der Projektabwicklung. Das haben die Scrum Breakfast Vorträge von Marcello Leonardi, Jiri Lundak und Patrick Weiss gezeigt. Aber warum? Und was hat Scrum mit dem Erfolg des Unternehmens zu tun? Die nächsten beiden Scrum Breakfasts bei der namics in Zürich widmen sich diesen spannenden Themen.

Am 7. Mai referiert Peter Stevens zum Thema: "Lean Software Development: der optimale Weg vom Konzept zum Cash"

Der Weg vom Konzept zum Cash kann lange und risikoreich sein. Verzögerungen, Fehlentscheidungen, Budgetprobleme, Kundenakzeptanz, schnellere oder grössere Konkurrenz... Die Aufzählung der Risiken scheint endlos und doch ist es möglich, erfolgreiche Produkte und Systeme zu entwickeln. Wie kann der Gesamtprojektleiter dafür sorgen, dass das Produkt bzw. das Projekt erfolgreich abgeschlossen wird, dass das Ergebnis einen positiven Return on Investment (ROI) produziert?

Toyota hat jene schlanke Produktion und daraus die schlanke Produktentwicklung erfunden, die sowohl für optimale Markt-Eignung (Fitness für Use) sorgt, wie auch für optimale Abläufe in der Entwicklung und in der Produktion. Diese Kombination von für den Markt geeigneten Produkten, tiefe Kosten und hohe Qualität ermöglichte Toyota den Aufstieg an die Spitze der Autoindustrie.

Dieser Vortrag schliesst den Kreis zwischen Agilität und Wettbewerbsfähigkeit auf der unternehmerischen Ebene mit Scrum und agile Software Entwicklung auf der operativen Ebene. Sie lernen, wie die Leitgedanken von Toyota mittels Scrum Ihre Agiliät und Wettbewerbsfähigkeit verbessern können.

Anschliessend gibt es Fragen, Diskussion und Erfahrungsaustausch unter den Teilnehmern. namics lädt Sie wie immer zu Kaffee und Gipfeli ein.

Datum: 7. Mai 2008 (immer der 1. Mittwoch des Monats)
Zeit: Türöffnung 8.00 bis 10.00, Vortrag 8.35 bis ca. 9.00
Ort: namics Zürich, Konradstrasse 12/14, 8005 Zürich (map)

Anmeldung: per xing.com Event.

Die ersten Scrum Breakfasts stehen unter dem Zeichen „ Erfahrungsberichte aus der Praxis". Im Februar, berichtet Marcello Leonardi, Scrummaster des namics-Projekts White Label Classifieds. WLC -- im Markt unter der Name Publisherconnect bekannt – welches die Basis von mehreren Rubrikenmarktplätz Plattformen ist. Prominente Beispiele sind NZZexecutive.ch, Publicjobs.ch, osthome.ch, pilote.ch und viele anderen. Marcello ist Teammitglied seit über 1 Jahr und seit ca. 6 Monate Scrummaster. Er berichtet über das Projekt, sowohl aus der Sicht des Entwicklers wie auch der des Scrummasters.

Themen:

* WLC Projekt Übersicht
* Einführung von Scrum im WLC Projekt
* Entwicklungs-Snapshot - Projektstand (Release 5.0) mangaged by Scrum
* Leasons Learned

Anschliessend gibt es Fragen, Diskussion und Erfahrungsaustausch unter den Teilnehmer. Ebenfalls lädt Sie namics wie immer zu Kaffee und Gipfeli ein.

Datum: 6. Februar 2008 (immer den 1. Mittwoch des Monats)
Zeit: Türöffnung 8.00 bis 10.00, Vortrag 8.35 bis ca. 9.00
Ort: namics zürich, konradstrass 12/14, 8005 zürich
2 minutes from Zürich HB near Tram stop Sihlquai/HB

Anmeldung per E-mail an mich oder lieber per Xing Event.

P.S. Für Ihre Agenda - Der nächste Scrum Breakfast findet am 5. März 2008 statt. Es geht um einen Langzeit-Erfahrungsbericht. Jiri Lundak, Sr. Projekt Leiter bei Löwenfels Partner AG in Luzern und einer der ersten Certified Scrum Master der Schweiz überhaupt, reflektiert über Scrum nach über 4 Jahren Erfahrung bei der Entwicklung von Lösungen für kantonale AHV-Ausgleichskassen.

Nach wie vor sind Vorschläge für zukünftige Anlässe sehr willkommen.

Remember the first time your son or daughter held a helium balloon in his hand? What happened? Sooner or later, that balloon got away and s/he was very unhappy, to say the least. One might even say, traumatized. Why? Because s/he lost the balloon? That's certainly part of the answer, but it's not the whole story -- kids lose things all the time, without the emotional trauma of that first balloon.

That balloon's flying away contradicted "years" of experimental evidence (generally obtained using food from the kitchen table) that things always fall down. Always. Dependably. Reliably. Certainly. Despite this certainty, that balloon fell up. The world is not in order. And that is what was so disturbing.

So you have just started using Scrum to manage your first development project. You have 6 months to complete the project. The remaining effort on your project is estimated to be 600 Story Points (SP), which means you have to complete 100 Story Points per month. So far, so good.

Then your team executes its first Sprint and completes 50 Story Points. At this rate, it will take 12 months to finish the project ( 600 SP / 50 SP per Month = 12 Months). So you tell your boss you have a problem, you're going to be 6 months late, on a six month project. What does you boss do?

• Kill the messenger (what else?)
• If that fails, blame the methodology (which is kind of the same thing).

Why is he reacting this way? For him, a balloon is falling up. Typically, early in a project, everyone is optimistic.Serious problems only become apparent later in the project, shortly before a major development milestone. So when a deadline problem escalates, it is serious and doesn't leave much room to maneuver.

BTW -- yes, I have had the pleasure of taking over a project in which the program manager had invested a large sum, only to be told shortly before the target date that it will cost another equally large sum to finish the project. Bad thing. No fun for anybody involved. And the program manager really only had two alternatives: Cough up the money or cancel the project. Either way, he had to explain it to his management (and is not going to look good in the process).

Come back to our Scrum example. Probably this program manager had never gotten such early warning that project was having problems. So how is he going to react? Exactly as he has been conditioned to through every other project that has been late, only more so, because if a warning occurs this early, something must be seriously wrong.

But wait! Only 1 month has gone by. The are still 5 months to go. You can react. You can identify the problem and make adjustments. Why is the development proceeding so slowly? Are there enough people? Are they the right people? Maybe you can reduce the scope and still achieve your business goals. Maybe your developers are being distracted by other tasks. There are a lot of ways to fix a project with over 80% of the time remaining.

Together with the Product Owner, the Scrum Master and other management can take action to correct the problem early and effectively.

Once management has learned that they have control, can react and can prevent disaster long before it occurs, they will no longer be tempted to kill the messenger. In fact, they will welcome the messenger and appreciate the methodology, because early warnings will ensure that management looks good when the project comes to a successful and timely conclusion.

Der Scrumbreakfast ist ein regelmässiges Treffen für CIOs, strategischen und operativen Projektleitern, die entweder Scrum einsezten oder Scrum einsetzen wollen.

Der erster Scrum Breakfast fand in November bei namics in Zürich statt. Wir waren 10 Teilnehmer, etwa 50/50 geteilt zwischen aktuellen Scrumnutzer und möchte gern Scrumnutzer. Nach einem (mehr oder minder kurzem) Vortrag haben wir dann auch untereinander Erfahrungen und Informationen rund um Scrum und SW-Projekte austauschen können.

Nächster Anlass:

Jean-Pierre König, Senior Software Engineer bei namics ag und Verfasser von Inside Scrum gibt uns eine Hands-On Einblick in Target Process. TP wird seit etwa 3/4 Jahr bei namics für die Verwaltung von agilen Projekte eingesetzt. Damit kann der Scrum-Master sämtliche Aufgaben rund um ein Scrumprojekt verwalten und Team-Mitglieder können ebenfalls ihre eigene Aufgaben im Projekt pflegen. Themen:

• Estimation
• Planning
• Daily Scrum

Anschliessend gibt es Fragen, Diskussion und Erfahrungsaustausch.

Wann: 05 Dec 2007, 08:00 am -- 10:00 am (Vortrag 8.35 bis 9.00)
Wo: City/Location Konradstrasse 12, 8005 Zürich
2 minutes from Zürich HB near Tram stop Sihlquai/HB

Anmeldung per E-mail an mich oder lieber per Xing Event

Wie letztes mal, werden Kaffee und Gipfeli von namics offeriert.

Call for Participation

Der Scrumbreakfast versteht sich als offenes Community. Auf Vorschläge für Vorträge, ins besonderem Case Studies oder Erfahrungsberichte würde ich mich sehr freuen.

Today, 10 Project Managers from companies around Switzerland in the finance, travel, and internet branches met at our office in Zürich to exchange information about Scrum.

The idea: we get together, listen to a short presentation, and above all, exchange information with each other about our experiences, problems and challenges in introducing Scrum into our companies.

The feedback was positive - all of the participant said they wanted to come back next month.

True to our motto of "inspect and improve", next time we will keep the presentation a bit shorter and leave more time for discussion.

I am putting together the plan for the next Breakfast - Mark you calendars for Wednesday, December 5, 8am to 10 am (presentation starts at 8.35, so you can arrive in Zürich HB in time to grab a coffee and croissant on your way into the meeting room).

If you have questions, a topic you'd like have discussed or want to hold a short talk yourself, please let me know....

You can download the slides from today's talk here (pdf).

Here it is. One sentence for management:

Scrum is Lean Production for Product Development.

I admit, this is an oversimplification, but it will get us started.

Looking at it more deeply, Scrum is...

- Getting things done – Before a task (a piece of functionality which is valuabe to the customer) is started, the Customer (through the “Product Owner”) and the Supplier (the “Team”) agree on clear goals to be achieved in a relatively short period of time. They also agree on the definition of "done". And the end of that period, the Product Owner verifies that the agreed functionality has been realized.

- Business Value (ROI) driven – The Product Owner prioritizes functionality according to Business Value. High value items are done first. Low value items are done later. The Product Owner may even decide that Low Value Items aren't worth the cost.

-Iterative, incremental progress – An iteration (or “Sprint”) has a short, fixed length. After each sprint, the customer inspects the status of work completed. Only work which is done may be presented to the customer.

-Fixed Time, Fixed Budget, Fixed Quality, Fixed Scope – The parameters for each iteration are defined in advance.

-Commitment driven – Product Owner and Team agree on Scope for each Sprint. Both take responsibility for the results.

-Taking what you can eat – The Team commits to all the functionality it can produce by the end of the Sprint, no more, no less. The pressure is moderate but sustainable.

-Transparent – At the end of the iteration, committed functionality must be done. This is examined and confirmed by the Product Owner. Along the way, the Project Leader ("Scrum-Master") verifies that Team members are on track and removes hindrances as they arise.

-Self-Improving – After each Sprint, the Team reviews how it works, identifies improvements, and agrees which one to implement.

-Self-Organizing – People actually responsible for doing work understand their work best. They are best able to plan and execute their work. (If you don't believe this, then come to a Scrum workshop. It's easy to demonstrate).

-Efficient – impediments to success are identified quickly so they can be eliminated quickly.

-Lean – The Team realizes functionality, the Product Owner manages the workload. Other interested parties (e.g. Management, Steering Committees, the Customer's customers, and other “Chickens”) are involved, but prevented from disrupting progress.

-Beautiful – Beauty is painful, but priceless. Ask anyone who's achieved it.

Some of you may have raised your eyebrows when you read "Scrum is fixed scope". Scrum is Agile, isn't it? But that's just the point.

To be precise, each Sprint is fixed scope. Under Scrum, we take a big complex project and deliver it in little slices. (Remember integrals in college?) Each slice is achievable. After each slice, the Product Owners measures the progress and verifies that the Project is on track. If not, s/he can apply corrective measures to be achieve the company's goals.

Yes, it can happen that a Sprint does not meet its goals. This is a warning - a canary in the coal mine - that the project is not moving forward as planned. It may be that the team was too ambitious and accepted too much, but it may also be that the project has taken on too much Scope or that the Scope is unrealistic.

Every month, Scrum gives the product owner the chance to adjust to reality. Change Scope, push a release forward or backward, increase planned time or budget, or remove other hindrances to progress. Of course if the project looks really hopeless, the Product Owner might reassign the team to a more promising project.

And this is what agility is all about - keeping the company in sync with reality.

P.S. There are still places open for our Scrumbreakfast on Wedensday... Sign up now!

This Wednesday, namics will hold its first "Scrum Breakfast" - a talk and information exchange between CIOs, Strategic and Operational Project Managers. Today, I'd like to give you peak at what you can expect from the talks.

I started managing my first project with Scrum for namics just over a year ago, and the improvements in productivity, quality and customer satisfaction were dramatic. As tool for managing individual projects, Scrum gave us control over the devil's cross of Scope, Quality, Time and Effort.

You will come if you have either adopted Scrum in your team, want your company to adopt Scrum or are considering Scrum. We are here today to share information and experience about Scrum in the Enterprise. Should a company adopt Scrum and if so, how?

To answer this question, we'll look at three issues:

• How to decide whether your company needs Scrum?
• What is Scrum and how is it different from traditional methodologies?
• How to get Scrum deployed in an organization?

Does your company need Scrum?

This real question is, 'does your company need a significant change?' Are you having problems with profitability, declining market share, inability to develop competitive new products? Are you being overtaken by the competition? Is your company's core IT infrastructure becoming unmaintainable (or is it already)? Are you considering offshoring to cut costs?

Does any of that apply to you?

Scrum is Lean Production for Product Development. Actually, it is more than that. It is applicable to any process which creates new information, like products, software, or business processes.

When you use Scrum, you can extract the full potential of your staff, identify and eliminate hindrances to success, and focus your resources on goals which produce the maximum business value.

If your company is happy with its current status, competitiveness, agility, cost structure, etc., then there is no need to adopt Scrum. But come anyway and help us with the coffee and croissants.

For the rest of you, watch this space. Tomorrow, I'll talk about what makes Scrum different from other methodologies.

For Wednesday, please let us know you're coming, and I look forward to meeting you then. BTW - the talk is in German.

Last week, I led a workshop on Scrum and Agile Project management at /ch/open's successful Workshop-Tage. 23 people, ranging from independent consultants to a complete software team from a well known insurance company, wanted to know how make their software teams 'agile'.

The press is filled with articles about how changing requirements and poor project management are responsible for delays, cost overruns and other problems in big projects. Despite this background, the big question at the workshop was:

How can we get our management or our customers to experiment with Scrum, given how deeply Waterfall-like methodologies are embedded in our corporate culture?'

A good place to start is the so-called 'elevator pitch,' the 30 second description of a product or service: Who needs it? Why? And how is it different (better) than what we did before? An elevator pitch is used to launch new products and companies, so why not launch a new idea in project management for your company?

The Scrum elevator pitch:

For CIO's and executive or operational project managers who want to achieve optimal results in the face of complex projects, and who must satisfy competing requirements for Cost, Time, Functionality and Quality, Scrum is an agile Project Management Framework which :

• emphasizes ROI, transparancy, respect, and working software, and
• defines simple playing rules which assure that all critical tasks and responsibilities are taken care of.

Unlike "Relay-Race" or "Waterfall" methodologies,

• under Scrum, teams incrementally design, implement and deliver finished functionality
• Scrum reacts to change, embraces change, incorporates change, and gives the project owner the tools to keep costs under control
• with Scrum, management can be confident of progress to the desired result on the desired date (or recognize early if plan and reality are diverging -- management can take corrective action)

If the press reports are true, then this should get your boss's attention -- I'm looking forward to hearing how it worked for you!

Heute habe ich die besondere Ehre, zusammen mit Jiri Lundak die HERMES-Group über Scrum zu orientieren.

HERMES ist das Projektleitungsmethodik des Bundes und ist (meines Wissens) Vorschrift für alle grössere Projekten des Bundes. Der Bund hat zwar HERMES ins Leben gerufen, aber heutzutag wird es in Zusammenarbeit zwischen den ISB und seinen Benutzer weiterentwickelt und weitergepflegt.

Jiri leitet die Entwicklung von Lösungen für die kantonale AHV-Kassen bei Loewenfels Partner AG. Seit 4 Jahren wird unter Scrum erfolgreich entwickelt.

Bei mir geht es darum, was ist Scrum und warum will man es einsetzten. Bei Jiri geht's um die Anhalts- und Konfliktpunkten zwischen Scrum und Hermes. (Ob es mehr Konflikt- oder Anhaltspunkten gibt werden wir ja sehen!)

Ich freue mich auf eine spanende Begegnung. Die Folien zu unseren Vorträgen befinden sich hier.

Heute war es meine Ehre, an die GV der Swiss Open System User Group (/ch/open) Scrum und Agile SW-Entwicklungsmethodik zu präsentieren.

Die /ch/open ist übrigens der ältester Verein im Bereich Open Source und Open Systems in der Schweiz. 2007 feiert er sein 25. Jubiläum und kann auf eine stolzer Vergangenheit zurückblicken, wo er u.a. Internet in der Schweiz eingeführt hat.

Ich trette nach 7 Jarhe Dienst aus dem Vorstand zurück. Zum Abschluss habe ich Scrum und Agile SW-Entwicklung präsentiert. Die Folien zum meinem Vortrag befinden sich hier .

Alles Gute und viel Erfolg für die Zukünft wünsche ich dem /ch/open!

Im November hielte ich eine Reihe von internen Workshops, um namics Leute ins Thematik einzuführen. Einen Vortrag haben wir auf Video aufgenommen und dieser ist jetzt auf dem Netz.

Was ist Scrum? Scrum ist eigentlich mehr Spielregeln als fixer Methodik. Scrum ist eine "agile" Projektleitungsmethodik. Es ist für komplexe bzw. Software- und Produkt-Entwicklungs-Projekte sehr geeignet. Ich vermutte, dass es sich sogar für Sanierung von grossen Projekten allgemein auch sehr geeignet ist, dafür möchte ich es noch ausprobieren.

Anhand von einfachen Beispielen (Wie baut man ein Schaukel? Wie fährt man von Neapel nach Amsterdam) erkläre ich warum Projektmanagment so schwierig ist. wie Scrum funktioniert, wie man Projekte plannt und durchführt, wie man auf Aenderungen reagiert und warum man reagieren muss.

Wie Schach, ist Scrum genüg einfach das man die Spielregeln sofort verstehen kann, aber auch genüg vielfältig, dass es sich anbietet um eine ganze Reihe von Herausforderungen zu meistern.

Zum Video selber - der wird nicht einfach als streaming Video veröffentlicht, sondern mit dem Powerpoint in einem Flash Datei integriert. Man kann leicht Kapiteln einführen, und die Powerpoint mitblättern lassen. Das Werkzeug dazu kommt von xtendx, die wir auch danken, dass Sie uns geholfen haben, unserer ersten XtendX Film zu produzieren und auch freundlicherweise das Video hostet.

Zum Anschauen: http://www.simplex.tv/xbend/simplex/34/266 - Enjoy!

Heute spreche ich beim Reto Hartinger's Internet Briefing. Jeweils am ersten Dienstag im Monat gibts um Mittagszeit einen kurzen Vortag über aktuelle, eher technisch orientierten Themen rund ums Internet.

Mein Thema: Was ist agile Software Entwicklung ist und wie ging die Einführung von Scrum bei unserem WLC-Projekt?

So wie ich Reto kenne, gibt's anschliessend eine spannende Diskussion über die Risiken und Nebenwirklungen sowie Vergleiche und Abgrenzungen zu andere Entwicklungs-Methoden.

Die Folien in zwei Formaten Adobe Acrobat und PowerPoint
- Agile Software Entwicklung mit Scrum [pdf, 1,7MB]
- Agile Software Entwicklung mit Scrum [ppt, 2,1MB]

Ich habe ab und zu über die Schwierigkeiten in der Projektleitung geschrieben. Vor 3 Monate durfte ich die Leitung von einem anspruchsvollen Projekt übernehmen. Dabei haben wir die so genannte "agilen" Methodik Scrum eingeführt, um wichtige Probleme bezüglich Software-Qualität, Termintreue und Kundenzufriedenheit zu lösen.

Die Ergebnisse lassen sich schon jetzt zeigen. Dieser Blog ist jedoch nicht der richtige Ort, um über Kundenprojekte zu sprechen. Darum nutze ich die Gelegenheit, euch zu einem Tech Talk bei Reto Hartinger's Internet Briefing Group einzuladen. Am ersten Dienstag in Februar werde ich um die Mittagszeit einen kurzen Vortag halten, was agile Software Entwicklung ist und wie wir sie in diesem Projekt eingeführt haben.

So wie ich Reto kenne, gibt's anschliessend eine spannende Diskussion über die Risiken und Nebenwirklungen sowie Vergleiche und Abgrenzungen zu andere Entwicklungs-Methoden.

> Datum: 6. Feb. 2007
> Wann: 11.30-14.00 Uhr mit gemeinsamen Essen
> Ort: Zunfthaus zur Schmiden, Marktgasse 20, Zürich

Anmeldung und weitere Informationen unter http://www.internet-briefing.ch/index.cfm?page=101498&anlass_id=56

Tomorrow I will be giving a talk on Scrum for namics - what it is and how it works, experiences from our first Scrum projects, and why we should be using it more. (Which explains why I have working on the slides since 6:00am this morning).

In the course of my preparations, I found a blog by Steve Yegge — Good Agile, Bad Agile — in which he talks a lot about the virtues and pit-falls of Agile Programming.

Along the way, he tells us a lot about life at Google and how they develop software (outsiders find it difficult to believe that they can produce anything). And buried deep in the middle of his story, I found this little gem:

Incidentally, Google is a polite company, so there's no yelling, nor wailing and gnashing of teeth, nor escalation and finger-pointing, nor any of the artifacts produced at companies where senior management yells a lot. Hobbes tells us that organizations reflect their leaders; we all know that. The folks up top at Google are polite, hence so is everyone else.

All in all, a very interesting read. Google strikes me as a pretty "agile" place (at least if Steve's descriptions are correct), regardless of what they call it.

Innovation needs a constructive atmosphere, and I think respect and politeness are necessary pre-conditions (not sufficient conditions, but necessary ones). Which is one reason why I teach them to my kids.

Agile is at least as much about values as about methodology. Which is why I think it will be good for our customers and will fit well with namics.

For a long time, I thought project management was a pretty worthless science. At worst, it was a line item on the invoice with no clear deliverables. At best, it seemed focussed on producing mountains of paper which no-one ever read; what little software it produced was bloated, overweight, over-budget and behind schedule. Good for big companies and huge projects, but over-dimensioned for the rest of us.

Okay, I’m being a bit global in my accusations, but let’s be honest: How many software development projects come in on-time, on-budget, and with functions that the users really want? (How much of, say, Microsoft Office do you know how to use? I rest my case.)

In the course of the last year I have been increasingly interested in so-called Agile methodologies: Scrum for project management and Extreme Programming (“XP”), the corresponding engineering discipline. For me, it clicked. These are methodologies that focus on producing working software, give the user what s/he wants, and produce a positive return on investment (ROI) for the company investing in the software.

How does it work? Simple. Define the product in terms the user understands: what s/he can do with the software and why. Together with the team, define the milestone (something that can be demonstrated) and implement it within one month (don’t change the goal at all during that month). Demo the result. Get feedback, adjust your plan if necessary, and repeat until ready to ship.

Why is this better? Under classical project management, the development team works like a taxi fleet. Although centralized planning tries to optimize utilization, each taxi is ordered and dispatched individually. If a taxi gets lost, runs late, or changes destinations, this has consequences. While these tend to be cumulative in their effect, aside from the overall project running late and over budget, it is hard to know exactly what went wrong.

Under Scrum, the development process is like a scheduled freight train. The train departs every hour and arrives 50 minutes later. One person (the Product Owner) decides what gets on the train. One person (the Scrummaster) is responsible for keeping the train on track. The team runs the train. If the train is delayed, everybody waits and everybody is aware of the problem. Once the train has departed, nothing else can get on and the train drives on to its planned destination.

After an hour, everybody knows where the train is. Since the schedule is important, no one is allowed to change the destination en route. Changes can be made, but only when the train is in the station (except in emergencies, of course), and only under the direction of the Product Owner.

Scrum operates through simple rules that can be applied to complex situations. It’s easily understandable. Progress is easily measurable (I graph progress and change in scope every iteration). Most important, the playing rules prevent the bad things which cause projects to go astray.

Technorati Profile