Contents
This lecture focuses on the light-weight LeSS framework. It bases its learning from the scrum guide which is strongly recommended reference to understand the base principles for LeSS to a scaled out version. Learn about the structure of the framework and some of the ceremonies that define it and what makes it so scaleable.
Big Picture
LeSS Framework
Less framework was created in 2002 and formalised in 2010 by Bas Vodde and Craig Larman their objective was to apply scrum in a large-scale context. LeSS can be scaled from a minimum of 2 teams to a maximum of thousands. It is regarded as light-weight and highly scaleable. There are two flavours Less and Huge Less.
LeSS is a light-weight scaled Scrum framework designed for organisations to scale up the small scrum teams into larger scale scrum without losing its momentum or value. Scrum framework does not change at all, the pillars for Transparency, Inspection and Adaptation, as well as Scrum values and artefacts remain the same. What is different is the collaboration and communication between the scrum teams and alignment towards a common goal. All roles in the Scrum team remain the same.
LeSS Mindset
Less bases its big picture on four main practices: Experiments, guides, Frameworks (Rules) and Principles. These are discussed below:
Less adopts a Shuhari mindset, this is a three stage process where shu we create and repeat our known experiences or disciplines until we gain full understanding and mastery of it. In Ha once we have mastered our techniques and processes we can innovate. Finally in ri we allow the creative journey to begin. This is the basis for experimentation to master and explore; and learn from the known experience of others.
The Guides are a mixture of both Experiments and rules that support the empirical process. The guides offer organisations values on how to adopt LeSS into there setup, offering tips and experience to improve the level of agility.
There are three areas of the LeSS framework: Less Huge Structure, Huge Product and Sprint.
Less provides some rules on its LeSS, this is more granular detailing the setup for the frameworks. It details the structure, the Product, and the Sprints. These are a list of rules on how each component is set up, some of the roles within the group as well as the mindset. The other part of the rules are based on the two frameworks of LeSS.
At the heart of LeSS are 10 core principles, that offer a guide on the practices and approach when adopting LeSS in an organisation.
Each of these practices enable the organisation to embed the right practices when adopting LeSS, this helps to build the understanding from the offset and build from firm foundations.
LeSS Framework
There are two frameworks one obviously called LeSS and the other LeSS Huge. The latter is smaller scale framework supporting upto 8 teams and the other LeSS Huge is highly scaleable supporting upto 8 plus teams. Both frameworks are underpinned by the LeSS Rules.
LeSS Rules
LeSS Rules form the structure of the discipline driving it from its foundations for the LeSS frameworks in order to support the empirical process. The rules itself revolve around a product-centric approach and the rules itself are split into 3 main areas: LeSS structure, LeSS product and LeSS Sprint.
i Teams:
self-organised
Cross functional
Co-located
long-lived
Customer-centric feature teams
ii Scrum Master:
Dedicated Full-time role
Supports 1-3 teams
Supports Teams and Product Owner
Supports organisation
Supports development practices
iii Structure
Managers optional
practice Go and See
LeSS structure from the offset
i Shippable product:
One Product Owner
One Product Backlog
ii Product Owner:
Supports mulitple teams
Works with Customers and Stakeholders
Responsible for prioritisation
PBI's Clarification with teams
iii Definition of a Product
Broad definition of products
iv Definition of Done (DOD)
One Definition of Done for whole team
Each team has its own DOD
Perfection goal to improve DOD
i Sprint Level:
One Product Level Sprint
Starts and ends at the same time
Each team has its own Sprint backlog
ii Sprint Planning:
There are two sprint planning parts
Sprint planning 1 and 2
iii Sprint Planning One
Common for all teams
Attended by Product Owner
Attended by Team of Teams
iv Sprint Planning Two
Common for each team
Creation and design of Sprint Backlog
Perfection goal to improve DOD
Queueing Theory
Managing batch sizes, limiting queue lengths, reducing batch sizes and managing 'waste' are elements of Queueing theory. In LeSS these variables are introduced to be able to take a quantative or economic validation on processes or flow of processes running through the system.
Queueing Theory is often associated to Kanban and kanban metrics by forcing a pull system by setting work In progress limits (WIP) and applying Little'law we can do three of the following things:
1. Visualise the workflow
2. Limit work in Progress (WIP)
3. Reduce batch sizes
4. Manage Queue lengths
Empirical control Process is based on relying on experience or observation alone without due regard for system theory an empirical basis for the theory. The building for expertise and specialism in the area and using the Scrum pillars for Transparency, Inspection and Adaptation requires a non-formulaic response. This is due to the unknown quanitites to drive an evolving understanding based on what we know rather than what we dont, this is the key to Empirical Control Process. LeSS Rules help us to mature towards that goal.
System Thinking
To understand the working of the system is imperative in order to have a stable shippable product with no bugs and defects. System Thinking is to understand the system and its behaviour, the design its working to reduce the system unknowns when the system does not behave as expected. Taking s system approach would be remove the impediments by understanding the system, its interconnections and its dependencies.
LeSS adopts an approach towards root cause analysis rather than quick fixes will improve the delivery performance.
Lean Thinking
Lean thinking empowers decentralising decision making so that right people can make the right decision at the right time and not become a bottleneck to the flow. Delivering value to the shortest sustainable lead time requires the flow to be continuous waiting on decisions will only lead to waste or delays.
Continuous Improvement
Waterfall is based on phase gate milestones, this is where the analysis, design and build is tested before a demo is given to the users. SAFe takes a view that if we take a phase gate approach we compromise the value stream achieving its goal and delivering the right benefit.
By adding integration points with system demos allows a more economic benefit to be realised early and the right approach taken at the earliest point. The benefit of integration points on working systems facilitate learning towards optimal solutions.
Customer Centric
LeSS takes a strong Customer focus approach based on the customer needs and focus towards What the customer wants mandate is at the forefront for the feature teams. So taking a more customer-centric approach rather than developing components is vital. LeSS distinguishes the role of the Product Owner and the teams as the facilitator of the customer-centric approach by connecting the teams with the customer. The team in return do detailed analysis with the customer.
Whole Product Focus
LeSS Framework takes a product-centric approach where there is only one Product Owner, one Product Backlog and finally one potentially shippable product. Having focus on the product ensures the values are realised only once the product is integrated.
More With Less
This is regarded as the heart of LeSS, the objective is to create simpler solutions without the added complexity of procedures or roles to enhance the process. Adding more roles can only lead to a reduction of responsibility and removing the unwanted or necessary steps will yield more focused and realised solution.
Transparency
Lean thinking empowers decentralising decision making so that right people can make the right decision at the right time and not become a bottleneck to the flow. Delivering value to the shortest sustainable lead time requires the flow to be continuous waiting on decisions will only lead to waste or delays.
The decision making process is broken down to empower teams to make strategic decisions and be responsible.
Roles and Responsibilities
The three main roles inside scrum are:
Scrum Master Scaled Product Owner Feature Team - Dedicated: This is where a team member is dedicated fully to a single team.
- Cross Functional: Team that has members that have all functional skills to deliver one potentially shippable product.
- Co-located: This is where a team member resides locally with another, for example in the same room or office.
- Long-Lived: This is where the team will never be changed, they are long-lived to produce one shippable product. They are geared towards maturity and continous improvement.
The Scrum Master is the Servant leader where the main goal is to serve, unlike Scrum, in LeSS a Scrum Master can serve upto 3 teams. In LeSS it is considered a full-time role rather than a part-time one. The scrum master main focus is the development practices, the Product Owner, the team and finally the organisation. They also advocate the agile mindset and practices to both the business and feature teams by coaching them through the agile journey. The facilitate and lead LeSS adoption
They align themselves to remove any impediments or blockers that may arise in the process and actively ensure the facilitation for scrum activities or ceremonies throughout the process. Roles of the Scrum Master is highlighted below:
Product Owner
The Scrum Master works closely with the Product Owner in a coaching capacity and assists them in improving the quality of their work and provide quantifiable guidance on benefits to be accrued on the future landscape. The Product Owner should not be totally dependent on the Scrum Master.
Feature Team
Teams work closely with the Scrum Master, however, in order to be a self organised team, the Feature team acts as a whole and bear equal accountability for their work. The journey for the team is towards maturity and reduced dependency on the Scrum Master, who may have multiple teams to support. The scrum master provides guidance and coaching to the wider team, takes a hands-off approach allowing the teams to take up their responsibilities.
Development
Scrum Master is often armed with a really strong technical expertise, also based on their experience can engage with teams to adopt new practices to improve the quality of the product for the customer. Allowing scrum masters to improve the technical journey in terms of development tools and practices are deemed of high importance in LeSS.
Organisation
For LeSS to work in organisations they must adapt to the agile mindset, practices and Less principles. The Scrum Master would work alongside organisations to take them through this journey.
In LeSS supports a Whole Product focus concept and therefore there is only one product owner for a potentially shippable product across multiple feature teams. There is also only one Product Backlog, and the product owner is the single owner of the backlog, every item needs to be authorised and approved by the PO before it will go into the backlog for prioritisation. Main duties for the Product Owner include:
They align themselves to remove any impediments or blockers that may arise in the process and actively ensure the facilitation for scrum activities or ceremonies throughout the process. Roles of the Scrum Master is highlighted below:
Prioritisation
Prioritising items from the backlog ensuring a customer demand is being met.
Backlog Grooming or clarification
Maintaining the backlog is one of the main tasks for the product owner. Ensuring user-stories are created are accurate and contain acceptance criterias and have clear business value and old user-stories are removed. They act as a connector not a intemediary and faciitate a true connection with users or customers. A Product Owner will understand the product and be a passionate advocate to the cause.
Story Mapping
Working with stakeholders to create user-stories are also vital. Having accurate stories enable the development teams to deliver exactly what the user wants. Story mapping is a technique that allows stories to be created at epic level.
Writing user-stories
User-stories are a subset of story mapping - the single unit of a feature to be developed. Generally stories created are based on the behavioural approach where customers behaviours are captured in terms of the requirements. These are delivered by the Feature Teams but approved by the Product Owner.
Story walkthrough
Once requirements are captured these will need to discussed with the development teams for delivery, the Product Owner will ensure the requirements are clear and the right representatives are present.
Liaise with scrum master
The Product Owner and Scrum master work closely together, particularly during the Sprints, the Product Owner considers the Scrum Master a coach and will take advice on tools and techniques inside the remit of their role.
The Feature teams are self organised and cross functional teams that are empirical in nature and support a shared goal. They are responsible for the execution and delivery for the Sprint backlog items for one potential shippable product. The emerging detail is defined and developed as an increment of 'Done'. They all share equal responisibilty for all the teams work and are accountable as a whole.
The Feature teams will translate the user-story prioritised from Sprint Planning 1 into functional and non-functional low level requirements. The developers are empowered to make day to day decisions according to their area of expertise. All sub-tasks for the user-story are created, all dependencies are defined and all test documents are prepared during the Sprint Planning 2.
The feature team supports 4 types of structure
Sprint Planning
LeSS supports two Sprint planning parts called One and Two respectively, these are split into the What and How with the Sprint Planning meeting being the shortest one.
Sprint Planning 1
In Sprint Planning 1 the Product Owner prioritises the backlog, with the high desirable features decided from the business. The designated team leaders for each of the Feature teams (can be anyone in the team except for the Scrum Master) will attend the meeting. It is designed to be light and very high level of detail at this stage.
The features are decided between the team leaders and delegated to each other, the whole feature teams will be accountable for this delivery so a team goal is set in order to focus the team the deliverable.
Sprint Planning 2
In Sprint Planning 2 the feature teams take the prioritised and agreed items from Sprint Planning 1, and create the final Sprint backlogs for each of the allocated teams. The Product Owner is not present in this meeting. Each Sprint backlog is identical to that of the Scrum Sprint Backlog containing all the user-stories accepted into each sprint. Each user-story is discussed, formalised and outstanding discussions arise in terms of any gaps and dependencies.
There is one level sprint so All sprints start and end at the same time for each of the feature teams.
LeSS Definition Of Done
One of the most common issues that arise from software development is software bugs, poor quality coding, functionality not meeting user requirements. LeSS takes an approach where we can define what 'done' looks like in terms of a potentially shippable product, in the form of Definition of Done (D-O-D). There are two levels of D-O-D, at feature level and at product level.
As a collective, the business and feature teams define what D-O-D should look like during the initial Product Backlog Refinement (PBR), this often involves some outside technical authority such as technical architect, team specialists and tester. Once this has been agreed, all software developments are measured on this accordingly when calibrating to a shippable product, with the objective of adding it to a release and part of the product increment. These guidelines ensures that the product is stable and technical fit for purpose.
1. Feature has passed all acceptance criteria
2. Feature integrated into clean build
3. Feature has no bugs or defects
4. Feature passed all regression tests
5. Feature has been code reviewed
6. Feature has tested all non functional requirements
7. Feature passed integration tests
8. Feature promoted and tested Pre-prod environment
9. Feature is supported by relevant documentation
Product Backlog Refinement - PBR
In PBR epic level features and discussed, shaped and created as User-stories. These 3 levels of PBR; Multi team, Single team and Overall PBR. Once user-stories have been created and in D-O-R status, they can be prioritised accordingly to decide which priority items the feature teams should work for future sprints. Prioritisation normally happens at the start of Sprint Planning 1. Product owners will set up an prioritisation meeting, this will involve relevant stakeholders, business reprsentatives and relevant heads, here estimated priority items are discussed and the priority order decided and user-stories tagged.
It is usual to apply a 80:20 parato rule for items in the sprint backlog, therefore, the product owner will be mindful that some contingency needs to be applied to the workload. So bulk of the items prioritised will be about 70-80% and will be deemed as the must haves
It is vital the Product Owner has a groomed backlog in order to ensure that no priority work is left out, the backlog must also be ordered with th last priorities defined by workshops that may have arised up to the point of prioritisation.
Sprints
These are timeboxed events which starts off with a goal and ends with a commitment or an objective that has been met. These timeboxes are based on fixed time and fixed costs, only the scope of what comes into the sprint can be compromised. The objectives form the deliverables for an increment of 'Done' in terms of the Definition of Done. Based on Agile principle No 5 this personifies the nature of a sprint to deliver software frequently.
Agile Principle #3 ".. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale .."
The Sprints run sequentially, and a prioritisation meeting occurs before the kick off. Sprints run sequentially one after the other, there is no break in between. Here the emerging detail is shaped and executed by the scrum team members. In principle once the sprint has been committed no items should be added. Only scope can be re-negotiated.
The duration of a sprint is generally from 2 weeks to 4 weeks, anything longer is deemed to slow down the rate of development and reduce the predictability of scrum events. The structure of a sprint is shown below:
The diagram above describes where the scrum ceremonies discussed earlier sit within the sprint. During Sprint planning the Sprint Goal has been created, this objective is accepted by the scrum team and focus will be maintained to achieve this. In the early phase of the sprint user-stories committed as a result of the sprint planning are being understood by the team, any gaps uncovered are resolved quickly, sub tasks created to show some transparency on the work to be done on the analysis or development started. For effective monitoring all team members log the time start on all activities and when they finish. This will help the scrum master understand the work remaining.
Conceptually, sprints can be split in to 3 parts sprint execution, Integration and finally QA, the diagram below shows the main structure of some of the high level activities during the sprint and the scrum team members involved.
