Agile

IT Management Paradox

  • Effective management practices lead to small teams.
  • Ineffective management practices lead to huge teams.
  • Most people are involved in ineffective practices.
  • Demand for ineffective management practices is higher, than denamd for effective practices.
  • Education system follow the demand of the majority.
  • Education system teach ineffective management practices, because the demand is higher.
  • Effective management practices extinct.

This explains all that billionairs with unfinished education: it’s better to know nothing, then to know wrong.

Example:

“Tick-the-code” and similar practices are widely replaced by “intuition-based-review-of-single-commit” practices. Intuition based review is perfectly useless. Whatever you call it “expert review” or “experience based review” or whatever. Single commit review is also perfectly useless. All commits can be ideal, but together they can, and will, create nonsence. Bare minimum for review is 1 class.

Old-school Agile rule of thumb

If it needs special tools - it’s bullshit.

IMHO, if the tool is just a replacement for pen and paper, but you still can do it with pen and peper - it’s ok. It’s not handy to use pen and paper in the age of remote work. But anything more complex will only make things worse.

Agile: Why do we use Todo Work Ready Done, instead of Red Green Refactor Deploy?

Looks obvious, right? 🤔

Current setup

In TDD, we use the following sequence:

  • Red: try and fail
  • Green: fix and confirm
  • Refactor: polish solution

That’s 100% solid time-proven sequence. But in Agile/Scrum/Kanban we completely different approach:

  • Todo
  • Work
  • Ready
  • Done

Which is not as good as it looks at first sight. That’s why Trello and Jira had an option to set custom workflow and custom task states.

TDD workflow and Agile task workflow does not map to each other in any aspect! 🥲

So, why are we doing that? To be more “manager friendly”? Is it “positive thinking” which stops as from using the word “fail”?

Well, we can replace “try and fail” with “try and confirm that feature is not implemented / reproduce the bug”, happy?

Suggestion

Maybe we can use sequence like that, for task management:

  • Pick: from heap to sprint backlog
  • Try/Red: Try it and confirm the issue
  • Fix/Green: Fix and confirm solution
  • Polish/Refactor: polish solution
  • Commit: share changes with the team
  • Package: aggregate changes into release package
  • Test: QA team test the package
  • Deploy: publish package for general public
  • Collect feedback: from support team, investors, etc.
  • Fund: get money for next sprint

This looks much closer to reality, you know.. 😎

I suggest using Try/Fix/Polish insteard of Red/Green/Refactor to avoid confusion between task management and coding. But that sets maps to each other perfectly!
Also, that’s closer to the idea behind SMART criteria.

For in-house projects, it can be simplified to just:

  • Pick
  • Try
  • Fix
  • Polish
  • Deploy

Why not?