Peter Gfader's brain noise
Do you hold “Retrospectives” or do you seek “Continuous Improvement”? #DoingVSBeing #Agile
Do you do “TDD” or do you “Build the right thing”? #DoingVSBeing #Agile
"All existing revision control systems (incl TFS) were built by people who build installed software" #quote via @ph

Interesting thoughts about Feature Toggling

Idea one: separate feature launches from
infrastructure launches

  • You can deploy the code for a feature long before you launch it and nobody will know
  • You can completely rewrite your infrastructure and keep the UI the same and nobody will know

Idea two: run multiple versions of your code at

  • You can repeatedly switch between two backend systems and keep the UI the same and nobody will know

  • You can deploy a non-user facing change to only a
    small percentage of servers and nobody will know

  • You can offer different user interfaces
    to different users and nobody will know

Manage the different versions within your application
—> Branch in code

Three types of Feature Flags:

1. Development on user facing features
2. Development on infrastructure
3. Kill-switches

From: “Always ship trunk” slidedeck by Paul Hammond

Is this a better way to structure tests? via @KevlinHenney

I just came across this screenshot. I really like this way to structure tests.

What do you think? Would that be helpful in your team?



Make sure to follow Kevlin!

Does SAFe respect People, Inspection and Adaptation? via @henrikber

Lots of things have been said about SAFe. These 2 things bother me the most (via @henrikber)

  • In a complex situation the solution needs to emerge through inspect and adapt. 
  • People that are doing the work know best how the work should be done

SAFe violates these 2 arguments

Article from David Anderson that highlights those 2 arguments.

The Kanban Method will coexist with SAFe in the marketplace. People will choose between a modern 21st Century approach to complex situations or a familiar 20th Century approach to change and their software engineering processes.

How up2date is your documentation? Not at all?

Check out by @zuehlke_group

"Automated documentation of applications through UI tests"

Do you know how to present like a Pro?

Great 10 tips. I would add 1

  • Skip the “Agenda” slide
  • Make “Tell Stories” #2 of priorities


  1. Pass the Trapdoor test
    One minute in your talk, a trapdoor opens and you have another 1 minute left
    1 thing to remember?
  2. Make em laugh
    People don’t remember what you say, but how you made them feel
  3. Paint Pictures
  4. Show & Tell
  5. Skip the “About Us”
  6. Shorter wins… Always
  7. Open body language
  8. Why you? 
    Nobody else can tell this story better than me
  9. Share your weakness
  10. Tell Stories

Do you know the “bullshit asymmetry principle”? via @ziobrando

Great story behind this slide deck from Alberto Brandolini (Zio Brando)

What is the difference between “being agile” and “doing agile”?

Great article about the “Agile Mindset”

Make sure to checkout this diagram!!!

Google’s Scientific Approach to Work-Life Balance (and Much More)

Great article about work and life at Google and how to balance it.

Get started with

…for any organization, there are four steps you can take to start your own exploration and move from hunches to science:

  1. Ask yourself what your most pressing people issues are.  Retention?  Innovation? Efficiency?  Or better yet, ask your people what those issues are.
  2. Survey your people about how they think they are doing on those most pressing issues, and what they would do to improve.
  3. Tell your people what you learned. If it’s about the company, they’ll have ideas to improve it. If it’s about themselves – like our gDNA work – they’ll be grateful.
  4. Run experiments based on what your people tell you. Take two groups with the same problem, and try to fix it for just one. Most companies roll out change after change, and never really know why something worked, or if it did at all. By comparing between the groups, you’ll be able to learn what works and what doesn’t.

And in 100 years we can all compare notes.

Is your backlog a map or a list?
Taiichi Ohno (Toyota Prod System) on fooling westerners.

Taiichi Ohno on fooling westerners:

“I’m proud to be Japanese and I wanted my country to succeed. I believed my system was a way that could help us become a modern industrial nation. That is why I had no problem with sharing it with other Japanese companies, even my biggest competitors. But I was very, very concerned that you Americans and Europeans would understand what we are doing, copy it, and defeat us in the marketplace.”

He went on to say that when Americans and Europeans came to visit Toyota that he did his best *to confuse them* as to why Toyota was so successful.
He said,

“I explained it by talking about techniques, like quicker machine setups, reduction of the seven wastes (*muda*) and other techniques with Japanese names like *kanban* and *kaizen*. 

I did my best to *prevent the visitors from fully grasping* our overall approach. Today, I am ready to be open and explain fully what we did. We are now strong enough to deal with any competition.”

I am still amazed by the greatness of this man!



The problem with TDD! #noTDD #TDDisDead

The problem with TDD I think is: 

"TDD is harder to practice and TDD is harder to get ‘right’ than other tools." 

Not saying that your favourite tool is an easy tool to use ;-)


  1. TDD is a combination of: Thinking, Coding, Testing, Refactoring.
    Let alone “Testing”, lots of people (including myself) get already the “Thinking” wrong.
    Here an example of 2010 when I got the Thinking wrong 
  2. Additionally to those 4 there are lots of other skills needed: Mocking, CleanCode, Emergent Architecture, ATDD, …
  3. BTW: Did I say that Refactoring is very hard?

My video interview about: Clean Code, Testing and Continuous Improvement

Is TDD dead? No, its just a tool. #noTDD #TDDisDead

If you havent been on a internet-less island you probably heard about this blog and the google hangout conversation.

Here are my thoughts to that

# Unrelated 

Completely unrelated to TDD/UnitTesting I really enjoyed 2 sentences from the hangout:

"In order to understand/define something, I like to understand how it came about"
Martin Fowler


"If an idea is obviously bad, find a cheap way to try it."
"If an idea is good, someone else has tried it before"
Kent Beck


Read More

Interesting success story of Large Scale Scrum (LeSS) @ J.P. Morgan

What are the experiences of a large group in a tier-one financial services firm adopting Large-Scale Scrum (LeSS)?

Things I wanted to highlight:

Read More