What do you think?
Rate this book
A Mike Cohn Signature Book
Large-Scale Scrum: More with LeSS
In "Large-Scale Scrum," Craig Larman and Bas Vodde offer the most direct, concise, actionable guide to reaping the full benefits of agile in distributed, global enterprises. Larman and Vodde have distilled their immense experience helping geographically distributed development organizations move to agile. Going beyond their previous books, they offer today's fastest, most focused guidance: "brass tacks" advice and field-proven best practices for achieving value fast, and achieving even more value as you move forward. Targeted to enterprise project participants and stakeholders, "Large-Scale Scrum" offers straight-to-the-point insights for scaling Scrum across the entire project lifecycle, from sprint planning to retrospective. Larman and Vodde help you:
Implement proven Scrum frameworks for large-scale developments
Scale requirements, planning, and product management
Scale design and architecture
Effectively manage defects and interruptions
Integrate Scrum into multisite and offshore projects
Choose the right adoption strategies and organizational designs
This will be the go-to resource for enterprise stakeholders at all levels: everyone who wants to maximize the value of Scrum in large, complex projects.
Implement proven Scrum frameworks for large-scale developments
Scale requirements, planning, and product management
Scale design and architecture
Effectively manage defects and interruptions
Integrate Scrum into multisite and offshore projects
Choose the right adoption strategies and organizational designs
This will be the go-to resource for enterprise stakeholders at all levels: everyone who wants to maximize the value of Scrum in large, complex projects.
368 pages, Kindle Edition
First published November 6, 2014
165 people are currently reading
513 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 32 reviews
December 2, 2016
Definitely much more interesting in the initial chapters (before the description of ceremonies) than in the final ones. Why so? There're far more scaling considerations there (+scenarios) that get repeated in a slightly different form in the very end. The most interesting parts refer to: the role of management (truly good stuff!), the boundaries of product, approach to refinement.
Btw. if you've read two previous books by these authors & you expect something similar, you may end up disappointed - this book is supposed to be brief & very "to-the-point" (without exhausting all the possible consideration paths :>). Some sort of a "starter-handbook" for people who want to get a glimpse of LeSS & maybe try it out.
So, to summarize: recommended or not? Yes, IF you didn't read much about scaling agility yet AND you didn't read previous Larman+Vodde books before AND you're not sick with reading about Scrum ;>
Btw. if you've read two previous books by these authors & you expect something similar, you may end up disappointed - this book is supposed to be brief & very "to-the-point" (without exhausting all the possible consideration paths :>). Some sort of a "starter-handbook" for people who want to get a glimpse of LeSS & maybe try it out.
So, to summarize: recommended or not? Yes, IF you didn't read much about scaling agility yet AND you didn't read previous Larman+Vodde books before AND you're not sick with reading about Scrum ;>
February 5, 2025
I believe this book to be outdated. While there are still some concepts that are explained well, neglecting the remote culture and pretending the only way to gonia working from the office is just delusional.
Also after reading it, I’m under impression that it promotes hussle culture and meeting driven management where „just talk” is the answer to almost every problem.
While I agree, constant communication and disturbances are also one of the main reasons of not getting the work done.
Also after reading it, I’m under impression that it promotes hussle culture and meeting driven management where „just talk” is the answer to almost every problem.
While I agree, constant communication and disturbances are also one of the main reasons of not getting the work done.
September 20, 2017
An excellent book with many great ideas. Some of my favorite excepts:
“for every item in every team, they have written the automated acceptance tests before starting to develop the solution code. Thus, in addition to integrating the code continuously, they’re also integrating the automated tests. These acceptance tests are run frequently by team members”
(RULE: There is one Product Owner and one Product Backlog for the complete shippable product.)
(RULE: The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/ users and other stakeholders.)
(RULE: All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/ users and other stakeholders.)
(RULE: There is one product Sprint Review; it is common for all teams.)
LeSS Huge:
Multi-site teams frequently create both obvious and subtle frictions and costs that are surprisingly large in their negative impact.
Qualities that reduce the friction of another site include similar time zone, internal dedicated site (not outsourced), developers that are fluent in the same spoken language, a location and culture that highly values long-term hands-on developer excellence.
A Scrum Master must be co-located with their teams.
Each site must feel like a peer, not a second-class citizen.
Sites must be visited regularly and cross-pollinated.
In meetings, strive for face-to-face with video tools.
The use of shared-document tools make it easy for everyone to modify artifacts together and at the same time.
Or in lean thinking, “Where there is no standard, there can be no kaizen.” Experiencing Scrum by the book creates understanding of how Scrum principles and practices relate— a systems-thinking perspective.
Requirements for the initial teams: dedicated— each person is a member of one and only one team stable— the members of the team aren’t changed frequently long-lived— the team isn’t a temporary project team but stays together for years cross-functional— the team has the needed functional skills to achieve done functionality co-located— the team is in one location, often literally at the same big table, so that trust grows through face-to-face communication and learning grows through teaching one another
A perfect feature team is a team that works across the whole system and co-creates the product together with actual users. This is a good yet difficult-to-achieve perfection goal.
One essential concept behind feature teams is to organize and specialize in the domain of the customer rather than the domain of technology. The same concept also guides other LeSS structuring decisions.
A good Scrum Master can handle multiple teams, a great Scrum Master just one. — Michael James
Perfection Goal Ideas
1. The perfection goal is to have a releasable product all the time. Release stabilization periods need to be reduced and eventually
2. Co-located, self-managing, cross-functional, Scrum teams are the basic organizational building block. Responsibility and accountability are on team level. 3. The majority of the teams are organized as customer-centric feature teams. 4. Product management steers the development through the Product Owner role. Release commitments are not forced on teams. 5. The line organization is cross-functional. The functional-specialized line organizations are gradually integrated in the cross-functional line organization. 6. Special coordination roles (such as project managers) are avoided and teams are responsible for coordination. 7. The main responsibility of management is improvement— improve team’s learning, efficiency, and quality. The content of the work always comes from the Product Owner. 8. There is no branching in development. And product variation is not to be reflected in the version control system. 9. All tests are automated with the exception of (1) exploratory test, (2) usability test, and (3) tests that require physical movement. All people must learn test automation skills. 10. Adoption is gradual and evolutionary. These principles are considered in every decision.
But as far as possible, as Product Owner you should decide to ship every Sprint or even more frequently. Why? The reasons include (1) early delivery of value, (2) feedback about the effectiveness of the new features, to adapt better in future Sprints, (3) increased responsiveness to changing business needs, (4) deep improvements in the development group, because the frictions preventing frequent shipping become painfully obvious and require fixing, (5) improved internal motivation among the teams from the feeling of achievement and progress, and (6) increased trust among stakeholders, because of tangible results. Another benefit, proportional to the organizational resistance to change (which is heightened in large groups), is that... Shipping speaks louder than words.
There are no internal dependencies and no dependency management with feature teams that use shared code. Teams can benefit by working together on shared work but wouldn’t depend on the output of the other team. Why? Any feature team can work across the code base for their items. And teams manage their coordination between themselves, applying ideas such as continuous integration, communities, multi-team workshops, and sharing and swapping work.
The habitual mindset is to “fully understand” a requirement before implementation. The irony is that avoiding early implementation prevents understanding. But it’s a strong institutionalized habit— reinforced by having separate analysis groups that don’t also implement. Break the habit with smaller and more frequent meals. “No analysis group” doesn’t mean no analysis, it’s just done by the same teams that implements items.
“We’re not agile. Analysts write use cases and scenarios in Word, record them in SharePoint, and tell teams where the information is, via an email.” “We’re now agile! Product Owners write epics and stories, record them in the Rally backlog, and tell teams where the information is, via a notification.” Of course, it’s a delusion that using new words and tools with new labels means that anything meaningful has changed. Tools aren’t agile.
Mathematics of Done Potentially Shippable = Definition of Done + Undone Work Work in Sprint = Product Backlog Items × Definition of Done Potentially Shippable— All activities that must be performed before the product can be shipped to end-customers. This list does not depend on the skills of the teams or the organizational structure, but depends only on the product. Definition of Done— An agreement between the teams, the Product Owner, and managers on which activities are performed during the Sprint. A Definition of Done is said to be perfect when it is equal to Potentially Shippable. Undone Work— The difference between the Definition of Done and Potentially Shippable. When the Definition of Done is perfect, then there is no Undone Work. When this isn’t the case, then the organization has to decide (1) How do we deal with the Undone Work? and (2) How do we improve so that there is less Undone Work in the future? Items not done yet or not finished— A Product Backlog Item that was started during a Sprint but wasn’t completed. This is often confused with Undone Work. “Not done yet” is a Product Backlog Item that was started but not “done” before the end of the Sprint, whereas Undone Work was never even planned for. When a team has an item that was not finished— partially done— then they ought to feel concerned and discuss improvement actions during their Retrospective. Not started— A Product Backlog Item that was planned for during the Sprint but was never started. It just goes back to the Product Backlog. The team should still find out why and discuss this during their Retrospective.
Split into thin end-to-end “vertical” requirements. DO NOT SPLIT ITEMS INTO INTERNAL DESIGN STEPS! [Plus] It can be integrated, delivered, used, provide value, and give feedback. And the automated acceptance tests never need to be changed.
Even with impossible-to-achieve 100% “accurate” estimates (a contradiction of terms), predictability can’t be assured, because new items must emerge. We sometimes remind our clients, “the only products that might be without change are those without customers.” Thus we want responding to change over following a plan.
Why not use relative points? Using a non-relative unit such as person-days eliminates the synchronization problem explored next. And a different unit may be widely understood or used, meaning less re-education or unit transformation. Also, some groups abuse and distort relative estimates (e.g. linking them to person days, using them to naively compare teams, linking them to targets and bonuses) and then they become meaningless and dysfunctional.
• LeSS Rules •
Sprint Planning consists of two parts: Sprint Planning One is common for all teams; Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items. Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on during the next Sprint. The Teams identify opportunities to work together and final questions are clarified. Each Team has its own Sprint Backlog. Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs.
After working in big groups for years, and observing tons of techniques for coordination across multiple teams, we’ve discovered the one technique that by far seems to work best. Here are the steps: 1. You realize a need to coordinate with team B; 2. stand up; 3. walk to team B; 4. say, “Hey! We need to talk.” We call it just talk.
“for every item in every team, they have written the automated acceptance tests before starting to develop the solution code. Thus, in addition to integrating the code continuously, they’re also integrating the automated tests. These acceptance tests are run frequently by team members”
(RULE: There is one Product Owner and one Product Backlog for the complete shippable product.)
(RULE: The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/ users and other stakeholders.)
(RULE: All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/ users and other stakeholders.)
(RULE: There is one product Sprint Review; it is common for all teams.)
LeSS Huge:
Multi-site teams frequently create both obvious and subtle frictions and costs that are surprisingly large in their negative impact.
Qualities that reduce the friction of another site include similar time zone, internal dedicated site (not outsourced), developers that are fluent in the same spoken language, a location and culture that highly values long-term hands-on developer excellence.
A Scrum Master must be co-located with their teams.
Each site must feel like a peer, not a second-class citizen.
Sites must be visited regularly and cross-pollinated.
In meetings, strive for face-to-face with video tools.
The use of shared-document tools make it easy for everyone to modify artifacts together and at the same time.
Or in lean thinking, “Where there is no standard, there can be no kaizen.” Experiencing Scrum by the book creates understanding of how Scrum principles and practices relate— a systems-thinking perspective.
Requirements for the initial teams: dedicated— each person is a member of one and only one team stable— the members of the team aren’t changed frequently long-lived— the team isn’t a temporary project team but stays together for years cross-functional— the team has the needed functional skills to achieve done functionality co-located— the team is in one location, often literally at the same big table, so that trust grows through face-to-face communication and learning grows through teaching one another
A perfect feature team is a team that works across the whole system and co-creates the product together with actual users. This is a good yet difficult-to-achieve perfection goal.
One essential concept behind feature teams is to organize and specialize in the domain of the customer rather than the domain of technology. The same concept also guides other LeSS structuring decisions.
A good Scrum Master can handle multiple teams, a great Scrum Master just one. — Michael James
Perfection Goal Ideas
1. The perfection goal is to have a releasable product all the time. Release stabilization periods need to be reduced and eventually
2. Co-located, self-managing, cross-functional, Scrum teams are the basic organizational building block. Responsibility and accountability are on team level. 3. The majority of the teams are organized as customer-centric feature teams. 4. Product management steers the development through the Product Owner role. Release commitments are not forced on teams. 5. The line organization is cross-functional. The functional-specialized line organizations are gradually integrated in the cross-functional line organization. 6. Special coordination roles (such as project managers) are avoided and teams are responsible for coordination. 7. The main responsibility of management is improvement— improve team’s learning, efficiency, and quality. The content of the work always comes from the Product Owner. 8. There is no branching in development. And product variation is not to be reflected in the version control system. 9. All tests are automated with the exception of (1) exploratory test, (2) usability test, and (3) tests that require physical movement. All people must learn test automation skills. 10. Adoption is gradual and evolutionary. These principles are considered in every decision.
But as far as possible, as Product Owner you should decide to ship every Sprint or even more frequently. Why? The reasons include (1) early delivery of value, (2) feedback about the effectiveness of the new features, to adapt better in future Sprints, (3) increased responsiveness to changing business needs, (4) deep improvements in the development group, because the frictions preventing frequent shipping become painfully obvious and require fixing, (5) improved internal motivation among the teams from the feeling of achievement and progress, and (6) increased trust among stakeholders, because of tangible results. Another benefit, proportional to the organizational resistance to change (which is heightened in large groups), is that... Shipping speaks louder than words.
There are no internal dependencies and no dependency management with feature teams that use shared code. Teams can benefit by working together on shared work but wouldn’t depend on the output of the other team. Why? Any feature team can work across the code base for their items. And teams manage their coordination between themselves, applying ideas such as continuous integration, communities, multi-team workshops, and sharing and swapping work.
The habitual mindset is to “fully understand” a requirement before implementation. The irony is that avoiding early implementation prevents understanding. But it’s a strong institutionalized habit— reinforced by having separate analysis groups that don’t also implement. Break the habit with smaller and more frequent meals. “No analysis group” doesn’t mean no analysis, it’s just done by the same teams that implements items.
“We’re not agile. Analysts write use cases and scenarios in Word, record them in SharePoint, and tell teams where the information is, via an email.” “We’re now agile! Product Owners write epics and stories, record them in the Rally backlog, and tell teams where the information is, via a notification.” Of course, it’s a delusion that using new words and tools with new labels means that anything meaningful has changed. Tools aren’t agile.
Mathematics of Done Potentially Shippable = Definition of Done + Undone Work Work in Sprint = Product Backlog Items × Definition of Done Potentially Shippable— All activities that must be performed before the product can be shipped to end-customers. This list does not depend on the skills of the teams or the organizational structure, but depends only on the product. Definition of Done— An agreement between the teams, the Product Owner, and managers on which activities are performed during the Sprint. A Definition of Done is said to be perfect when it is equal to Potentially Shippable. Undone Work— The difference between the Definition of Done and Potentially Shippable. When the Definition of Done is perfect, then there is no Undone Work. When this isn’t the case, then the organization has to decide (1) How do we deal with the Undone Work? and (2) How do we improve so that there is less Undone Work in the future? Items not done yet or not finished— A Product Backlog Item that was started during a Sprint but wasn’t completed. This is often confused with Undone Work. “Not done yet” is a Product Backlog Item that was started but not “done” before the end of the Sprint, whereas Undone Work was never even planned for. When a team has an item that was not finished— partially done— then they ought to feel concerned and discuss improvement actions during their Retrospective. Not started— A Product Backlog Item that was planned for during the Sprint but was never started. It just goes back to the Product Backlog. The team should still find out why and discuss this during their Retrospective.
Split into thin end-to-end “vertical” requirements. DO NOT SPLIT ITEMS INTO INTERNAL DESIGN STEPS! [Plus] It can be integrated, delivered, used, provide value, and give feedback. And the automated acceptance tests never need to be changed.
Even with impossible-to-achieve 100% “accurate” estimates (a contradiction of terms), predictability can’t be assured, because new items must emerge. We sometimes remind our clients, “the only products that might be without change are those without customers.” Thus we want responding to change over following a plan.
Why not use relative points? Using a non-relative unit such as person-days eliminates the synchronization problem explored next. And a different unit may be widely understood or used, meaning less re-education or unit transformation. Also, some groups abuse and distort relative estimates (e.g. linking them to person days, using them to naively compare teams, linking them to targets and bonuses) and then they become meaningless and dysfunctional.
• LeSS Rules •
Sprint Planning consists of two parts: Sprint Planning One is common for all teams; Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items. Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on during the next Sprint. The Teams identify opportunities to work together and final questions are clarified. Each Team has its own Sprint Backlog. Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs.
After working in big groups for years, and observing tons of techniques for coordination across multiple teams, we’ve discovered the one technique that by far seems to work best. Here are the steps: 1. You realize a need to coordinate with team B; 2. stand up; 3. walk to team B; 4. say, “Hey! We need to talk.” We call it just talk.
January 13, 2021
A great book with explanation, stories, rules and guideline on how to scale a software production team. I see many issues within our current company explained and solved in the book.
November 13, 2016
Excellent material for anyone wanting to push their agile knowledge farther for medium to larger teams. This could help with any product development (yet of course, is specifically good for software development). This presents a great framework with fantastic experiences to help understand why each piece is included. Anyone who wants to go further for a lot more detail should check out (by the same authors) Scaling Lean & Agile Development and Practices for Scaling Lean & Agile Development. But even this book alone is fantastic. If you're serious about agile thinking, learn this. For those in hybrid situations using other frameworks (such as SAFe) you would still gain a lot from this, even though some specifics will not apply.
Overall, this is a fantastic contribution to product development and helps many leverage the experiences of Craig and Bas. Thanks guys!
Overall, this is a fantastic contribution to product development and helps many leverage the experiences of Craig and Bas. Thanks guys!
July 12, 2022
boring and dry;
some things are extremely dated so you subconsciously start imagining bearded man coding in cobol;
a lot of extremely biased things like 'SAME SITE' policy where people like slaves are sitting together as close as possible feeling each other's bitter sweat and heavy breathing);
when reading shit like that you start wondering if these folks actually worked with international teams working across the globe;
certainly doesn't feel like it.
but again, some things are quite good, basic but worth noting down.
50/50
some things are extremely dated so you subconsciously start imagining bearded man coding in cobol;
a lot of extremely biased things like 'SAME SITE' policy where people like slaves are sitting together as close as possible feeling each other's bitter sweat and heavy breathing);
when reading shit like that you start wondering if these folks actually worked with international teams working across the globe;
certainly doesn't feel like it.
but again, some things are quite good, basic but worth noting down.
50/50
This entire review has been hidden because of spoilers.
October 14, 2023
Good, not great. The book is full of great ideas, but you have to dig in to find them, for the structure is kind of confusing at first, because early chapters keep referencing to later ones. All in all however, I found lots of answers to questions I had about how to scale scrum, so I'm happy I read this book.
April 10, 2023
463-Large scale scrum-Craig Larman-Technology-2014
Barack
2023/04/09
"Large-scale scrum", first published in 2014. It provides straightforward insights into scaling Scrum throughout the project lifecycle, from sprint planning to retrospectives, for enterprise project participants and stakeholders.
Craig Larman, born in Canada in 1958, studied at Simon Fraser University. Together with Bas Vodde, he is known for formulating LeSS (Large-Scale Scrum) and several books on product and software development.
Table of Contents
1 More with LeSS
2LeSS
LeSS Structure
3 Adoption
4 Organize by Customer Value
5 Management
LeSS Product
7 Products
8 Product Owner
9 Product Backlog
LeSS Sprint
11 Product Backlog Refinement
12 Sprint Planning
13 Coordination & Integration
More or LeSS
15 What's Next?
Before entering the 21st century, software development often adopted the waterfall model. In the past 20 years, the workflow of software development has changed a lot. For most software products, people's consensus has become the pursuit of more and faster iterations and is no longer satisfied with releasing a milestone version every six months or every quarter. In addition to accelerating the iteration rate of software updates, the size of the software itself has also increased significantly. So another important topic for the development team is how to better cooperation between different teams. When we talk about agile development, it may be intuitive when the team is small; but when the team grows larger and the engineering complexity increases exponentially, how to manage the project becomes a big problem.
According to the author's definition, a big difference between Scrum and other agile development is that Scrum does not define the rules themselves, but defines some basic principles. Using these basic principles, developers can flexibly formulate a development process that suits their own team and the actual situation of the product. Since principles are relatively more abstract than rules, the flexibility and applicability may be wider. An abstraction is a powerful tool that often means broader applicability. If a method is too detail-oriented, it may have limited adaptability, limiting its use in broader scenarios.
When Scrum was first proposed, it may be mainly applicable to small projects, and when people have achieved certain success in relatively small projects, they will naturally try to apply Scrum to larger projects. At this time, we have to face the situation of multi-team collaboration. Going from single-team Scrum to multi-team Scrum is not a linear change. So the author here specifically proposes Large Scale Scrum strategy.
The proposal of the LeSS model is also based on practice. The first is to have a practical basis, and then extract some guidelines in the experiment; build a framework on the basis of these guidelines; then abstract it into some basic principles. Abstraction is an extremely beneficial tool, and a good abstract model has a wide range of adaptations, making it applicable not only to our existing experiments but also to other models. The same is true for our research, from the special to the general, and then from the general to the special.
In extending Scrum to a large scale In the process of Scrum, the author tries to reduce the intermediate process as much as possible and reduce the complexity of the system as much as possible. In the software system, there are basic principles of high cohesion and low coupling, which are used to deal with the problem of complex software systems. In analogy, LeSS deals with the problems that arise when the development team grows larger. So the strategies we apply in software systems can be similarly transferred to software teams.
In the case introduced by the author, one Scrum task is divided into two Sprints. In each Sprint, the leaders of each team discuss and share tasks. Each team can choose two or three tasks with the highest priority for them, and each team can also exchange according to their actual situation. One of the responsibilities of the person in charge of the entire project is to divide a large task into smaller subtasks and prioritize them. The person in charge of the entire project may not be clear about the details of each subtask, but he should have the best understanding of the overall macroscopic view so that when multiple teams collaborate, they can overlook the entire project from a high level.
In order to solve the same problem, there may be many different solutions, the most important point is that we must be able to implement these solutions. If there is no way to implement the planned plan, the actual value of this plan is debatable. If a good process is not implemented, its significance may not be as good as a general process, but every link can be fully implemented as much as possible. The production management of software is similar to the production management of other physical projects. In the end, one of the important factors for us to measure the quality of this project is its actual output. The principles and strategies introduced by the author come from practice. In the end, if we really want to make it our own, we must think about how to apply it to our own practice.
March 18, 2019
This is an introductory work to the LeSS scaling scrum framework. It explains the principles, rules and guides that should be part of a LeSS adoption.
It's the third book on the scaling Agile topic by Craig Larman and Bad Vodde. They claim the first two books were very specific as to what practices and experiments they used when scaling Agile in many organizations. With this volume they wanted to describe the big picture of LeSS, being the starting point for anyone wanting to get their first view into this framework.
I haven't read the previous two books Scaling Lean and Agile Development and Practices for Scaling Lean & Agile Development , so I can't comment on that.
What I liked the most about this book was the different Guides sections, explaining proven practices and patterns on how to achieve better cross-team coordination, backlog management, systems modelling or architectural workshops. These are clear concepts ready to be implemented by any teams, without having to necessarily adopt LeSS.
There are many scaling frameworks out there, what sets LeSS apart is remaining an empirical process control like Scrum. Leaving plenty of room for teams to adopt practices that suit their context best. In that sense, it lives up to the Scrum framework it comes from.
I can't fault the book much, as it was stated by the authors that it is an introduction to LeSS it doesn't go deeper into important concepts such as Systems Thinking for example.
It will give you pointers to deepen your knowledge by reading other books, if you are really interested in giving LeSS a try in your organization.
For myself, as a Scrum Master I found it valuable because it gave me another angle on the vast subject of scaling Scrum. And I took away some ideas from the Guides I can try to implement in my current organization.
It's the third book on the scaling Agile topic by Craig Larman and Bad Vodde. They claim the first two books were very specific as to what practices and experiments they used when scaling Agile in many organizations. With this volume they wanted to describe the big picture of LeSS, being the starting point for anyone wanting to get their first view into this framework.
I haven't read the previous two books Scaling Lean and Agile Development and Practices for Scaling Lean & Agile Development , so I can't comment on that.
What I liked the most about this book was the different Guides sections, explaining proven practices and patterns on how to achieve better cross-team coordination, backlog management, systems modelling or architectural workshops. These are clear concepts ready to be implemented by any teams, without having to necessarily adopt LeSS.
There are many scaling frameworks out there, what sets LeSS apart is remaining an empirical process control like Scrum. Leaving plenty of room for teams to adopt practices that suit their context best. In that sense, it lives up to the Scrum framework it comes from.
I can't fault the book much, as it was stated by the authors that it is an introduction to LeSS it doesn't go deeper into important concepts such as Systems Thinking for example.
It will give you pointers to deepen your knowledge by reading other books, if you are really interested in giving LeSS a try in your organization.
For myself, as a Scrum Master I found it valuable because it gave me another angle on the vast subject of scaling Scrum. And I took away some ideas from the Guides I can try to implement in my current organization.
November 17, 2020
They changed the name for SCRUM, is now called "LESS for one team" - Craig Larman
What I like in SCRUM is its simplicity, I strongly believe that when it comes to software development complexity must not be managed but must be lowered, always.
This is true for the code but it is also true for the organization around code, the reason for this is simple and is called "the Conway's law".
What I like in this book is how the scalability issue is addressed: not all the companies need to scale and in order to scale you have to simplify.
This framework is not hard at all to implement, the hard part is to find yourself in the situation where you really need it and to build a culture in your organization that can support this framework.
If you think that you need to scale up your product development organization this book is a must read and after the reading I suggest you to think again if you really need to scale or not.
What I like in SCRUM is its simplicity, I strongly believe that when it comes to software development complexity must not be managed but must be lowered, always.
This is true for the code but it is also true for the organization around code, the reason for this is simple and is called "the Conway's law".
What I like in this book is how the scalability issue is addressed: not all the companies need to scale and in order to scale you have to simplify.
This framework is not hard at all to implement, the hard part is to find yourself in the situation where you really need it and to build a culture in your organization that can support this framework.
If you think that you need to scale up your product development organization this book is a must read and after the reading I suggest you to think again if you really need to scale or not.
November 7, 2017
This book was excellent, and it put into perspective a lot of large scale elements, for example, how many teams, Scrum training, Sprint reviews, stability of team members, organisational perfection vision, common definition of done and what happens to undone work. It ended up also comparing the LeSS transformation I was part of to the one that the company I am with currently is preparing, and trying to identify areas of improvement from my previous experience. I also really liked the structure, the guides that the book contains along the way that go in depth on a particular subject, like Product Backlog Refinement or Product Owner relationships. Would wholeheartedly recommend it.
January 8, 2019
Scrum is often said to be as much, if not more, about making organisational dysfunction transparent as it is about successful delivery of products. While this is often not apparent in one team Scrum, once the approach is scaled, with LeSS, then this soon becomes obvious. This book does a good job of highlighting this, offering solutions - using LeSS, obviously - and providing insight into product development at scale. The insight it provides, however, is equally valid for one team Scrum. For anyone looking at how their Scrum team can work successfully within their organisation, it is well worth a read.
October 15, 2017
I was really really tempted to also tag this one "speculative fiction" because that's how hard this is to implement. There are great ideas in here, and I can imagine it working, but I have a really good imagination. I don't blame the book (though it is certainly imperfect: sometimes a bit scattered in structure, uneven in practicality and detail) because I think it outshines most books like it. I cheerfully blame human nature.
May 30, 2017
Great book on the principles and practices behind scaling Scrum. Easy to read and clearly explains the reasoning behind the rules, principles and guides.
Good to use as a starting point when starting on a LeSS journey but even when used outside of the LeSS framework a lot of the lessons are readily applicable. Would recommend this to anyone wanting to learn more about scaling Scrum.
Good to use as a starting point when starting on a LeSS journey but even when used outside of the LeSS framework a lot of the lessons are readily applicable. Would recommend this to anyone wanting to learn more about scaling Scrum.
December 7, 2017
Even if you don't plan to do LESS or you are interested in other flavours of agile than Scrum, this well-written and full of ideas book can be of help.
If you know how to ignore certain parts full of beliefs around team-centric Scrum you will find a superficial introduction to Systems Thinking and causal loop diagrams, a discussion about story splitting and other interesting topics.
If you know how to ignore certain parts full of beliefs around team-centric Scrum you will find a superficial introduction to Systems Thinking and causal loop diagrams, a discussion about story splitting and other interesting topics.
August 5, 2019
Лучшая книга по скраму. Методично объясняет как добиться гибкости, выстроить отношения, повысить вовлеченность и сделать качественный продукт. Обязательна к прочтению.
---
The best Scrum book ever. Methodologically explains how to achieve flexibility, build relationships, increase involvement and make a quality product. A must-read.
---
The best Scrum book ever. Methodologically explains how to achieve flexibility, build relationships, increase involvement and make a quality product. A must-read.
August 1, 2017
Easily accessible description on how to work with many teams developing a product.
A few places contained unneccessary/inproductive bashing of managers and todays organizations, otherwise well writen.
A few places contained unneccessary/inproductive bashing of managers and todays organizations, otherwise well writen.
December 16, 2019
Pretty good overview with a good balance between depth and breadth. Being in the thick of a LeSS Huge roll-out gives great context, so maybe not the easiest entry book for those wanting to get in on the ground level.
May 17, 2020
The style of the book didn't work for me, and I had to abandon reading it half way. It's a decent introduction to LeSS and has good bits of information - the style just doesn't suit me and didn't work for me
June 24, 2017
Как и все книжки по Agile методологиям полна идеализированных взглядов. В целом для понимания концепции LESS достаточно прочитать по диагонали, но не более того. Достаточно большое количество воды.
November 13, 2017
Thanks to this great book I understand the principles of LeSS.
I strongly recommend this book to every person willing to learn a good approach to scale Scrums.
I strongly recommend this book to every person willing to learn a good approach to scale Scrums.
April 10, 2018
Typical agile book, but with wayyyy to many bullet points. Not the best reading experience. Slightly better than SAFe Distilled, but still 3 stars. OK as an intro to Less. No more.
September 13, 2018
Great Book! Lots of tips for scaling without losing the agility and simplicity you had when the company was smaller with fewer people and fewer teams!
November 10, 2018
Good book on agile development
Many practical insights and useful tips. Good to read as a different approach to the Scaled Agile Framework for modern larger organizations
Many practical insights and useful tips. Good to read as a different approach to the Scaled Agile Framework for modern larger organizations
September 11, 2019
Overall enjoyed it, a wealth of good ideas (and a few not so good). Looking forward to reading the next 2 books in the series with more of the nitty gritty around the experiments.
June 9, 2020
I like the story at the beginning of the book. I find it really inspiring and help me a lot in understanding LeSS deeper.
June 10, 2020
It's hard to say that this is anything else than the definitive book on LeSS.
October 25, 2020
A very good introduction to large scale scrum - easy to read and understand.
February 15, 2017
Worth reading every chapter
If you are practicing Scrum and struggling how to scale then this book is perfect for you. If are planning to adopt scrum for large product development then buy this book immediately.
If you are practicing Scrum and struggling how to scale then this book is perfect for you. If are planning to adopt scrum for large product development then buy this book immediately.
August 24, 2020
A great model to scale Scrum
Displaying 1 - 30 of 32 reviews