Scaling Agile - LeSS Framework

Scaling Agile Scrum in Large Organizations – Exploring LeSS Framework Dec 2015
© 2015 by Vijay Kumar R
Scaling
Agile Scrum
Problems with Scaling Agile Scrum in
large organizations - exploring LeSS
framework for solutions.
Vijay Kumar R
The views and conclusions in this document are those of the authors and should not be interpreted as
representing views of any organization, either expressed or implied.
Keywords – Scaling Agile Scrum, Agile, Lean, Scrum, LeSS framework

Over the last decade, Agile development methods and in particular Scrum has
revolutionized software development practices. Most software product
development organizations ranging from startups to large scale product
development organizations, have moved away from traditional waterfall model
and have adopted Agile Scrum practices in one form or the other. But not all large
scale product development organizations have seen the desired results. When
asked about reasons many organizations say, we have seen some positive results
but not significant improvements, and some say, Agile Scrum is not for large
organizations it’s recommended primarily to small organizations whose teams are
co-located.
When probed further with the Agile Mentors and Coaches from these large scale
product development organizations, a common set of problems gets called out,
such as:
 Do Agile rather than Be Agile – Scaling to Lean-Agile practices is not just about
moving the development to an iterative model. Even though the development
is moved to an iterative model, still having a large set of supporting processes
follow traditional sequential model will push the overall adoption to some kind
of water-scrum-fall model. To support iterative development, internal
organizations that manage process, people and fund need to exhibit the same
level of agility. Feature teams working on the products should be able to
quickly decide on how to move forward based on continuous feedback and
learning from users, customers and market. Bottlenecks that hinders the
decision making processes needs to be identified and addressed. For
successful adoption of Agile product development it's important for
organizations to be Agile than do Agile. Organization need to have the
organization structure that supports agility and continuous learning, by
embracing Agile values and principles.
 Adopted framework or process does not suit the organization's needs – Most
large organizations have globally distributed teams working on products which
have huge volume of features with dependency on multiple products and
components, but the framework or process they follow doesn't address the
fundamental issues, instead the framework or process prescribes adding more
roles, jargon's, complexity and management wrappers. A top down approach
of mandating adoption of a particular Agile Scrum framework or process for
scaling Agile Scrum without having analyzed the organization’s needs will lead
to failures, some of the fundamental issues that needs to be addressed in

managing large product development are - overall organization structure that
enables quick decision making, cross-functional feature team structure which
works for distributed teams, transparent communication, co-ordination
required between multiple feature teams, managing dependencies and
planning efforts required with globally distributed teams.
 Loss of overall product focus - In some organizations each feature team
working on the same product follow their own sprint cadence with a plan to
integrate with other dependent features as they are closer to deployment. In a
few other organizations, even though the feature teams working on a product
follow a single sprint cadence, they have separate backlogs, different practices
and multiple product owners with different prioritization constraints. With
each feature team working in silos and no regular communication with other
feature teams working on the same product, the focus of each feature team
gets limited to their set of product backlog items, thereby, losing focus on the
overall product and it’s goals. With multiple backlogs and product owners for a
single product and no single owner to the overall product vision, individual
module design and architecture are often handled at individual feature teams,
which might or might not match the initial product vision.
 Fixed release dates - By having a pre-determined fixed release dates
organizations add lot of extra checkpoints, processes, effort and co-ordination
roles for ensuring the fixed release date is met, as missing the release date
would mean waiting for the next pre-determined date to deliver the feature,
this approach leads to a mini water fall model with 2 weeks sprint cadence.
Having pre-determined release date does not encourage teams to integrate
the potentially shippable features regularly. Integration gets pushed to the
later sprints of the release and last minute trade-offs are done based on how
much each dependent teams have been able to deliver at the time of
integration. The focus shifts from delivering the prioritized customer-centric
feature to delivering feature that is ready to be released by all dependent
feature teams. Unless, it's a brand new product getting released to the
customers for the first time, product owners should be able to decide when to
release the prioritized individual feature for their product, wherever required
in alignment with dependency features as well.
 Continuous improvement and learning put on back burner - In many
