@samnewman @_ggoran @allenholub @davefarley77 @bakeraljc @nodosenlared @matthewpskelton Very much this. To your question, Goran, the words "domain", "microservice" and "team" vary hugely between orgs (and often in the same org!). I've seen "microservices" be significant subsystems or a few tens of LOC, and "teams" of 3-30 people. My approach is in that video >> @samnewman @_ggoran @allenholub @davefarley77 @bakeraljc @nodosenlared @matthewpskelton >> I linked earlier. We identify the demand, then look at the systems/microservices/etc that we will need to touch to deliver the work. This informs the makeup of the teams. So if we will work on service X, we need expertise of both that service and its subdomain *in the team*.

1/n tl;dr:

Sometimes you have to work like a dog to get to a place where you no longer have to work like a dog. Claiming otherwise is privilege.

I'm a financially stable 50-something. I grew up poor (by Western standards) in a single (alcoholic) parent household. 2/n When I was young, most of my peers were relatively well-off. They could afford things like clothes, especially designer clothes.

This was the 80s so it was all sports casual with designer labels. My clothes came from the market. I got bullied for that.

So @JoshuaKerievsky’s tweet about my use of “Example-Guided Development” (he says Design but I prefer Development) has caused some discussion. I figured I would try to explain my thinking and link to some of the discussion in a single thread, to attempt to tie it together.

https://twitter.com/JoshuaKerievsky/status/1156943290941333504

@JoshuaKerievsky I spend a lot of time thinking about “getting the words right”. Naming things is hard, etc. TDD has never been about testing, at least not in any way that could replace actual testing. It is a design discipline that uses executable examples to help guide the thinking.

[last thread today]

That’s a valid challenge @RonJeffries. I should have been clearer about the difference between Lean Operations and Lean Management. Operations is doing stuff, Management is designing and maintaining the system in which stuff gets done.

https://twitter.com/RonJeffries/status/1022470675926278144

@RonJeffries Lean operations comes in three flavours:
- Lean Manufacturing or Production, aka the Toyota Production System)
- Lean Supply, aka Supply Chain Management
- Lean Product Development (the one that usually gets missed, that @DReinertsen so expertly covers)

[another thread]

Great question, thanks @girba. I've been focusing on the supply side. On the demand side I talk about internal and external demand. External demand is stakeholder value. Internal demand is improving our ability to deliver. This is where the kaizen happens.

https://twitter.com/girba/status/1022424779759013888

@girba In most delivery contexts I see, the team has to fight for internal improvements, hide them among other work, squeeze them in the gaps or just not do them. From a product management perspective, the PM doesn't know how to assess the value of this either, so that's an unfair ask.

[thread]

tl;dr:
1. Estimates are not necessarily waste.
2. Feature/story level estimation is almost always unnecessary.
3. You’re probably doing estimation wrong anyway.

For 1 we’re going to need a brief intro to Throughput Accounting (don’t worry) and what is and isn’t waste.

https://twitter.com/RonJeffries/status/1021818544256888833

Throughput Accounting is dead simple. There are only three numbers:
- “Throughput” is how much money you make selling your product.
- “Inventory” is how much you spend on stuff you turn into Throughput.
- “Operating Expense” is how much you spend turning Inventory into Throughput

[Thread] What do I mean by “the best programmer I know”? Let’s start with the assumption I think I’m a decent programmer. Here are some examples:

1. He sees what is really there. I see what I am conditioned to see. Once he points it out, it was obvious all along.

External Tweet loading...
If nothing shows, it may have been deleted
by @skooterTwitten view original on Twitter

2. He solves the problem at hand, not a fancy generalised version of it.

3. He writes simple, obvious code that is easy to change later.

4. He knows he doesn’t know, but tries anyway. He then iterates on his attempts until he gets there. This requires humility and perseverance.

That's a valid challenge. Allow me to clarify: Scrum as a method is outdated. It was groundbreaking in the early '90s but has hardly changed since. Some of its presuppositions have become invalid, ironically through its own success.

Two examples, the Product Owner and Scrum Master roles: