Agile
The Right Way to Think about Cost Savings in Agile (via Leading Agile)
Some companies think that bringing in Agile (e.g., Scrum) lets them fire their architects and middle managers to save money. If you have a ball of mud because of dependencies and high orchestration costs, Agile won’t help you. (This is usually where people throw Agile out because it “didn’t work.”) Also, some people erroneously attribute their success to Agile methodologies instead of having the root problems solved (e.g., open requirements, ownership of the tech stack, CI/CD from the beginning).
Communication
Want to Win Someone Over? Talk Like They Do. (via Harvard Business Review)
- Pay attention to how others communicate
- Build genuine relationships
- Consider whether evaluators are likely to change
- Don’t forget about ethics
Culture
How Apple Is Organized for Innovation (via Harvard Business Review)
This article talks about how as Apple grew, it resisted the typical choice to organize into business units and divisions, using a functional approach instead. This means the managers also have to be experts (i.e., not just good managers, but good in the area they’re managing). I wonder how well this scales because (1) at some point, things become so complex that one person can’t know the breadth and depth sufficiently, and (2) not all technical stars make good managers. Some of this echos the “project to product” shift; however, I wonder how much of their success is due to their momentum, not their way of work. (That is, if you have more money than God, you can do whatever you want because the losses that would torpedo any regular company are “rounding errors” to Apple.)
Process
No, engineers don’t suck at time estimates (via Software Lead Weekly)
This is a fantastic article about how estimates, at best, should be ranges instead of point values, especially when too many independent variables go into producing said estimates. I liked the call-out of the power law, and how statistics are abused to appease project managers. Flow-based approaches like Kanban and timeboxing are tried and true, as the article highlights. The more I learn about different approaches (and experiences I’ve had), the less I care for Scrum. I know there are exceptions, but every org I’ve been in tried desperately to use story points and burndowns to predict the unpredictable; they rarely worked in practice for reasons the author explains.
Productivity
You’re Between Assignments at Work. What Do You Do? (via Harvard Business Review)
- Set a time limit of how long the lull should be
- Challenge yourself by taking on things a bit outside your comfort zone
- Find ways to give back to others
- Finish tasks that have been lingering
Process
Ask HN: How do you balance reading books vs. articles (via Software Lead Weekly)
Everyone has their own system of what’s signal/noise. I prefer books for general topics that have longer shelf-lives, as books get more editing and have more thought put into structure and presentation. I use short-form pieces to stay current on topics that move to quickly for books to stay relevant (e.g., trends, technologies, topical subjects).
Software Development
A Common-Sense Guide to Data Structures and Algorithms (Part 5)
Our book club moved on from lists to stacks, queues, and solving problems using recursion.