organizations Agile Scrum adoption or Scaling Agile Scrum is considered as a
project, once the framework is perceived to be adopted and it attains a
sustainable pace of delivery the transformation project is considered complete

and the adopted framework or process becomes a one size fits all process. One
of the basic pillar of Lean is continuous improvement and continuous learning,
Agile/Lean adoption is never finished, similarly, Scaling Agile Scrum at a large
enterprise needs to be a continuous journey which is iterative and adaptive.
In this paper, I have explored how Large-scale Scrum (LeSS) framework addresses
the mentioned problems.
Why Large-Scale Scrum (LeSS)
LeSS suggested organization and feature team setup
Most traditional large organizations are structured around functional groups like
analysis, development, test and delivery, distributed across multiple sites like test
group in one city, development group in another and so on. The development
teams are further divided to component teams formed around architectural
modules, technology, etc. Each of these functional and component teams have
separate reporting structures resulting in separate priorities and measures. Any
feature that has to be developed in this structure involves lot of handoffs
between each functional and component group, large co-ordination efforts, more
defects and delay in overall integration.
For a single product, organize related product backlog items into requirement
areas and organize feature teams by requirement areas. A requirement area is
customer centric delivering customer value, which has nothing to do with
Large-scale Scrum is Scrum, it is not "new and
improved Scrum". Rather it is regular Scrum plus
a set of suggestions which have been successful
in large multisite, multiteam and offshore Agile
development. Developed by Bas Vodde and
Craig Larman, it's a framework for software development to inspect and adapt
the product and process when there are many teams. It reflects Lean thinking
which is pivotal to continuous improvement. When compared to other
frameworks LeSS is scaling Scrum without adding layers or processes, it's non-
prescriptive, and merely gives suggestions.

business vertical, component or architecture. LeSS suggests organizing feature
teams around customer value and avoiding functional/component teams. It's
important that a feature team is self-managed, cross-functional and co-located
which is empowered to take all the decisions necessary for the successful delivery
of a complete customer-centric feature across all disciplines (analysis,
development, test and delivery). In some cases component teams might still be
needed to deliver stories outside the scope or responsibility required by feature
teams to deliver the overall feature. The goal should be to create a maturity path
towards possibly eliminating the component teams through simplifying and
consolidating software architecture to reduce the learning curve for team
members to pick up the new skills and knowledge.
While setting up feature teams, avoid having team members of a feature team
dispersed in multiple sites/location. Multiple feature teams can be co-located in
multiple sites but it's ideal to have all the team members of a feature team to be
co-located. Prefer co-locating related features teams at a common site.
In addition to functional and component teams there are specialization groups
like configuration management, build/integration teams which over a period of
time tend to become bottleneck. LeSS focuses on less structure. LeSS prefers
organizations to expand the existing feature teams responsibility to include
activities involved with configuration management and continuous build and
integration, instead of creating more complex organizations with single
specialized groups.
While, it's important to ensure feature teams are empowered, self-managed,
cross-functional and co-located. It's pivotal for all team members (including
developers and testers) feel they are part of a single feature team. Try having a
single measure for all feature teams working on the product and for all members
of the feature team.
Whole product Focus
One of the dominant problems in scaling Agile is loss of a single product vision
across all teams working on the product. LeSS scaling elements are focused on
directing the attention of all of the teams onto the complete product instead of
individual parts/modules.

