7 Habits is a classic self-help book that would accomplish some of this. Although, it approaches the problem of business indirectly with concepts like degree of control vs. degree of concern. It also suggests principles that an overly busy person cannot follow, but never connects the dots by explicitly saying "you're too busy."
Another one to look at comes from R&D management: Principles of Product Development Flow. The first couple chapters, especially, explain the problems of trying to maintain a full schedule (queueing theory.) I would probably make a resource based on the book rather than just handing someone a copy, unless you know they'd not be intimidated by it. https://www.amazon.com/Principles-Product-Development-Flow-G...
Changing to it was inspired by a few things one of which was: https://www.strategy-business.com/article/10204
As well as a talk at CTO club which unfortunately is not shareable but can share the footnote listing: [1] 2014 State of DevOps Report https://devops-research.com/research.html [2] 2016 State of DevOps Report https://devops-research.com/research.html [3] 2015 State of DevOps Report https://devops-research.com/research.html [4] Westrum, R. “A Typology of Organizational Cultures”, http://bmj.co/1BRGh5q [5] Shook, J. “How to Change a Culture: Lessons from NUMMI” http://sloanreview.mit.edu/article/how-to-change-a-culture-l... [6] https://www.slideshare.net/reed2001/culture-1798664/93-Highl...
Though if you are interested in a good book on loosely related subject, highly recommend "Principals of Product Development Flow" https://amzn.to/3Ox4PgB
Second, the areas given and why I believe they're not as useful as alleged.
1. Activity Days In the example provided "Activity Days" is measured by the count of lines of code that have been altered. First, this is easily gamed and second it doesn't actually tell you anything other than an engineer is (supposedly) altering code. It also doesn't have any insight into the other responsibilities that an engineer may have during a sprint that have nothing to do with code. I can only imagine a manager's manager looking at this and constantly asking why engineer Ben seems to never be active without ever actually understanding what it is that Ben is really doing day-to-day.
2. Impact To quote the article, "The bigger is the impact the more will be the code and the project affected.[sic]" Impact is not synonymous with risk and risk is far more important to determine. Impact is a small part of the equation one can use it to help determine risk. That said, risk should be determined up front as part of pointing prior to any work being done. If a team can't properly point a piece of work while taking risk into account then the team likely doesn't understand what they're actually trying to do and need to do a research spike.
3. Code Churn The whole point of agile is to iterate and try things. And some of those things will possibly even be thrown away completely. If a team finds itself in a situation where it has iterated the entirety of a two-week sprint on a single piece of functionality then that should be discussed in retro. The discussion should be to determine if the repeated iterations added value or if the team was merely spinning its wheels. This is up to the team to decide not someone who is looking at a "code churn" metric.
4. Work Time Knowing how long engineering takes per work item _as a whole_ is far more valuable than breaking down an engineer's time into the areas described (avg pr time, avg review time, time to open pr). The reason for this is that an engineer's time is only a portion of the overall work done in a sprint for a work item. A team will generally have to do the following steps 1) design 2) engineering 3) quality assurance 4) documentation. Work items often have drastically different time requirements within those steps. A case that may take a day in engineering may require three in quality assurance, vice versa, or three in each.
Now, what should be measured.
Flow. The flow of work items, in a sprint, from start to finish through every step of the way. This requires using points to determine complexity, risk, and other agreed upon concepts (NEVER USE TIME hours, days, etc). Second and even more important, value. This is the most under observed and ignored attribute in agile/scrum or any workflow for that matter. If the product owner can't place a value score on a piece of work then the team should not be doing it. There is nothing more wasteful than producing a piece of functionality for a software product that nobody ends up using. Along with this, there needs to be a way to determine if the value score on a piece of work is accurate as part of a feedback cycle for the product owner and team. (Observing the life of a work item in a released product via usage metrics is one way of achieving this.) When a product owner does this correctly it's amazing to watch. You can't even imagine how ecstatic customers can be when they're constantly bombarded with high-value functionality.
For more information, I would recommend the following reading on this topic.
Start here: https://www.amazon.com/Actionable-Agile-Metrics-Predictabili...
Then go here: https://www.amazon.com/Principles-Product-Development-Flow-G...
by Donald G. Reinertsen
https://www.amazon.com/Principles-Product-Development-Flow-G...
Wish I had read this years ago! I think every developer can benefit greatly from understanding these principles. Plus if they were more widely known and adopted it would be easier to get other managers to go along with them.
[1] http://amzn.to/2GL17hs (affiliate link)
I have yet to find a better text on how to properly manage software projects than, "The Principles of Product Development Flow: Second Generation Lean Product Development"[0].
[0] https://www.amazon.com/Principles-Product-Development-Flow-G...
Some of it was familiar. Some of it was new. The language used and how the book articulates the reasoning behind various strategies has been invaluable to me in expressing to others why something is a tractable problem as opposed to an unavoidable one that is just the cost of doing business.
To date I have not succeeded in getting anyone to read it though.
[1] http://www.amazon.com/The-Principles-Product-Development-Flo...
Google "planning fallacy", or see http://lesswrong.com/lw/jg/planning_fallacy/. In general getting a list of tasks together and thinking you have a handle on what it will take is a delusion. Trust your gut.
These books shifted my thinking on why some projects work out and others are disasters.
* http://www.amazon.com/The-Principles-Product-Development-Flo... * http://theleanstartup.com/
You could go the PMP route, I suppose. And get used to MS Project, which is a tool of the devil, but a necessary evil.
I would recommend reading this book for a very good, but broad and high level intro:
http://www.amazon.com/Introduction-Materials-Management-Tony...
This will cover topics like BOMs, MOQ, Safety Stock, Inventory strategy, warehousing etc.
Next I would recommend reading up on the following phrases: "product development" and "new product introduction" / "NPI"
http://www.amazon.com/Best-Practices-New-Product-Introductio...
http://www.amazon.com/Principles-Product-Development-Flow-Ge...
Lean training/reading never hurts either. Note: this is supply chain lean vs "lean start up".
http://www.amazon.com/Lean-Dummies-Natalie-J-Sayer/dp/111811...
A great read on the subject of batch sizes and limiting WIP: http://www.amazon.com/The-Principles-Product-Development-Flo...
Link (no affiliates): http://www.amazon.com/The-Principles-Product-Development-Flo...
To add: I highly recommend Principles of Product Development Flow (http://www.amazon.com/Principles-Product-Development-Flow-Ge...) - incredibly difficult book to read (i.e. lots of good but dense information) but it explains well the underlying principles - and thus goes beyond the buzzwords.
Simply put lean startups result from the combination of lean manufacturing principals and maneuver warfare (agility) principals combined and used in business. Which if you want to boil it down further could be thought of as using the scientific method as quickly and efficiently as possible to create organizations and products where teams have fully adopted a culture of continuos improvement.
Lean is probably best known for its ability to enable Toyota to be the amazing manufacturing organization they have been (ignoring recent growth related fuckups). See the book Lean Thinking or the many Lean Software books to see the ways in which people have translated Lean concepts to software development. Of course if you want to really grok lean in the context of making products you should study http://www.amazon.com/Principles-Product-Development-Flow-Ge...
Agile principals as codified by the god father of agile strategic thinking, John Boyd would be the other crucial element to lean startups. He is famous for driving maneuver warfare doctrine into the US military establishment and codifying some of the most advanced strategies and concepts regarding the nature of competition, agility and strategy. If you have seen the OODA loop or heard the phrase operating inside the enemies decision cycle then you have seen his work in action. See the book Certain to Win by Chet Richards for a good primer on Boyds work.
These concepts rigorously and intentionally applied to developing products, teams and companies are IMO what makes a startup lean.
And of course if you are interested, you can also read Eric Ries or Steve Blanks blogs.
https://www.amazon.com/Principles-Product-Development-Flow-G...