The first time I received some Scrum courses was around 2008. I remember thinking at that time “these new ideas will never work”. Only much later, in 2015, I was fortunate enough to have a brilliant Agile Coach at my side. I was working as a Product Owner back then and didn’t have any clue about Scrum. He helped tremendously that those “new ideas” finally began to sink in. Subsequently I began to dig a bit deeper and found out that many of the ideas indeed were not that new. …

Question: Why are so many agile transformations (or Scrum implementations for that matter) seemingly going nowhere? No doubt, Scrum is a framework that enables empiricism and fosters communication — if done right. But, in many organizations, Scrum is in essence a mechanism supposed to deal with long lists of work. In other words: organizations are mainly concerned with improving their delivery speed. At the same time they keep their old decision structures — eloquently explained by Craig Larman’s Laws Of organizational behaviour.

But the most important question will always be “what to build”. The framework itself doesn’t have an answer for that. …

Serious Scrum Header
Serious Scrum Header

“You keep using that word. I do not think it means what you think it means.”

One of the most common anti-patterns in software development is what Jeff Patton aptly names the „customer-vendor-problem“. In essence, this pattern is characterized by a clear separation between the Customer who wants something and the Vendor who is paid to deliver it within the agreed parameters of cost, time and quality. How are these parameters usually agreed upon? Yes, by estimations. In this construct we face multiple problems, as detailed in this great article by Ron Jeffries.

But to me the biggest obstacle is that both sides often have an inherent ambition to „win“ this game: The customer client wants to get as much “bang for the buck” as possible, and the vendor wants to get as much paid as possible for the delivery. Now, we all know this works nowhere outside of Powerpoint country. The neverending cycle of require->estimate->negotiate->order->deliver typically leads to cutting corners, high pressure and exchange of arguments like: „This is not what I wanted“ — „But this is what you specified“. …

Is Baseball the most “agile” sport on the planet?

Sport, especially Teamsport has always made a great, if obvious metaphor for teamwork: A common goal unites a bunch of people organized in teams which compete to win. Teams make decisions, communicate, manage conflict and solve problems (ideally in a supportive and trusting atmosphere) in order to accomplish their objectives. I imagine Hirotaka Takeuchi and Ikujiro Nonaka had something similar in mind when they were coining the now-famed “moving the Scrum downfield” phrase in their New New Product Development Game.

Image for post
Image for post
Photo by Wade Austin Ellis on Unsplash

My kids play baseball. I know, an unusual choice for kids in Germany (sincere apologies to American readers, I freely admit that it’s much less competitive here). Anyway, after living for seven-plus years with the sport I found some astounding analogies between Scrum and baseball, much more than in any other sport I have seen. …

Everybody likes it tidy — nobody likes to tidy up. Here’s what you can do.

What may be the worst part in organizing requirements with those modern digital helpers? The fact that disorder, overflow and being overwhelmed is invisible from the outside. Remember the time when cameras could take 36 pictures and album capacity was limited? I’m not saying this was paradise but at least we were forced to consider with which items we wanted to fill the void.

Today, digital storage is cheap, so we tend to continuously stuff User Stories, Tasks, Sagas, Defects and Test Sets into our Product Backlogs regardless of delivery capacity — a deceptive easiness that at some point in the future will inevitably lead to near-paralysis in the face of a seemingly unsurmountable pile of work. …

A few musings on how to spot the agile thinkers you need

Lately I have read a tweet that was really harsh on agile, especially on the certificates and certifications. Basically the person was asking how it could be that after a 3-day-training and a 60-minutes multiple-choice Test someone was allowed to call himself Scrum Master (and/or Agile Coach), whereas he himself needed a 6 month special course in project management plus one whole day of exams for his degree. I sensed deep frustration there. Obviously he felt cheated. Now, while I get it that there is no absolute or direct connection between time and money spent and the value of a degree he still made me think. …

On life with traditional meetings in agile times

In an ideal world the Scrum Events provide transparency on your project (or product, for that matter). Basically that’s the whole idea behind Scrum: solving the need for information of various stakeholders easily: interested people have the chance to track progress by visiting the sprint reviews. If you want to know what’s hindering, well, just visit a daily (as long as you’re not hijacking the discussion, that is). And planning gives a good impression on what we are trying to achieve within our respective timeframe. …


Daniel Westermayr

Agile Coach & Scrum Master, Kanban Coach & Professional Product Owner, Usability Engineer & UX Enthusiast

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store