Waterfall Model in Agile Sizes

I am a big fan of agile methodologies at all – if done right. Therefore, in my lectures, I teach about the big misunderstandings of the waterfall model, which never was told as such by Winston W. Royce in his paper “Managing the Development of Large Software Systems”. Actually, in his original paper, he described the error-prone approach he observed at this time.

“I believe in this concept, but the implementation described above is risky and invites failure”

Eventually, Bell & Thayer called this process Waterfall the first time in their paper ”Software requirements: Are they really a problem?”. 10 years later it became a standard in the Department of Defense Standard 2167A (DOD-STD-2167A).

When reading Royce’s paper carefully you will find a lot of recommendations pointing to nowadays agile practices such as iterative development, talking to the customer, performing reviews and even DevOps approaches as the fact software should be run by those who write it. All these things mentioned by Royce are never mentioned when talking about the waterfall.

But then again, when talking about agile you probably will realize, that it is nothing else than “Waterfall” just in small sizes as illustrated by @JishuaKerievsky:

Royce’s original paper: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
Paper by Bell and Thayer: https://pdfs.semanticscholar.org/a50d/8f564d063e526e94114875220440f64d8666.pdf

Feedback Loops in Scrum the Other Way Around

Scrum in ActionUser Stories are the way a non-technical product owner can communicate with the technical team. It is probably the best way any product owner can tell the technicians what he or she actually wants. A the same time it is the best point to pick up technical requirements, limitations and pitfalls related to your requirements. Therefore, take this opportunity and listen carefully. The feedback loop is not only top down, it’s bottom up as well, you just have to use it.

A difference maybe not realized yet

The difference in Scrum related to many other development processes is the rapid feedback you might get during backlog grooming or estimation meetings. Developers will moan about the stories, complain about requirements and tell you more often than not, these particular wishes might be very expensive or even not possible to achieve at all…

Take Action

Even this might be exaggerated, listen because here you get feedback from the folks knowing the software best. Change requirements on the stories, modify the scope, prioritize impossible features down. Nobody else does understand the overall system that well. Non of your architects, managers or analysts understand the system that way.

No means Maybe Later

No does not mean no by definition. If you come up with a story, developers think its impossible, it’s actually not. Stop fighting for the story. Take it, go back to the drawing board and refine or start over. No simply means it too expensive. Always remember: We are talking about technology here. probably everything is possible. It is simply a questions about how much effort one (in this case the product owner) is willing to put into it. If developers say no, they come up with a natural instinct which tells them it simply not feasible under the current circumstances. Always remember, SCRUM is about performing on the very best level under a certain set of circumstances and limitations at a very specific point in time.


As a product owner make use of estimation meetings and/or backlog groomings. Go over stories again an again and pick up the feedback from your developers. With every meeting you will get better feedback more details and better estimations. Take this opportunity receiving rapid feedback from the developers. There is easier way to get this feedback, though.

The Role of an Architect in Scrum

Over the last few days I (re-)thought a lot of the role of an architect in a Scrum team. I tried to avoid to read about other opinions and just thought of my very own experience over the last few years in agile teams.

There should be an architect in your organization, however, he should not be part of the Scrum team itself. Scrum is about the development process in your organization or project and as such is it a required constraint for the architecture to develop.

The architect deals with non technical issues, so called facts of life, politics, organizational constraints, budget restrictions and so on. No team member could address thees in the regular development sprints.

As an architect one should analysis and manage risks – again nothing a team member could do during a regular two or four week sprint. Considering risks probably begins long before the team is Assembled and t he project is started. In fact, as an architect one could even point out the project might not doable due to various reasons.

An architect has to run in iterative cycles as constraints change, customers come up with new and modified requirements and organizational goals mit shift over time. All this might require some redesign or evolution of the architecture. However, these architectural cycles are not bound to the development cycles of e team. They are more related to the business, customers and organization.

The architect is a technical leader. Maybe by prototypes or bullet tracing he shows how hard parts of the system can or will be addressed. As such he provides a base to the team to better estimate the complexity of the upcoming implementation. Eventually, as architect it is important to address the hardest issues first whiled the Scrum team addresses the tasks with the highest business value first.

As an architect you teach and coach your team. In Martin Fowler's article Who Needs an Architect?, published in IEEE Software, Fowler points out, that an good architect mentors his team, not sitting in his ebony tower.

Dealing with uncertainty is probably one of the most underestimated aspects of the dayjob of an architect. In the role of an architect, I have to make decisions under a high degree of uncertainty. As many aspects of a project change over time, early decisions are uncertain. However, as an architect, you have to consider the consequences of these decisions. It's a major part of your job to consider risks and work on plans wether any event occures that affects your project both, a a threat or a chance.

I contrast, in the role of an developer, you should not be confronted with uncertainty. You have a tough schedule and proper tasks to fulfill, Technologie and tools are in place and in the best case you have all the knowledge to perfomreyou task. If the requirements for your task are not clear, you probably cannot fulfill it.

I have experienced this very issue during the last few years several times. Most of the time this was caused by the lack of an architect or the position of the architect was not dealing with the role of the architect in a proper way, most of the time writing code themselfs.

