Why Is Your Team Falling Behind? Ask ‘The Penny Game’
spin.atomicobject.com
spin.atomicobject.com
So pennies in later systems never fall onto the truck and get delivered to the customer, rather they fall into the final state and randomly teleport back into earlier stages as teams that implemented them start getting support work.
Unfortunately you're not going to be as productive when you're developing a new product against a background of supporting multiple existing products / customers, as you were when you were developing your startup's initial product without much else going on.
Absolutely. The cognitive dissonance is bad enough that we might be overdue for a change in vocabulary, starting with the word "done". Even hypothetically perfect code needs to get ported to a new architecture, OS, VM, and/or compiler at some point.
I think we, as technical experts, do a terrible job explaining that every piece of code old and new has an ongoing cost. The discussion points should be about which costs are higher and whether trade-offs are worth it. Are the ongoing costs (is the team even aware of what they are?) lower than the cost of change (how do we know it was worth it? can we change our mind if it wasn't?).
While the article brings up many good points about bottlenecks, estimation, and allocation of resources, I find that bad mental models of how software development works costs far more, albeit in subtler ways, than "Heather can do 12 units of work but we only gave her 8 and she blocked a lot on task Alpha instead of moving on to something else".
Though your mileage certainly varies.
The way to stay at the front of the race is to prioritize your bugs and fix the right ones in the time that you have because if you think you'll get them all, you'll never ship. Get the ones that have the highest probability of causing your customers pain and know that you aren't ignoring the ones that are scheduled for your next maintenance release. Debate intelligently if you think something needs to be reclassified as a higher priority and learn to accept that there might be a couple that you don't win so you can get on with covering as much of what remains as possible.
It's always hard to find good metaphors for programming programming as a craft, but I liken it to a factory or campus.
Even when it is "built" and producing value, there are always issues with maintenance and renovation and replacement.
"Technical debt" isn't just maintenance costs, but the restrictions placed on what you can do next. Ran an electrical line straight across the lawn? Now you have to black-out a building to progress.
constructional engineering has the benefit of clear physical limits, you cannot fiddle with a building after its release too much - add more stuff on top and it will crash down. people get that, by now.
same with software - everything gets added in, email, chat, video, whatever. then it becomes a bloated mess, and a new product, lean and simple, comes along. rinse, repeat. they will ruin Slack, for example, guaranteed, and not even that long from now.
the thinking of constraints, of boundaries of growth, has not been established in software yet. UNIX had it, but that mindset got lost as moore's law kicked in. but the constraint is the human mind, groking what the fuck those millions line of code actually do.
Actually, those get updates too. As scary an idea as that is. NASA engineers are some crazy folk.
But I don't disagree that software can be done. It depends on the software, and the supporting ecosystem just as much. A microwave doesn't need or get updates, but it's also not networked, or rendering across different browsers, or needing to support a lot of users.
But I think in the larger sense, done is relative. There is always a vision, and growth. And deadlines. This isn't such a problem so long as you are always working at making it better. But if all you ever do is ship features and never address the underlying design... good luck.
That's for the copy of the software deployed on a specific microwave. Presumably though the team that wrote that code are doing some ongoing work adding new features and fixing bugs for new model revisions and brand new models. As well as changes to keep their tooling and development environments up to date or at at least supportable.
That's a perfect example of an that proves the rule.
Saying that, even within that ecosystem, there are libraries, ports, oops-it-blew-up patches, builds against emulators because the hardware isn't ready, etc. You don't write a new codebase from scratch for every device you ship. Parts of that "done" code end up in next year's model.
Or your business model doesn't support your technical goals. That is, your business model doesn't work.
"I don't know yet. I need three days and I'll give you a better answer." is often a great estimate.
This article isn't about meeting (or failing to meet) deadlines, it's about work-in-progress building up.
To my mind the costs of context switching are pretty well established at this point and the value of limiting work in progress is clear enough from experience, but that's just my experience and maybe you disagree.
That's not what I'm advocating. All I meant to say is that when you have a lot of work in progress you get less done, whether or not you have deadlines.
This is modeling how people organize in hard Math, and getting real results to improve a situation. It is not equating software to manufacturing.
The penny game (where I work we call it the beer game) is a good learning exercise, but in software development you really don't want to be having different "stations" handing work off to each other in the first place, because that leads to delays and quality issues. Each station will develop its own little backlog and pretty soon a feature cannot make it from start to finish without spending weeks waiting in the design queue, then the dev queue, then the test queue...
Instead, you need to have a small, cross-functional team focusing on the same piece of the product at the same time, collaborating and giving rapid feedback on each other's work--that's what agile and XP and scrum are for. And you need a pull system instead of a push system, to regulate the amount of work in progress--that's what kanban boards are for.
Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions.
And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate.
Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.
But when you tighten the feedback loop and shrink the batch size of the work, you make the dependencies smaller and more granular, so the queue gets smaller and fluctuates less, and you get better flow of work through the process.
Here's a simple visual that illustrates why this is the case:
https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOf...
Lean, and Japanese manufacturing the worker has a lot power(They can stop the line) and have final say in quality.
I would create detailed step-by-step job instructions for each station in the manufacturing line, along with expected times each unit should take at each station. It was trivial to compare expected versus actual, then dive into the details of what's going wrong if the two values are not matching up (new vendor causing quality issues? machine troubles?).
With software, those "job instructions" are little more than the specification hammered out by (hopefully) someone who knows the product, domain, technical capabilities of the software development team (including design and QA). It's rare. Very Rare....any single person can estimate exactly how long a sprint or anything larger is going to take. One wrong technical hurdle, and every estimate is out the window.
For the "production worker" on the software dev team, just following those specs wont get them to the finished product. Their knowledge, how well the team can support lack of expertise, shifting priorities...these all create logjams.
The persistent assumption that writing code can be handled like a production process is flat-out wrong. The software equivalent to production is the build/test/deploy phase which any intelligent developer will automate.
The concept of a 'production worker' programmer seems ridiculous. Somebody more experienced researches the domain, comes up with solutions, specifies all those solutions, and the 'production worker' programmer is left to to what exactly? The engineering equivalent is handing a draftsman a hand written drawing and telling them to implement it in CAD. It's good for practice and to get new people up to speed with the process but it doesn't provide much value.
The reality is, unless the team is using an easily repeated process like churning out Wordpress sites from a scaffold generator, there's no such thing as 'job instructions' on a programming team. Each and every developer on the team is assessing the domain and trying to hammer out a specification for the production process. Any part of the process that's easily repeated should -- and ideally --will be automated away.
It's not an easy process to measure because specification requires extensive research and discovery. Bad assumptions are made and corrected. Some approaches require new and novel approaches. A significant amount of the work comes with a great deal of risk.
Throw a few programmers into the mix who lack the battle hardened experience and wisdom of previous successes/failures and they'll generally drag everybody else down.
In short, software development is not a production line. It's hard to define because it requires a lot of unknowns and even more unknown unknowns.
Which is why everything always takes longer than I think it should.
I feel like there is room for an analogous quote about using the Poisson distribution compared to capacity reasoning.
If you optimize something that isn't a constraint, the problem isn't just that you are wasting effort - it's that you might also be unwitting increasing the backlog of another part of the system. So it's not only "not helpful", it could sometimes even be harmful.
That's why Goldratt et al emphasize constraint analysis so much - analyze the entire system (usually using causal analysis; why certain parts of the system explain other symptoms), identify the current core constraint, invest all spare efforts to alleviate that constraint only (and not other inefficiencies), and then re-analyze.
I don't believe this is necessarily counter to Agile! It's just that a lot of people implement Agile badly. Which isn't a problem with Agile exactly, it's just that there's a lot about complex systems that are counterintuitive. You can't really be reductionist about it.
I wonder how the game would end up if stations could work on other levels for a slight penalty to production for both stations, only kicking in when one is idle over some threshold.
If the problem is that some developers are literally idle because their task is done, they should do something else.
As always: communication overhead. This developer coming in to a new thing after finishing their last thing has to spin up on all sorts of stuff, maybe they don't even know much about what we're working on, but even if they do, they don't know what the current status is. All that spin-up has cost both for the developer and the new team. It is often more efficient to spend that idle time working on lower-priority tasks in their current area.
IMO the solution is to stop treating programmers like cogs in a machine, and actually give them some amount of autonomy to make decisions.
We refactor as we go, even if the business value could have been delivered "faster" by compromising long term value for short term goals.
But we also let them do their job and trust them to understand the strategic goals to the business better than we do.
I remember one place I worked, they brought in consultants to "help" us create an agile process. After about four months or so, they declared the operation a success because the "velocity" had increased by 4x. (Which would be incredible if it were true). In reality, we were just measuring four times more things, and development was going much slower, but those charts sure looked nice.
Oh man, this happened at one of my stricter scrum managed companies. There was a bug that people were noticing that should have meant that no other cards could pass QA.
I recognized it as the small change that it was, made the branch, and had a peer ready to merge it, but got "a talking to" from the scrum master and product managers because they never recognized it as a bug.
The problem is that you don't know what average throughput is until you run the system in production. So you might have either too much, or too little capacity.