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

http://less.works/less/framework/index.html

http://www.amazon.com/Large-Scale-Scrum-More-Craig-Larman/dp/0321985710

http://www.amazon.com/Practices-Scaling-Lean-Agile-Development/dp/0321636406

http://www.amazon.com/Practices-Scaling-Lean-Agile-Development/dp/0321636406

http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961

scaling agile - less framework

Software