flail

Appreciate thinking of problems that might have made it work not so well.

Having said that, the office is a single floor. The grocery order is once every few weeks.

There's quite some time flexibility in ordering stuff.

There is plan B (buying a couple of cartons in a grocery shop on the same block).

The system is scaled to what we need. And I don't say anyone should copy it blindly. If we talked about several floors, multiple coffee corners, etc., the flow of index cards might have required much more conscious thought.

In our case, we need none of this.

Also, continuous improvement (kaizen): start with something simple, then improve it. There's not much point in solving hypothetical problems with system design. Most of the time, we'd only be unnecessarily complicating the solution.

Which (tongue in cheek) is half of the history of software development :)

For all but 4 people, it's on the way to their own desks.

I bet that when someone just drops the card on the kitchen table, someone else would carry it to Kasia. As far as I know, dropping the card has never happened.

Nonetheless, the comment is spot on. If people needed to go far from their regular tracks, it might have been less reliable. Good system design means that doing the right thing is the easy/easiest thing.

People who genuinely want their teams/organizations to improve didn't disappear.

However, the labels under which they operated were taken over by the certification business. So, "grassroots" people either don't care about the labels at all or they invented their own.

By now, Agile is an empty buzzword. Unless someone explains what they mean by that, it means nothing.

Same with Kanban, by the way.

"The Phoenix Project" is basically "The Goal" rewritten in the context of software projects so that people would pick up the ideas easier instead of dismissing them as the "unrelated context."

The authors never hid their intentions on this one.

BTW: both are great reading.

Also, the grand idea described in Goldratt's The Goal is the Theory of Constraints (ToC). While Kanban (as a method) draws from it with the limiting WIP practice, these two don't overlap that heavily.

That is an interesting observation.

The first two (and I would say key) practices of Kanban (as a method) are: - visualize work(flow) - limit work in progress

So I wonder, how did these Kanban teams visualize work exactly?

Now, I don't say the whiteboard (virtual or physical) is the only way to do it, yet it's almost ubiquitous.

That's true. The notion of what Kanban is differs between knowledge work (stemming mostly from software development adaptations) and manufacturing.

Since my context is primarily IT I made some simplifications when describing the context.

Admittedly, the principles are the same. However, because of the differences in the nature of the work, different areas are stressed. A notable example is how differently "removing waste" is considered between IT and manufacturing.

Anyway, yes, whiteboards and sticky notes are staple artifacts of software development/knowledge work context. "Old-school" (since it started decades earlier there) manufacturing is much more creative with designing visual signals.

On the other hand, knowledge work typically handles uncertainty and variability of work way better. That stems from a different type of process (more creative, less repeatable) and unique nature of each individual task.

As someone who's running an agency--even if in a different part of the world--and taking care of the financials I see a very similar pattern.

More importantly, I'd second "A fair salary is the one you shake hands on."

Interestingly, there may be an interesting relationship between the two observations.

We are located in Poland so the numbers are not exactly the same as they are for a US-based company, yet the structure is similar. However, some of the work we do goes through a partnership agency located in US. Some of the work we do directly for US customers. So these are the same people doing the same quality work with the same efficiency.

The difference in the rate for the end customer? 100%+ If they go through US-located partnership they pay double. Note: the whole setup is fully transparent for the end customer so there's no pretending that we are not who we really are.

Should our people expect better salary because there's someone making a huge premium on the top of what we are making? Well, that would definitely make our business unsustainable.

Can we raise our rates to a similar level when working directly with US-based customers? That doesn't work either as the premium is paid for the fact that people come through US-based consultancy.

Is the work done in any different manner? No, it's exactly the same work.

So we end up balancing our financials and we acknowledge that from time to time we would lose an engineer who will either jump on the independent consulting bandwagon (the leverage for them is potentially much bigger than if they were located in the US) or join US-based company remotely.

Ultimately "a fair salary is the one you shake hands on."

Note: we are an entirely transparent company, thus all the financial details are known to everyone and we openly discuss these matters. We also strive for fairness understood as collective fairness, i.e. if I want to earn over what is commonly perceived as the value I bring to the company I'm not getting it. Also, we share the profits with everyone at the company.