LeSS provides two large-scale Scrum frameworks:
LeSS - For a customer centric organization delivering customer value, it's
imperative that the entire product team has a single vision and focus of the
product. Having one product owner who owns the vision for the complete
product, road map and business plan supports the whole product focus. In
addition to a single product owner, there needs to be a single Product Backlog
shared by all teams working on the product, which is being continuously
reprioritized to optimize the overall system for customer delivery. An iteration or
sprint in Scrum is for the entire product, with the goal of creating a shippable
product increment at the end of each sprint/iteration, it’s important that all
feature teams working on the product has a single "Definition of Done" and follow
one iteration/sprint cadence. PO of the product decides the priority of the
features getting scoped into the sprint, each individual feature teams picks the
stories that are part of the customer-centric prioritized features. Each individual
feature team will own their sprint backlog. LeSS suggests sprint planning,
retrospective and reviews to consist of two parts: first part common for all
feature teams working on that product while the other is usually done separately
for each team. Each feature team working on the product regularly checks in their
part of the code to common centralized repository and no feature is complete till
all dependent code is integrated and tested resulting in a potentially shippable
product increment.
LeSS Huge - LeSS Huge builds on LeSS framework, all the suggestions listed for
LeSS framework applies to LeSS Huge. LeSS Huge framework is suggested for large
product groups (more than 8-10 feature teams) that need to subdivide for
manageability. LeSS Huge framework divides teams based on requirement areas
focused on major areas of customer requirements, rather than on architectural
subsystems. The framework introduces Area Product Owners (APO) in addition to
one overall Product Owner (PO) for the product to enable scaling. PO is
responsible for the overall product-wide prioritization and deciding which teams
work on which requirement area. He works closely with APO's. Each requirement
area can have four to eight feature teams and one APO. PO and APO synchronize
frequently.

Communication and co-ordination
Given the fact that Large product development organizations have multiple
feature teams working on a single product with feature teams spread across
multiple cities, LeSS suggests a few changes in standard Scrum meetings and
communications to keep the focus on the overall product and to ensure there is
transparency between all the involved parties by being aware of the vision,
overall architecture and implementation:
 Product Backlog Refinement - LeSS suggests an overall Product Backlog
refinement before the individual feature team backlog refinement with
representatives from all the feature teams and APO’s working on the product
with the main intent of detailing the features to all feature teams, coming up
with initial estimations and identifying required dependencies. After the overall
Product Backlog Refinement, individual feature team conduct the backlog
refinement with all the feature team members and customers/users.
 Design workshops - LeSS suggests joint design workshops with SME's, technical
leaders and representatives from all feature teams involved with the
development of the product being designed. During these workshops members
use whiteboard to detail the design, identify constraints involved at the overall
product level and also at the individual feature level and make decisions
pertaining to the design. This workshop is not for PowerPoint presentations. If
teams are located at multiple sites try digital whiteboards or video sharing. This
is not a one-off workshop conducted at the beginning, the idea is to
continuously evolve the architecture/design as the product moves through the
development.
 Sprint Planning - LeSS suggests Sprint planning in two parts, the first part of the
sprint planning session with the overall Product Owner and atleast two
representatives from each of the feature teams working on the product. Second
part is conducted independently by each individual feature teams on their sprint
backlog with all feature team members and Scrum Master.
 Scrum of Scrums - Try "Scrum of Scrums" where representatives from each
feature team working on the product team gather at least twice or thrice a week
to discuss on cross-team dependencies, concerns and progress. The format of
"Scrum of Scurms" is similar to Daily Scrum meeting.
 Retrospectives - LeSS suggests an overall retrospective and individual team
retrospective. In Retrospective attended by all members of the individual
feature team, Scrum Master and Product Owner, the goal is to explore what the
teams should start doing, stop doing and continue to do, to get better at

