In many ways, the journey to Large Scale Scrum is as colossal as the scale of the Golden Gate Bridge.
My 2017 goal is to become a certified trainer for Scrum, Nexus, Large Scale Scrum(LeSS), Scaled Agile Framework® (SAFe®), Enterprise Scrum(ES) by year end. Disciplined Agile potentially in 2018, who knows. Call it my perfection vision, perhaps unattainable but a good North Star. Why? Because in my work, my clients must really feel that I am independent and that I will support them having educated them on the options, once they make their own decisions. I cannot claim to be good with ES as it is so new, but I have dabbled with the others since they came out. I love agility, so I prefer to grow good sustainable agility, and often end up with a mish mash of what’s right for the client, at least what I and the client think is right. I find it useful to have enabling constraints such as frameworks to frame discussions and choices before a mish mash gets considered though. I worry about off-piste for practical support reasons. I get fantastic engagement at mini-workshops where colleagues get educated on and consider options.
Why such a colossal scale for LeSS alone? Well, for any of my case studies to qualify for Large Scale Scrum, I and my client need to understand that a LeSS adoption implies formally eliminating (within the scope of the LeSS adoption):
- the existing single-function groups (business analysts, architects, component teams, testers, UX, …), traditional single-function roles & career paths,
- the existence of projects and the use of project managers, no team Product Owners, no team Product Backlogs (PBL), no “PO BAs” etc., and
- reforming to true Feature Teams that are full stack, the Feature Teams doing the interaction & refinement with real users/customers, etc., i.e., it is a deep structural organization design change, not a practice.
I’m told that LeSS Huge “adoptions” can take ten years as they are prone to get reset by regime change every so often; new leaders who revert to Theory X and have to be convinced about Theory Y. As I’m no Henrik Kniberg, my half-life at an organization is only 9-12 months typically. So I have to ensure I develop internal capability so other people see the journey through.
I don’t let the above pre-conditions get me down. I say whatever will be will be. I just need to be careful to avoid saying an implementation is LeSS worthy unless the judges of Certified LeSS trainer certification decide so. Previous case studies of mine were not deemed LeSS Like (Nexus+). I qualified on the 2nd bullet, but the 1st bullet was beyond my scope even if we did implement Scrum Development Teams in true Scrum fashion. The 3rd bullet was a bridge too far.
Indeed, at my latest client, where there is strong third party presence, each third party with their own organizations, the 1st bullet is beyond my reach, the 2nd bullet would be possible only if agreed, and that last bullet is only attainable for brand new work, as the in-flight disruption of “throwing teams in the air” with 3-4 months of dev time left might also be a bridge too far. I’m hopeful that Toyota Kata will be used.
“It always seems impossible until it’s done” – Nelson Mandela
I wrote blogs posts on SAFe and Nexus+ already. See:
There is plenty of information on LeSS at less.works so I won’t regurgitate it here.
I read the three LeSS books more than once. I read the blogs. I attended numerous talks by Craig Larman, and one by Bas Vodde. I avoided LeSS as I felt that while it set organization design as a pre-requisite, it did not provide solutions for organization design that satisfied my own criterion – dealing with people in a humane way, e.g., preparing people for “flipping the system”. In 2012, I recommended LeSS as the most beautiful approach for Scrum only, with some caveats about the people side of things. With the advent of Nexus, the exoskeleton of Scrum, in 2015, I became dubious about LeSS being the fairest of them all. Nexus’s simplicity to me was its genius.
Spotify’s approach is not a model or framework. My heart sank when Spotify only got an honourable mention this year in the Version One report. I wonder how close ING and NetFlix implementations were to Spotify really. I would customize for the context of course, but I’m wondering if any truth got lost. Hopefully not. My heart sank, even more, when Scrum of Scrums took 27% of the market and SAFe took 28%. So, to me that means Scrum is corrupted in 55% of the market at least. I thought it was 90%+. Maybe it is. The LeSS folks seem unworried by the drop from 4% to 3%. Let’s see if the partnership with Scrum Alliance gives LeSS a boost. And let’s lighten up this post with some good news.
I was dubious before I attended training by Bas Vodde in San Jose earlier this year. But, here were my positive light-bulb moments:
- “Take a bite” reminds me of Black Swan Farming.
- There is an openness to the use of Toyota Kata to bring about evolutionary change, change that is part of the normal daily work. I already add it and I’m glad that’s encouraged.
- Diverge-converge/merge approach encouraged, e.g., during systems modelling exercises
- System Modelling is a retrospective technique to attain a better common understanding. In fact, actions from retrospectives are not encouraged, perhaps because they become “shoulds” that simply won’t happen. My approach is to use mini-kaizen events during the retrospective time-boxes, as I picked up long ago that in “JFDI” cultures, actions don’t happen.
- General management may want to “help” when change comes from the top. “Avoid people with little or no technical expertise”. For example, Bas might ask you which version control system do you use. If you don’t know the answer….
- Avoid commercial electronic tools to force leaders to “walk the gemba” at the place of value creation (and at the place of value consumption I guess)
- While multi-site and co-located teams are supported, dispersed teams are not supported.
- Sprint length 4 weeks for COBOL and the likes, 2, weeks for Java and the likes, 1 week for Ruby, Python and the likes. No 3-week sprints, tongue firmly in cheek :).
- Sprint planning is two separate meetings, part 1 and part two. Sprint goal is not part of LeSS but you’re free to use it. No joint commitment from Sprint Planning.
- No concept of Development Team in LeSS. Instead, there are Teams.
- Product Owner does not clarify requirements. The Teams talk directly to users and customers.
- Product Owner acts as a matchmaker between customers and Teams, usually just for introductions. The Product Owner is less involved in follow-through conversations. LeSS Product Owner cannot become overwhelmed/over-worked, as that’s a road to perdition.
- No solution to time zone problems, they “just suck”.
- LeSS Scrum Masters cannot also be developers. Scrum Master is a full-time role. LeSS Scrum Master also coaches on engineering practices.
- LeSS doesn’t minimize dependencies. Synchronous dependencies between Feature Teams are encouraged. However, minimization of asynchronous dependencies is encouraged.
- “Component team organization is a waterfall organization” is the view of the LeSS inventors.
- Delay learning until it’s needed instead of forcing learning early. I’m not surprised, but I still see trainers being asked to “sheep-dip” people in training to demonstrate progress with something:(.
- Try “fake Product Owner” to start to avoid real Product Owner seeing a chaotic mess in the early days.
- For LeSS all at once, one needs credibility. But LeSS Huge all at once is not recommended. 50 people approx. or one requirements area at a time is recommended.
- 4 finely grained Product Backlog Items(PBIs) per team per sprint, with 3 sprints of look-ahead. More than 4 leads to analysis paralysis. So for 8 teams in a requirements area or LeSS (non-Huge), there would be 96 detailed PBIs; let’s say 100. “
- No notion of epics or features, just PBIs, which are either finely grained or coarsely grained. If you have Jira, delete all issue types other than one for normal PBIs (call it “Item”).
- Leave defects in the defect management system if you have one, don’t duplicate. We don’t want to make the PBL unmanageable.
- Some really cool tips to simplify parental relationships between PBIs (ancestors) – go to the course to find out more.
- If every requirements area optimizes its own performance it could be a disaster – aligns with my experience of the “Beer Game” so not such a light bulb, but worthy of comment.
- Requirements Area are dynamic. It’s a scaling technique. Product Owner decides which areas teams work on, on an “as needs basis”.
- “Get rid of QA department”. That was said I’m sure in light of “no role safety, just job safety”. Some of the best professionals I know are testers.
- LeSS Huge “adoption” takes 5-10 years. Aggression depends on continuous integration / continuous delivery readiness.
- With Products, we don’t know the scope. It’s a long-lived thing. Projects are harmful to products. A product portfolio is strategic, it is not a super batch of requirements like a programme/project portfolio.
- Line management has the greatest influence on the “definition of done”. Scrum Masters have less impact of removing impediments to improving the “definition of done”. LeSS encourages (teaching & coaching as opposed to command & control) knowledgeable technical managers, like in Germany, where managers often know more than developers technically. Suggestion for two teams is one line manager, one Scrum Master.
- Product Owner has the greatest influence on investment in test automation, continuous integration, continuous delivery. Don’t enhance DoD in all teams at the same time.
- For LeSS Huge, expanding DoD beyond a Team is useful to force co-ordination.
- Huge Product Owners rarely touch the Product Backlog. Area Product Owner is just a granularity of Product Owner; it is not a hierarchy.
- Don’t be a nice Product Owner. But still be a nice person.
- Continuous Integration doesn’t mean Jenkins, it means continuously integrating (not leaving code checked out for two weeks).
- Write Product Backlog Items as Outcomes or Goals, not solutions.
- Huge Product Backlogs can be split due to complexity but only once that complexity becomes painful. Filtering of the overall PBL to get an APBL should be the default option.
- Priority of Feature in Requirements Area does not have to be the same as the priority of mother feature in overall Product Backlog.
- Consider un-splitting PBIs to avoid polluting BL with too many details (making it unmanageable), e.g., immutable and mutable profiles instead of CRUD (create, view, update, delete). Un-splitting is APO responsibility.
- Typical to use ancestor like splitting in Requirements Area Backlogs to make backlog more manageable.
- LeSS estimates are in hours, as they’re less corrupt if gamed. If using points, use retrospective reference items that area already “done”. Use historic work all teams can relate to, to set sizing reference points. This overcomes ideal time’s/story points lack of correlation with lead time (without limited work in progress), as being historic hopefully we remember/track the actual lead time.
- Release sprint is acceptable (“if a terrible idea”). The notion of an “undone department” is better.
- Product Owner is allowed to overrule Team at Sprint Planning but if that happens it’s usually a sign that something is amiss.
- UI/UX is in the sprint. There is no dual Scrum concept like say UI/UX working one sprint ahead.
- No code branching. Integration multiple times per day drives co-ordination. “Communicate in code”.
- Have bazaar style sprint reviews but schedule times so people don’t get half-updates or cause unnecessary disruption.
- Co-ordination approach is “Just Talk”, supported by “communicate in code”, “travellers” (people who change Teams if accepted by receiving Team), scouts, and “component mentors”.
- Must at least have gitlab & github. Mercurial is better for larger code bases.
- Communities (with no authority to force a decision on the entire group) as opposed to communities of practice. Good representation is important. Line management needs to set expectations of 10% time allocation to communities. Bas is uncomfortable with communities presenting at the bazaar of the Sprint Review as it dilutes focus on the product.
- Recommended – innovation games, impact mapping, specification by example
- LeSS rules can and should be broken. I say that with tongue firmly in cheek, but it’s funny because it’s (almost) true :).
In summary, I can tell that LeSS is ten years old as it is well thought through. It still lacks on the people front to my mind. I think that’s where my own agility change chef (and my competitors) work helps.
For me, LeSS edges Nexus, and Less Huge blows away Nexus+ from a Scrum perspective. Modified Nexus blows away SAFe to my mind for Scrum, XP and Kanban (see my previous Nexus posts). Both LeSS and Nexus blow away SAFe from a Scrum perspective. But, being technically better never won markets. Can one do it? Agility is just a means to the end. Many forget that. One has to be careful in a niche, as niches are also prone to disruption. Perception is sometimes more important than reality, and for some, it is the
As I said earlier, I will support whatever the client decides, having educated the client on the options to the best of my ability, hopefully minimizing confirmation bias, with the client and I together considering the context.
I look forward to Craig’s course in July in Madrid. I hear it has a different style. Let’s see.