I’ve been involved in the Agile space for 20 years and witnessed a couple of trends over those 2 decades. In the last 5 years, I’ve seen a lot of effort in scaling Agile at the enterprise level. While Agility has proven its value at the team level, efforts are still deployed to create enterprise agility. Those efforts created a lot of discussions, comments, and criticism over the years.
Many scaling approaches are based on Scrum (LeSS, SAFe, Nexus, etc). I just couldn’t find a good scaling book from a Kanban expert. Prateek’s book was, for me, a breath of fresh air around scaling agility with the perspective of Kanban instead of Scrum. His main proposition for solving the scalability of Agile is to use flow. To quote him on page 3:
Our focus here is scaling flow and agility, not necessarily scaling Agile.
By using flow as his guiding principle instead of Scrum in the approaches named above, the conversation in his book is quite different than what I’ve read in the last 5 years around scaling. For me, it was refreshing to read about scaling from a flow perspective rather than a Scrum perspective like LeSS, SAFe, or Nexus.
I’ve found the author to be true to the mantra of flow across the entire book. More than once in the book, I have found him going back to flow when discussing multiple issues around scaling agile … whoops I mean scaling agility.
As I was reading the book, the term ‘Lucid’ came often to mind. The concepts, ideas, and examples were clear and easy to understand. Based on Lean principles, Prateek explains how Kanban is an implementation of Lean. Based on a 9-page guide, Kanban is very straightforward to understand and implement.
Most of the Kanban practices and techniques suggested by Prateek are mostly known in the Agile community. Team Boards. Portfolio boards. Exit criteria. Policies. WIP. Flow metrics. Extending upstream and downstream boards. Blocker policies. The author doesn’t reinvent the wheel when it comes to Agile practices. If you have used Agile in the past, you will be in known territory here in regards to practices to set in place.
Chapters 1 through 9 were for me a good refresher on Kanban. Things got more interesting for me starting at chapter 10.
Highlights of the book
I appreciated how Prateek challenged some conceptions I hold dear in Agile. I found the author very courageous in challenging those conceptions and I thank him for that. Always with flow in mind, I greatly enjoyed his perspective on strong themes in Agile and scaling.
Blockers
In chapter 10, I liked how the author is clear about blockers. He proposes 3 levels to consider when an item is blocked and when it should be removed. He then talks about internal and external blockers. These policies are simple and reusable in any context if you ask me. If your team(s) are still struggling to define what a blocker is, have a look at this chapter.
Prioritization
I found chapter 11, Prioritization, fun to read because it took me out of my comfort zone. His analysis of different prioritization techniques leads us to conclude how prioritization is waste, a novel idea in the Agile world. If prioritization is an issue with your teams and you are looking for ideas out of the beaten path, read the 10 pages of this chapter. Yes, only 10 pages to prove his point. For Prateek, all that matters from the perspective of flow is what gets pulled in next. If we can make this as inexpensive as possible, we can make sure we will not interrupt the flow of work.
Effectiveness
Chapter 14, Effectiveness, was also a gem to read. The example of the Berliner Republik was fascinating about being as transparent as possible about the current demand and how it influences the prices. Prateek’s suggestion of adding a ‘Monitoring’ column to our Kanban board is another novel idea. When was the last time that you saw a ‘Monitoring’ column in a Scrum, SAFe, or Nexus? Probably never. My take is these frameworks are well-oiled internal processes for IT. But they aren’t responsive to feedback from the market, as explained through the Berliner Republik example.
Total Age
One other novel idea I picked up from Prateek but it isn’t in his book was calculating the total age of active work items in your workflow. In the past, I would use the total WIP to have some indication of the amount of work in a workflow. I’ve found the total age to enable a richer conversation.
Let’s say you have 10 work items on your board. Is that a lot or not enough? But their total age is 110 days. For me, looking at the total age changes the conversation because it’s a scale that is more presentative than just 10 items.
To add to this total age idea, let’s add a daily price tag to this total age. For example, let’s say each day worked on the item costs 1,000$ to the organization. This means that for a total age of 110 days, there’s currently 110,000$ invested in potential features.
Let’s say I have another team with 10 work items on their board. But their total age is just 31 days. If we keep the same daily cost, 1,000$/day, this team has 31,000$ of investment on their board. Same amount of work but different investments.
Team size
One final gem was chapter 19 where Singh takes us back to a Slack conversation where somebody stated how “it’s better to have multiple, highly specialized, small teams — and coordinate them properly — than a large bunch of T-Shape “jacks-of-all- trade”.
The author takes the rest of the chapter to verify this assumption through Monte Carlo simulations. If there’s one thing I’ve learned from Prateek, is how he demonstrates his point by doing experiments to validate his hypothesis. What were the results?
A disservice that methods under the umbrella of Agile have done to systems is promotion of the idea of ‘small teams’. Small teams can be very efficient, but treating a size limit as holy scripture is blindly following dogma that might not be the best option in your context.
He made me think about how I should challenge this mental model that is too ingrained in the Agile community. Well, let’s just say that “the common small-team advice in Agile is mostly dogma”. If you strongly believe in this dogma, please read Chapter 19.
Numbers, numbers, numbers
Another key takeaway about this book is the amount of numbers it has. Compared to other scaling books where practices, roles, and events are explained and linked together, Prateek’s book has data to prove some of his points.
I find the author true to his North Star, flow. After a few chapters, I got used to seeing the author always coming back to flow to justify his reasoning. If flow, and the underlying efficiency, effectiveness, and predictability are things you value, you will find value in this book.
The challenge I foresee after reading Scaling Simplified is the management courage required to implement flow at scale. While Prateek was staying on course with his vision throughout the book, I couldn’t keep thinking of the politics, HR issues, aging IT infrastructure, power struggles, and many more constraints management will face when scaling flow.
It is easy to hire consultants who will come in to install Agile at scale. As a manager, you can fire them when your staff has had enough, not risking your job along the way and stating that agile doesn’t work at your company. On the other hand, scaling flow asks management to address their difficult questions without a recipe at hand. I believe it is much harder to come back over and over again to the Lean principles listed by Prateek. In other terms, a deep commitment to flow and its Lean principles are required to achieve Prateek’s vision in his book.
If you plan on taking the Applying Scaled Portfolio Kanban (ASPK) class from ProKanban.org, I would suggest reading Scaling Simplified as a prerequisite. I believe it will give you a foundation for the class. In the class, you will already have an understanding of the ideas behind the class and be ready to dive into specific topics with your trainer and other participants.
I would recommend this book to anyone who has an interest in scaling agility AND is exhausted of the current approach on the market. If you are a mid-level or C-level manager, I would also recommend this book. Be warned though, you will not find a magic bullet. You will probably find some simple techniques and practices that can impact the flow of your organization. The hard part is to pursue this commitment to flow.
My hope for the future is to see a follow-up book in a few years, let’s call it Implementing Simplified Scaling, which would be a collection of testimonials about people who tried, failed, and succeeded with scaling flow. Who knows, maybe one day, Prateek will be giving a keynote at the annual Agile conference about simplified scaling with flow.
English 
French