A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one
A feature is able to take in a customer feature (requirement) and handle it end-to-end and in this way capable to deliver value iteration by iteration.
Most teams are not feature teams. There’s an attempt to create a cross-functional team, but that team does not possesses the skills necessary to implement a customer-centric feature end-to-end.
Traditional organisations are composed of component teams – a component team specialises in one particular line of work.
A feature team organization exploits speed benefits from specialization, as long as requirements map to the skills of the teams.But when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint. Feature teams balance specialization and flexibility.
In large traditional structured organisations the number of component teams is huge: a sub team for each and every ‘phase’ of the project or system involved:
marketing / business concepts, business analysis, functional analysis, copywriting, visual design, user interaction / user experience design, technical analysis, technical design, front-end development (subteams by technology), back-end development (many subteams for each component or layer), network, server-system infrastructure, mainframe systems, webserver, etc – the list is long.
There’s a terrible overhead and waste in coordination, hand-overs, communication.
Coordination Chaos:
Creating true feature teams is a major and important step in the organisation’s redesign to become agile.
Generalizing specialists
The team itself is cross-functional, this means that the team as a whole requires the skills to implement the entire customer-centric feature end-to-end.
People within the team have multiple specialisation (skills): you need to ask and encourage (incentive) your team members to have secondary, tertiary skills. If the people don’t have those other skills, apply co-learning techniques.
Scott W. Ambler coined the term “generalizing specialists” to define the need for multi-disciplinary team members.
Scaling Scrum addresses the questions/challenges that arise when applying Scrum (Agile) in a significant context: an organisation or project with multiple teams and possible multiple products. The scale can vary from a few teams to dozens of teams (e.g. a few hundred or even thousands of people). As such a framework for ‘Large scale,’ Scrum should scale indefinitely. The challenges/issues involved are cross-team coordination, organisational design, impediments resolution, backlog refinement and building one integrated product. Said, all the challenges you face in 1 team Scrum, but on a (much) large(r) scale.
The first advice given is: do not scale Scrum, do not multi-site! If you can create your software product with one team, go ahead and work with one team.
Large Scale Scrum (LeSS) can be called a ‘framework’ for scaling Scrum, but rather it defines a set of additional rules and guidelines. These rules are very much aligned with Scrum and feel very natural. LeSS does not introduce an extra detailed process layer on top of Scrum. In that perspective, LeSS is very straightforward and lightweight.
Large Scale Scrum = Scrum. This is rational and recognisable but does not take away the challenges. This is aligned with the vision of scaling Scrum by the official Scrum institutions: get basic Scrum right for your teams, scale only if necessary. Scale professional Scrum. Transparency is the key element to success. Unfortunately, most (large) organisations are very un-transparent in most things. A scaling Scrum framework remains a framework (not a one-size-fits-all solution) for complex product development. Teams will need to apply practices and methods and measure work empirically.
LeSS and LeSS Huge
LeSS: Up to eight teams
LeSS Huge: Up to a few thousand people on one product
LeSS clearly defines building one integrated product with 1 product backlog. Sprint planning part 1 happens with all teams (or with team representatives). The Sprint Review is for all teams to review the potentially shippable Product Increment together. The focus is on the whole product. An Overall Retrospective does not exist in standard Scrum. Its purpose is to retrospect the previous Sprint (s) from a product perspective cross-team.
LeSS Huge provides a set of rules for a setup with a lot of teams – the ‘tipping point’ is ~ 8 teams, but it rather depends on the feeling and workload of the product owner. Suppose the product owner cannot handle the workload anymore to own his backlog. In that case, LeSS Huge provides an answer by introducing ‘requirements areas’ (a set of customer-centric feature areas) with an additionally responsible product owner per requirement area.
Flip the system
A key takeaway is that top-level management support is required to transform an organisation to become influential in agile product/software development. As such, this is not new, but essentially – in the context of Large Scale Scrum – this implies the ‘go’ or ‘not-go’ decision.
A LeSS consultant talks to the management to discuss the required changes in organisational design and good engineering practices. If the management is not convinced or does not acknowledge the need for such changes, the LeSS adoption would be a ‘no-go’.
An adoption flips the organisational system for one particular product (or product group), not for the whole organisation. When the adoption of this 1 product is successful, you continue to spread to adopt the way of working to other organisation products.
Adoption
A part of the course addresses the adoption and the preparation involved to adopt LeSS. The path to agility is a path of continuous improvement. There is no perfect time to start agility; rather, ‘initiation’ of the transformation to agility can begin at any time.
There are different views on when to start the first Sprint: you can start right away (knowing you will not be able to produce a potentially shippable product increment at the end of the first Sprint), but you deal with it empirically and transparently during your sprints.
On the other hand, you foresee a preparation period that involves activities to get started:
Educate everyone (including management)
Design cross-functional (feature) teams and create feature team adoption maps
Define the 1 definition of done
Make the product owner, an actual product owner
Keep project managers away from the teams
The preparation includes the setup of any facilities, systems, etc. With good practice, you have a solid basis to produce working software (according to the definition of done) at the end of your 1st Sprint.
The course
The Certified LeSS Practitioner is a three-day course, quite interactive. Craig organises his course by explaining some content, immediately followed by an individual, team exercise or in-class example. We’ve exercised lots of mind mapping to recapitulate what we’ve just learned and an activity on causal-loop modelling. After the course, I’ve created my overall mindmap of the course contents, which I’ll use as a link to explore other topics. Both Ari Tikka and Ahmad Fahmy were present during the course. They have both experiences adopting LeSS (Ari in Nokia Networks and Ahmad in Bank of America Merill Lynch).
Craig takes time to address almost every question, or concern raised or parks it with consideration. He emphasises core Scrum and empirical process control very much (as he should).
Craig breaks the course in unequally time-boxed pauses and spices it up with miscellaneous valuable and useless stuff and quite a few bad Canadian jokes (no further spoilers mentioned here) J
Each participant received a copy of the scaling books + print-out of the slides (the slide deck is about 300 slides). Any particular multi-site or offshore agile development issues are part of the resources but not addressed in the course. Most large organisations have some offshore/nearshore development ongoing (or past this, after lots of misery) – it would have been exciting to get some more explanation or guidelines on this topic.
Certification
After completion of the course, you are a Certified LeSS Practioner. The Scrum Alliance also accredits the course as an added qualification on the topic of Scaling Scrum Fundamentals.
Resources
The site http://less.works provides a lot of info on the framework. It’s much recommended to read the material on the site (it contains a lot): minimum minimorum of the LeSS rules, but mostly read the LeSS framework, principles, and structure.
Craig Larman and Bas Vodde are agilists with lots of experience in Scrum and scaling Scrum/Agile. Craig focuses on organisational redesign and systems thinking and serves as a consultant for large-scale Scrum and enterprise agile adoption.
Craig and Bas have authored the following main books on Scaling Lean and Agile development:
This article expresses my view regarding the Large Scale Scrum (LeSS) Practitioner course, given by Craig Larman – March 2015, Brussels. In case of any remarks or questions, don’t hesitate to reply.
“Lean coffee” is een meet-up format waarbij de agenda door de aanwezigen bepaald wordt:
elke participant kan items voorstellen om te bespreken
elke participant kan stemmen op de items; de items komen aan bod in de volgorde volgens de meeste stemmen
de discussie tijd is beperkt (vb. initieel 8 minuten)
stemmen: nadat de tijdspanne voorbij is, kan elke participant aangeven wat hij er van vindt (goed => verder gaan met de discussie, middelmatig, of slecht)
als er consensus is om hetzelfde item verder te bespreken, kan dit, maar met een kortere tijdspanne (vb. extra 5 minuten); anders gaat de discussie over tot het volgende item
in een kanban (in zijn meest eenvoudige vorm: “to discuss”, “discussing”, “discussed”) hou je een overzicht bij van de flow van de items
de aanwezigen kunnen notities nemen, indien gewenst
(optioneel) op het einde van de lean coffee, kan je de belangrijkste bevindingen distilleren
Lean coffee kanban
Voor meer info over de “antwerp lean coffee” (georganiseerd door Patrick Steyaert en Arlette Vercammen), bezoek antwerp.leancoffee.org (in tegenstelling wat de naam doet vermoeden, gaat dit op verschillende locaties door en niet enkel in Antwerpen).
