Help! I’m Trapped in a Waterfall!

In an organization, the two levels most likely to be willing to adopt Scrum are probably the very top and the very bottom.

Top management is driven by sales figures, market share, financial results and other performance indicators. They (should) know how the company is doing and feel the heat if it is not doing well. In extreme cases, pressure will transcend corporate politics, forcing even dramatic change for the good of the company. If top management is feeling the heat, then it will be open to change and see Scrum as a source of salvation.

The operational level is trying to actually accomplish work, create and sell product, satisfy customer requirements. These people are confronted daily with the impediments preventing the company from succeeding.

What do you do if you have operational responsibility for some area, want to improve, want to adopt Scrum, but you are not able to change the entire organization?

Operational teams can decide to use Scrum to improve their own efficiency, even without active support from top management. How to introduce Scrum Bottom-Up:

  • Learn how to do Scrum properly. Read about it, get certified, get a coach or mentor. Scrum done wrong can be worse than no Scrum at all.
  • Recognize that your deliverables and commitments to the rest of the organization won’t change because you use scrum. Just deliver what they ask for.
  • Get support of your immediate management. Explain what his advantages are. The support of middle management is essential to get budget for courses and coaching.
  • Explain to your customer what you are going to change, what his advantages are, and what his role is.
  • Start „Sprinting“. Define the roles (Scrummaster, Product Owner and Team) and make sure everyone knows their responsibilities.
  • Be true to Scrum. Don’t change it except to satisfy an external requirement (say to deliver a functional specification or delivery timetable).
  • Don’t try to change other parts of the organization (yet). Identify impediments as they arise and find solutions together with the concerned teams. Negotiate changes which make the organization more agile.
  • Identify a member of top management who „feels the heat.“ Get him involved.
  • The success of your project will motivate him to implement Scrum top-down.

Top Management can recognize Scrum’s potential as an agent for change and organizing principle for their company. They can achieve substantial improvements in quality, time to market and cost control. Agility and flexibility benefit. Competitive advantage results. How to introduce Scrum top-down:

  • Learn how to do Scrum properly. Read about it, take a course, get certified, get a coach. Scrum done wrong can be worse than no Scrum at all.
  • Identify a pilot project to use Scrum.
  • Ensure they know how to do Scrum properly. Get them certified, get them an experienced coach/mentor. Get them started on sprinting.
  • Once the success of the pilot project is clear, decide to use Scrum in the organization.
  • Plan and execute the roll out and deployment of Scrum using Scrum.

Actually planning and rolling out Scrum in a large organization is big topic, something for another day.

Next month

What should we talk about next month? I have several topics in mind –
Bottom up: Getting started with Scrum. Planning and executing the first Sprint. Setting up and prioritizing the Product Backlog. Using tools to manage
Top Down: Organizing large projects. Planning and rolling out Scrum across multiple teams. Synchronizing work across teams. Scrum of Scrums, Enterprise transition teams, Scrum Rollout teams.
Using Scrum as a subcontractor. What to do when you are one of several companies delivering a solution and your part is but a step in the waterfall?
Daily Business – Managing your project with Target Process.

What has the most value for you….?

Scrum Breakfast / Scrum Community

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).

Scrum for Managers: What is it. How is it different?

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!

Scrum in the Enterprise

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.

Scrum elevator pitch

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!

Scrum bei der Hermes Arbeitsgruppe

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.

Botschaft an den CEO: Scrum und XP sind für Euch

Über die letzte paar Monate habe ich diverse Beiträge über Scrum veröffentlicht, aber noch nicht so richtig in Text-Form erklärt, was Scrum eigentlicht ist und warum man es braucht.

Mein namics-Kollege Jean-Pierre König, hat neulich einen Blog zum Thema Scrum gestartet und hat auch eine Reihe von Artikeln als Gast-Blogger über Scrum verfasste: Was ist Scrum, wie funktioniert Scrum und warum sollte man Scrum einsetzen?

Dies hat mich motiviert, wieder mehr über Scrum zu schreiben. Mit den nächsten paar Einträge möchte ich auch diese Themen aus der Perspektive vom Management beleuchten, warum Scrum und XP von strategischer Bedeutung sind.

Die Herausforderung, komplexe System zu bauen

Jeder Projektleiter wird mit dem Teufelsquadrant konfrontiert. 4 Parametern: Qualität und Funktionalität (also Umfang) sowie Termine und Preise (bzw. Aufwand). Es gilt die ersten 2 zu maximieren und die anderen zu minimieren. Je grosser das Projekt, um so mehr trägt der Projektleiter die Verantwortung, ja geht sogar persönlichen Risken ein.