delivering customer value. In the Overall Retrospective attended by Scrum
Masters and representatives from each feature team, teams explore issues
specific to overall organization, processes, knowledge sharing and co-
ordination.
For any discussion, workshop or meeting to be effective, it's imperative that team
members actively participate and efficiently utilize the available forums.
Managers need to encourage, more direct communication between developers
and testers who are part of the feature team, communication between feature
teams working on the product and remove any barriers affecting this seamless
communication. Also, teams needs to take a closer look at the meetings and their
overall value add. Besides standard Scrum meetings avoid non-value adding
meetings, invite team members to meetings only if their inputs are absolutely
required. For mass communications or information sharing try emails instead of
meetings.
Continuous Integration and Delivery
LeSS suggests growing a system rather than building a system, building a system is
about building separate components and assembling them together when
finished on the other hand growing a system implies evolving a system iteratively
to a larger system. Avoid making large changes to stable system, instead, break a
large change to smaller change sets and integrate regularly to the stable system.
Continuous integration (CI) is essential for scaling Lean and Agile development in
large organizations. For scaling Agile practices, build and test need to be fully
automated, the more time it takes to integrate changes to the central repository,
less frequently developers will integrate their code. CI is a developers practice, CI
requires a change to the daily habits of all developers. With short cycles, manual
regression testing is nearly impossible. Iterative and incremental development
implies that code is not frozen at the end of the iteration but instead has the
potential to be changed each iteration. Therefore, manual regression testing
would mean rerunning most of the manual test every iteration. Automating the
tests therefore pays back quickly. With a fully automated continuous integration
system, team members integrate their work frequently (each member integrates
at least daily), leading to multiple integration's per day. Each integration needs to

be verified by an automated build (including test) to detect integration errors
quickly.
While Continuous Deployment is about revealing (releasing) the completed
feature to the end-user, Continuous Delivery is about making sure the feature is
ready and tested enough to be deployed to production. Not all organizations or
products require Continuous Deployment, but, Continuous Delivery is pivotal for
scaling Agile with the goal of making feature ready to be deployed on production
with the click of a button. Only when the code is continuously delivered/deployed
successfully to a production like environment, product owners will have the
confidence that the feature is ready to be deployed to actual production with the
push of a button whenever the business is ready for it. Continuous Delivery
enables PO's to have more control on deciding the timing of the feature release
instead of aligning to an operations defined pre-determined fixed release date.
Also, in case of failures, it makes the decision to rollback easier, as the PO knows
he can deploy the feature anytime when it is ready again instead of waiting to a
pre-determined fixed release date.
CI and CD practices are in the right direction of Scaling Agile in large organizations,
however, without addressing some of the basic disciplines, organizations might
not be able to see the desired results.
 Prefer Small Changes - Avoid having large changes to a stable system, small
changes increase control and visibility. There are multiple ways to split large
stories to smaller ones like split by use case, split by scenario, split by success
or failure scenarios, split by operations and many other ways. While most say a
story should be small enough to be marked done within a two week sprint,
there is no one size to which the story size should be limited to, it depends on
the maturity of the team members of the feature team, complexity of the
feature and many others.
 Feature Toggles - Implementing feature toggles provides an alternative to
maintaining multiple feature branches and also, provides a mechanism for
development team to turn-off a failed change and leaving the remaining
turned-on in production. Feature toggles let developers continuously integrate
features while they’re under development. Also, feature toggles enables
product owners to toggle and expose a set of features to selected or all end-
users.

 Code quality - The single most efficient way to attain quality and reliable
software is to ensure code is tested at a unit level and reviewed incrementally,
this helps prevent defect leakage into later stages. Organizations need to
ensure adherence to the process of getting unit tests successfully executed,
completing code review before code is checked into the repository and a strict
set of coding guidelines is adhered to. While this may appear to be top-heavy,
it has the huge payoff of producing quality code. Test completion including
unit tests should be part of definition of done, if testing slides out of a sprint
and is done later, it takes 2 to 5 times the effort to complete testing outside a
sprint as inside a sprint.
 All changes needs to be backward compatible - All pieces that make up the