Therefore, do architects write code? This might be one of the most discussed topics for software engineering. Personally, I have experienced both, architects writing (productive) code all the time a well as architects never worked in product development. As an architect you probably should provide certain coding skills. Earning your street cred before becoming an architect is inevitable. You must be able to read, understand and improve the code. However, you have to delegate the actual task of building the code base to others. Nevertheless, you probably have to improve your coding skills permanently. Therefore, an erchitect must be able to write excellent code, however he should not write the bits delivers despite prototypes and tracer bullets.

As a fact, running an agile environment does not supersede an architect. Neither does it reduntize the overall product planing and designing process. The architect is not part of the Scrum team as he does not deliver within the Scrum team. He is in a position existing before the Scrum team is assembled, he leads the direction and can hold an consulting position for the team. However, the a architect is not part of the sprint plan and as he is not part of the Scrum team as such.

Teamwork in Scrum

ScrumMaster Logo SealSome aspect attracting my attention since my very first Scrum training is the fact how a Team actually handles team work.

In a conventional software development team you probably find a bunch of hierarchical organized group members including managers, an architect, engineers and developers. While the architect figures out what to do with respect to the managers needs, the engineers define how to do it and de developers eventually do whatever the hierarchical organization above has defined.

In a Scrum Team, the Team is told what to do directly by the ProductOwner in form of stories. Consequently, what to do, how to do it and the act of doing it is completely within the responsibility of the Team. In the conventional approach, each level could blame the level above in case of a failure. The developers blame the engineers for insufficient definitions, the engineers blame the architect for a faulty architecture or misleading bullet tracing and the architect might blame the managers due to a strict budgeting, too much pressure and so on. Of course each manager might blame his manager in turn and so on.

So, how do we end up in a team effect? I have seen teams where each developer picks a story from the task board, teams where each developer had his/her own area of stories (server, client, user interface etc.) and teams where the overall team works at one story at once. Boris Gloger, holds the view the entire Team (of developers) works on the same story. I am not absolutely sure yet,  how this works in larger teams (5+ developers) with small stories, however in theory, if a story is done by the hole team it succeeds as team.

If each developer works on a separate story, I recall a passage from the latest book of Robert C. Martin, talking about who breaks the code will own it. What’s the logical implication of this? If a developer breaks code he might get blamed by other team members. That’s the quick death to a team. If the team separates in smaller groups which maybe blame this developer, this might be an even quicker detach to the team. If the blaming happens in front of the ProductOwner, this might fundamentally harm the overall Scrum Team, in particular the Team – ProductOwner relationship. Suspiciousness, maybe shorter sprint duration and additional tension within the whole Scrum Team might be the result. The very best ScrumMaster will have a hard time undoing this. Considering the fact that a really good team might take up six to twelve moths to form up, blaming should be avoided at all circumstances.

So what’s the right attitude in this case? If something goes wrong, a story is not fully implemented, code is broken, previous functionality is lost or whatever goes to the dogs, the whole team should stand up, work together to fix this issue as quick as possible without caring who introduced it. Of course the team should perform a root cause analysis what exactly happened, however, as it should be done in retrospectives, the topic should not be what went wrong and who’s fault it was. Instead it should be about how to avoid such a issue in the future. That way its all about improvements and that’s what Scrum is about at the very end.

Kaizen und Personal Kanban

Als frischgebackener ScrumMaster, habe ich mir einen Rat aus dem zugrundeliegenden Training bei Boris Gloger zu Herzen genommen: Scrum als Einstellung zu verstehen, jeden Tag etwas zu verbessern. Mehr als jeden anderen im Team betrifft das den ScrumMaster, denn letztendlich ist er dafür verantwortlich dem Team die Impediments aus dem Weg zu räumen. Ein ScrumMaster sollte also mit gutem Beispiel vorangehen und nicht nur sein Team sondern auch sich selbst ständig verbessern.

Von MIT und WIP

Personal KanbanViele Baustellen schaffen natürlich viel Verwirrung, daher habe ich im Sinne von Kaizen damit begonnen schrittweise Verbesserungen einzuführen. Ein erster Schritt ist dabei die Einführung von Personal Kanban. Während des Scrum-Trainings wurde ich als “Coach” zum Thema Konsequenz durch einen Mitteilnehmer ausgewählt. Dabei habe ich unter anderem kurz den “Most Important Task”-Ansatz von Leo Babuta angerissen, die drei (oder auch fünf) wichtigsten Aufgaben (MIT) jeden Tag in Form eines Post-It-Zettels zu visualisieren und nacheinander abzuarbeiten. Der ausschlaggebende Punkt, ist die Auswahl der drei wichtigsten Aufgaben und der dadurch generierte Fokus darauf. Ähnlich ist der Ansatz im Personal Kanban. Durch die Festlegung der WIP (Work-In-Progress-Artefakte) wird der Fokus verlagert. Weg von der “erdrückenden” Liste an zu erledigenden Dinge, hin zu der überschaubaren Liste an Aufgaben, die tatsächlich erledigt werden. Da ich den MIT-Ansatz bereits seit langer Zeit verfolge, fällt mir die Implementierung von Personal Kanban nicht sonderlich schwer. Gleichgültig, ob “Most Important Task” oder “Work In Progress”: Beide Ansätze unterscheiden sich zunächst nicht sonderlich. Was in The Power of Less als Goal bezeichnet wird, kann in Personal Kanban als langfristige Aufgabe (z.B. Jahresprojekt) in einem eigens hierfür gedachten Abschnitt geführt werden. Die Gestaltungsspielräume in Personal Kanban sind dabei jedem einzelnen überlassen.