Geht das Projekt schief, werden nicht nur Ressourcen vergeudet, sondern das menschliche leidet sehr stark, ja der Ruf des Projektleiters oder gar die beteiligten Firmen hängen davon ab, ob das Projekt erfolgreich wird oder nicht. Im Fall des Supergaus wollen Auftraggeber und -Nehmer gar nicht miteinander reden. Das Zwischen-Menschliche wird zum Hinderniss — als erstes muss man den Vertrauensbasis wieder herstellen.

Und troztdem, die Studien zu folge, ca 50% aller Projekten haben Probleme mit den Teufelsquadrant. Auch bei den erfolgreichen Projekte, werde 2/3. der entwickelten Funktionalität selten bis gar nicht benutzt.

Also grob geschätzt, 2/3 des investierten Aufwands hätten gesparrt werden können.

Warum wird so viel unnötige Funktionalität produziert? Das hat mehrere Grunde:

  • Kunden werden regelrecht erzogen, dass Funktionalität, die man fruh im Projekt spezifiziert, günstig ist, bzw. dass Aenderungen teuer sind.
  • Change happens – also Aenderung kommen, und die eingesetzen Methoden werden schwer heraugefordert, bei den Aenderungen mitzuhalten.
  • Es ist schwierig herauszufinden, was die Kunden bzw. Benutzer wirklich wollen und brauchen.
  • Software rapide und flexible zu entwickeln braucht entsprechende Engineering Practice und Technologie.

Ohne diese Methodik und Infrastruktur sind Aenderungen doch teuer, also doch lieber zu viel specifizieren als zu wenig. Aber das muss nicht sein.

Scrum stellt ROI im Vordergrund. Man entwickelt nur weiter, wenn es dem Geschäft tatsächlich mehr dient als es ihm kostet.

Scrum vermeidet eine über-Verplannung sowie die frühseitige Verpflichtung auf Funktionen, die evtl. gar nicht nötig sind. Man arbeitet an Sache, die von hoher Priorität sind und eindeutig sind, und wartet auf Abklärungen, Verhandlungen und Vereinfachungen von Sachen, die kompliziert oder nicht eindeutig sind.

Scrum vermeidet ein Mikro-Management der Arbeit und definiert wenige Instrumente, schreibt aber den Arbeitsablauf und Spielregeln genau vor.

Die Arbeit wird in so genannten „Sprints“ oder Arbeitseinheiten von 2 – 4 Wochen aufgeteilt. Nach jedem Arbeitstakt soll eine für die Business-Einheit nützliche Funktionalität produziert werden, welche produktiv eingesetzt werden könnte.

Die Hauptvorteile dieser Methodik liegen darin, dass:

  • nach einer ersten Aufbauphase ist man nie mehr als 30 Tage von einer potenziell einsetzbaren Version entfernt: ein Gesamtversagen ist fast ausgeschlossen.
  • Jeder Arbeitsschritt hat einen positiven ROI: Funktionalität, welche eingesetzt werden könnte.
  • Team und Auftraggeber sind bestens positioniert, um auf neue Informationen sowie ändernde Prioritäten und funktionale Änderungen zu reagieren. Probleme werden rasch erkannt und ausgeräumt.

Grundsätzlich gilt bei dieser Rythmus: Plan -> Do -> Demo -> Improve.

Die Planung erfolgt in gegenseitigem Einverständnis vom Kunden bzw Produkt-Owner und das Team. Allfällige unterschiede zwischen Wünsch und Realität werden hier beseitigt. Nachher kann man „in Ruhe“ arbeiten. An den Auftrag wird nichts mehr geändert, bevor der nächsten Sprint startet. (Da der Sprint nicht zu lang ist, hat man den Auftrag auch nicht vergessen oder modifiziert). Dann wird vorgeführt.

So verbessern sich die Termin-Treue, die Spezifikationstreue und der Vertrauensbasis.

Ein besondere Eigenschaft von Scrum ist das institutionaliserte Scrum-Retrospective. Nach jedem Sprint treffen sich Team und Scrum-Leiter und fragen sich:

  • was haben wir erreicht?
  • was war gut?
  • was war verbesserungswürdig?
  • was soll unternommen werden?

Als Scrum-Leiter kann ich bestätigen, dass diese Sitzung für den Scrum-Leiter sehr unangenehm sein kann. Aber Transparenz ist wie Schönheit, schmerzhaft, aber erstrebenswert). So entwickeln sich die Prozessen, zwar inkrementell, aber konstant. Uber Monate und Jahren kann das zu erheblich positive Wirkungen auf die Produktivität führen.

Nächster Beitrag – warum funktioniert Scrum und wer setzt es ein?

Präsentation Agile SW-Entwicklung bei /ch/open

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!

Scrum Einführung auf Video, oder der Beste Weg von Neapel nach Amsterdam

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!

Agile Software-Entwickung

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]