Introduction to Large scale scum (less) by Bad Vodde
"Bas Vodde is an experienced coach in agile and lean development (with a focus on Scrum and LeSS). He enjoys debugging organizations and has served on the leadership team of a large telecom product. He has worked for years on the largest LeSS Huge adoption he is aware of – large groups require patience. He also enjoys the actual software development and is an active contributor to Open Source (mostly in C++ and Ruby)" Source:http://less.works/misc/about.htmlIt was an interesting story telling (not lecture ,not Talk,it was .. a story telling) about history about roots of Less and its evolution based on experiments. He used unusual way to do his talk as instead of show slides and talk through various aspect of LeSS ,he decided to do story telling with 2 slides and video of fireplace to make atmosphere for real story telling. He explained his approach that "every talk about Framework is boring" and he believes that story telling is more interesting way to do introduction.
- Scrum is an Empirical process control. His journey with Scrum on Large Scale based on various experiments that he described in his book (more than 600) .
- It is very important to do Overall retrospective.
- According to Bas ,Less can works even with 2500 people but it is a bad idea and we should do it.
- There was problem with Scrum from day 1 because scrum was Designed for 1 group only.
- On LeSS website,you can find case studies about adopting LeSS. However these case studies are written in unique way as they are experience report where they talk about ...experience. I need to check this as I wonder is it more interesting way compare to classic marketing blablabla.
- One product has one backlog .You can read more about it here: http://less.works/less/framework/product-backlog.html
- Dynamic of software development (feature team and daily build) .Component teams for example front end and back end team. Problem is when feature. Async due unbalance between front end and Back end . Planning is not a solution. Split into feature teams from component teams.
- Gaining experience with Scrum is similar to Aikido. In Aikido like in Agile you start as beginners who follow given receipt, in middle you learn when you can break rules on master level you don't need rules, you create your own.
- Don't write book, because it is a pain in the ass. It is not Scrum related, but it seems many speaker who is author of famous book hates ... writing a book. I wonder, if is a requirement to be good speaker to complain about writing book .
- Scrum master is full time job in Less.
- Coordination role is not a role as it takes responsible out of the team.
- Less rules has 3 pages. They are split into 2 pages for small team and additional page for large teams (more than 8). Rules can be found here: http://less.works/less/rules/index.html . To be effective, though, the set of rules has to be small, and must be clear enough that it can easily be understood and remembered.
- Bas said that they don't want any rules in LeSS, but they must be some basics rules to help people on beginning. Rules in Scrum came from retrospective. It is the same in LeSS. Retrospective is a key element of Scrum/less because it helps you to constantly add , remove and adapt rules to allow team work better and better. This is reason why LeSS gives minimum principles/rules,because additional rules should came from feedback on retrospective.It is easier to have fundamental rules and add on top of them rather than tomes of rules and tailor them down as you don't know enough on beginning what you don't need. I think ,that is one of the most valuable element of LeSS because different project/team/company has different needs and these needs change due changes in team and projects.
- Meta principle is lean thinking(itself is bigger than agile). It was an interesting point, but I forget what was about it.
- Large scale scrum is Multiple team scrum (LeSS in not scrum on team level) . Multiple team scrum (less) vs Scrum of multiple teams. (Other frameworks).
- Sprint Bazaar is a .I never heard about it before bit it is interesting idea . More explanation can be found here: http://less.works/less/framework/sprint-review.html
- Spring planning 2 are different LeSS (Multiple team scrum) in comparison to Scrum of multiple teams. If you are interesting ,you should read these articles : http://less.works/less/framework/sprint-planning-one.html and http://less.works/less/framework/sprint-planning-two.html
- Spring review is a parallel activity.
- SaFe sucks . I have no idea what safe framework is but it sounds like waterfall with 'agile vocabulary' . It seems most people I met so far really don't like Scaled Agile Framework (SAFe).
- Multi-team plan meeting is good if many teams works on the same feature.
- Clarification is a team responsibility .
- Architecture community rather than architect role. I don't agree with this partly . I prefer to have an architect whose response is to take care of fundamentals of project and focus on high level vision of architecture . There is an amazing book that explain that in details called .
- Less avoid roles assignment. I believe that some role assignment should exist . It helps efficiency of team , specially that some people likes/hate do specific thing.
More about Adventure with Agile can be found here : http://www.adventureswithagile.com