feature, Code, Database, Content and Infrastructure needs to be designed for
being backward compatible and tested for backward compatibility. Versioning
of content, configs and database changes is an important aspect of ensuring
backward compatibility. Having automated test cases cover backward
compatibility scenarios as part of the regression, will provide confidence for
individual feature teams to revert back the changes in case of build failure or
turn-off the feature because of dependency issues.
 Shared Definition of Done (DoD) - Having one shared DoD for the entire
product ensures all the feature teams working on the same product have a
common set of activities to complete for ensuring a story/feature is "done".
Individual feature teams can expand the shared DoD to include steps to better
deliver their features/stories. The goal should be on incorporating only value-
adding activities/steps which the feature teams has to focus in order to
efficiently deliver the product with quality. DoD needs to evolve as the product
moves through multiple iterations and as the feature teams mature.
Continuous Learning and Improvement
One of the primary reasons component and functional teams were preferred was
because of their ability to specialize in a particular domain, function or
component and sharing of knowledge and learnings within the team. In scaling
Agile Scrum as organizations move towards organizing cross-functional and cross-
component feature teams around the product, the need for Subject Matter
Experts (SME's) around a technology, architecture, approach and standards needs
to be addressed. "Communities of Practice" (CoP's) provides an in-formal
platform for like-minded or like-skilled group of individuals who voluntarily come

together because of their passion and commitment around a domain, function or
component specialization. CoP's span more than one product/project and allow
SME's to share experiences, coordinate effort, and maintain their own sense of
identity.
Often organizations who treat Agile/Lean scaling framework or process adoption
as a project, quickly jump to the conclusion that the framework or process is
successfully adopted and the process is “optimized” enough. By concluding the
project, they stop looking for regular feedback to make improvements to the
process and optimize further. Without regular optimizations, over a period of
time, they become dysfunctional. One of the Lean's pillar is Continuous
Improvement - no matter how good a process is, it can always be improved or
perfected and that the workers doing the job are the best people to figure out
how to do it better. Retrospectives are a great way to identify bottlenecks from
people who use the process/framework daily. Organizations must encourage the
practice of having regular retrospectives and active participation. Identified
bottlenecks can be anything ranging from skills, tools, process, and organization
structure, Scrum masters and Managers should ensure the identified gaps or
bottlenecks are addressed in a timely fashion, without which team members will
not be encouraged to actively participate in retrospectives.
Avoid having external Agile consultants who have very limited or no knowledge
about the organization process and its products as coaches. Instead, try pairing
external Agile consultants with internal potential coaches so that internal
potential coaches can gain by the experiences from external coaches and use
them with the context of the organization and products. Encourage Scrum
Masters or Managers within the organization to take up the role and coach
others.
Conclusion
Organizing people for Scaling Agile requires a lot of organizational and cultural
change to support rapid iterative development to deliver customer value. Scaling
Agile Scrum at a large enterprises is a continuous improvement journey by
inspecting and adapting to an organization structure that supports agility and
process/framework which enables the enterprise to deliver value to its customer
without losing the focus on Agile principles. There are many enterprise Agile

frameworks for scaling Agile/Lean Scrum in large organizations like LeSS, SAFe,
DaD, Scrum-at-Scale, etc, each of these frameworks have their strengths and
weak points. Just a top down approach of mandating a framework leads to adding
unnecessary roles, structure and complexity resulting in chaos. LeSS doesn’t just
focuses on development team and process optimization, but also looks at the
entire organization and seeks to make fundamental changes in culture, structure
and optimization in any organization involved with software development. LeSS
holds true to the principles of Agile and Scrum.
References
[LeSS Website] http://less.works/less/framework/index.html
[Book] 2015 - Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde
[Book] 2010 - Practices for Scaling Lean and Agile Development - Craig Larman,
Bas Vodde
[Book] 2009 - Scaling Lean and Agile Development - Craig Larman, Bas Vodde

Scaling Agile - LeSS Framework

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a Scaling Agile - LeSS Framework

Similar a Scaling Agile - LeSS Framework (20)

Último

Último (20)

Scaling Agile - LeSS Framework