Kanban, Scrum, Agile and TameFlow

Just finished the last chapter of part 6 , and what also appears to be a summary of the whole TameFlow approach and how it contrasts with other Agile methodologies.

I have always had issues with the various Agile methodologies but have never been able to properly (and precisely) articulate why. Now I can :slight_smile: … thanks to TameFlow.

Just wanted to say a “big thank you” to both Steve and Daniel for putting this book together, and taking the time to answer my questions on this forum. (Very much appreciated). The book is absolutely worth reading (actually, that is wrong. It must be studied).

Procedural justice (!) (now that is a thought worth pondering…)

Look forward to eating the cherry on top of the cake in part 7.



:blush: :blush: :blush:

1 Like

So what is it that resolves your “issues” with respect to Agile, and what were they?

My biggest gripe are around the many different rituals that people follow mindlessly because someone said so.

Daily Standups is one of them. I really like your “management by exception” approach. The less interruptions the better, and only hold meetings if they are truly necessary.

Sprint planning, backlog management and planning poker.

I feel establishing task duration estimates, is missing the point, more should be done to properly explain to the team what the value to the customer is. With a better understanding of what the customer is trying to achieve and how it will deliver value to them. With that in mind, it will be easier for the team to come up with better, simpler solutions that deliver more value in less time.

TameFlow has really cemented the importance of using the “value” lens for every decision we make.

I feel a lot of Agile methodologies loose sight of that. In fact I just went back and re-read the Agile Manifesto. It talks about what Agile development teams value, but does not explicitly discuss the importance of delivering value to the customer. You get a sense that it is implied indirectly, but that probably explains why it is easy to loose sight of in the first place.

To be fair it is mentioned in the first paragraph of the “principles”, but how many developers read that?


Every time I read the book, I discover new stuff !!!

I will start a new reading of the book in a few weeks (my first crack at the paper version)

Thanks for the kind words.


1 Like


WOT?! There’s a fine print in the Agile Manifesto?!