Der erste Value Stream

Die erste Implementierung meines Personal Kanban umfasst daher zunächst die drei “Standardspalten” Backlog, WIP und Done. Die Verfeinerung entsteht im Laufe der Zeit während man sich selbst über den eigenen Value Stream im klaren wird. Ein komplexeres Schema eines Value Streams bereits zu Beginn einzuführen erfordert ein höheres Maß an Konsequenz dies umzusetzen und erhöht somit das Risiko, dass das Unterfangen scheitert. Der einfache Value Stream stellt sicher, dass bereits am Ender der ersten Woche zumindest einige Tasks in der Done-Spalte ein subjektiv gutes Gefühl vermitteln. Hierin besteht auch der größte Unterschied im Umgang MITs. Die Visualisierung der erledigten Aufgaben dürfte ein entscheidender Motivationsfaktor sein um den Ansatz konsequent weiterzuführen.

Von Lazy Lists zum Backlog – Der Erweiterte Value Stream

199 Taks zu vielDer nächste Schritt und eines der ersten Items im Backlog besteht darin, sämtliche “Lazy Lists” abzuschaffen. Vor ungefähr einem Jahr hatte ich den Versuch gewagt, meine Aufgaben von Microsoft Outlook nach Remember The Milk (RTM) zu migrieren und ab da an in RTM zu verwalten. Grund hierfür war die erdrückende Anzahl von Tasks, der Mangel an einer Priorisierung von Tasks und die konsequente Umsetzung von Inbox Zero.  Wie alle Lazy Lists, neigen jedoch auch die Listen in RTM dazu, schneller anzuwachsen als sie abgearbeitet werden können. Dies führt unweigerlich dazu, dass vor allem die Aufgaben am Ende der Listen lange Zeit unbeachtet bleiben. Sowohl in The Power of Less als auch in Personal Kanban wird propagiert, nur eine Liste mit allen Aufgaben zu pflegen und somit Anzahl der Eingangsfächer zu minimieren. Während die Visualisierung mittels eines Whiteboards in Personal Kanban die bevorzugte Lösung darstellt, möchte ich jedoch nicht auf die Möglichkeit verzichten, auch von unterwegs neue Items in das Backlog einzutragen.  Hier habe ich mich entschieden mein Value Stream durch ein vorgelagerten Schritt zu erweitern. RTM sowohl auf dem iPhone als auch im Web bleibt die Lösung um spontane Einfälle oder aktuelle Aufgaben zu erfassen.  Regelmäßig, im besten Fall jeden Tag, werden diese Aufgaben in den Backlog des Personal Kanban übertragen. Hier kommt der gleiche Effekt zum tragen, der auch bei Zero Inbox ausschlaggebend ist und weswegen im ersten Schritt zu Zero Inbox alle Items aus der Inbox gelöscht oder archiviert werden. Eine Liste mit drei Einträgen auf Null zu bringen ist wesentlich leichter als eine mit 200 oder gar 1.000 Einträgen.

Von Digital zu Physisch

Während meiner Recherche zu Personal Kanban bin ich auf verschiedene Anwendungen (Desktop und Web) gestoßen, mit denen sich ein Personal Kanban einrichten lässt. Die bewusste Entscheidung gegen ein digitales Personal Kanban ist mit der vorangehenden Abschaffung von Lazy Lists begründet. Ein physisches Whiteboard hat schlicht und ergreifend einen begrenzten Platz für Backlog-Items. Das Backlog kann schon aus diesem Grund nicht uneingeschränkt anwachsen. Und auch hier lässt sich zum Abschluss eine Analogie zu Scrum zu herstellen. Während die Menge an User Stories überschaubar ist (in der Regel um die 60), wachsen Bug-Listen oder Listen in Ticketsystemen schnell ins Absurde (mit hunderten oder gar tausenden Einträgen).


Die Umstellung von einem reinen MIT-Ansatz zu Personal Kanban stellt einen nicht allzu großen Schritt dar, sofern man bereits seit einiger Zeit mit MITs gearbeitet hat. Der Hauptunterschied liegt meines Erachtens in einer nachhaltigeren Visualisierung der erledigten Aufgaben und der Priorisierung der Backlog-Items während die Grundprinzipien einer einzelnen Inbox für Aufgaben und einer überschaubaren Menge an abzuarbeitenden Aufgaben vom Grundprinzip ähneln.

Microsoft eScrum 1.0

In case you missed Microsoft eScrum:

“eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help.”