The value is in the red

Many developers and organizations seems to be afraid of red builds. To get fewer red builds, gated check-ins, feature branches and other non CI techniques are unfortunately often seen as a "solution".

Sure, fixing a red build should be top priority but trying to prevent them in the first place by integrating code less often is just wrong. Red builds are good feedback.

Continious integration

I'm surprised to see how many developers there are who've misunderstood CI. No, it's not about tooling. No, it's not about build chains. No, it's not about visualize your automated builds. It's simply says that you should integrate your work with all others, all the time.

So no, CI is not a good mix with gitflow or other feature branch processes.

But yes, CI is a very good mix with TDD, small user stories and feature toggles.

Solving tasks

Junior: Make sure task works
Mid-Level: Make sure everything works
Senior: Make sure task works

Who to blame?

From time to time I hear discussions what team should fix a certain issue. Should it be the team who did the push or should it be the team owning the failing code?

• If team A pushes some code and build goes red, team A is responsible making it green again.
• If a bug is found in code owned by team B, team B is responsible having it fixed no matter who pushed the defect.

No, you're not practising TDD!

"In TDD, how can I test this private method?"

Test column(s) antipattern

Having seperate test (or analysis) columns on your kanban board simply shows that the you still think in a waterfallish way.