14 November 2015

What I learnt from 007: Evening Session - Large Scale Scrum (LeSS) by Craig Larman

I went to meetup "Large Scale Scrum (LeSS)" by Craig Larman .
Event was organized by Adventure with Agile.

Craig Larman:
"He serves as an organizational design consultant, with a focus on organizational redesign and systems thinking, for flexible, high-value-throughput product organizations. His emphasis is Large-Scale Scrum, and scaling agile principles and practices and lean thinking to very large, multisite, and agile offshore development (often, embedded systems, telecommunications, or investment banking), and coaching executive teams to succeed with larger enterprise-level agile and lean methods adoption."

It was quite interesting QA session ,when people asked more or less interesting question with very useful answers from Craig Larman. I like also introduction by organizer  who said that "meetups are about Learning and making connection".

What I learnt :

  • Many people ask about changing organization to adapt Scrum.
    • Craig responded that In order to succeed you need start from flip organization system before start Scrum and Less. He added later that problem with organization is an organization . You need change organization before changing Scrum.
  • They was question was How to start with Less ?
    • Craig started from bullet point about and then add that It depends on size of team . You should start for up to 50 people with One backlog , one product owner, because in Less always have one backlog and one product owner.
  • Some people asking about Tailoring down rules as many frameworks has many many rules.
    • Craig said that one reason of the main reasons to create Less was that Tailoring down hardly ever works. Tailoring down fails over and over and over again  , so he used opposite approach which is Tailoring up (scaling up) , because more you learnt from retrospective more rules you apply. This is a reason why core elements known as less rules are on 3 pages only. He learnt in order to start with framework rules should be as small  and descriptive as possible and then scaling up as you get more and more experience . Craig called this as "barely sufficient methodology".
  • Less is very simple and as it based on  Shu Ha Ri learning phases (from Aikido):
    • First , You follow kata.
    • Second , You mastered kata and ask for exception.
    • Third you create new katas.
  • Scrum team is not a IT team , it is a solution team.
  • Less worships customer not code. He said "My mother don't care about microservices , she want to watch  a movie on Netflix. When you focus on architecture ....then you lost a plot".
  • Some people asked about skills needed to be a great Scrum master. 
    • Scrum Master  must have a social network and political power  to do things and influence changes. 
    • Patience
    • a lot of humour
    • It must follow a 11th rule of system thinking which is "there is not blame".
  • I was expected to hear some punchline against SaFe  and this almost didn't happen with one exception when somebody asked about SaFe, then Craig said that he has almost no experience with SaFe so he can not say anything as for him Safe is a just a traditional waterfall with fancy agile vocabulary :)
  • Less rule 1 product owner  ... that has 2 main focuses
    • product vision
    • priorities
  • Team focus on clarification and something else that I forgot :(
  • Performance based bonus are counter-productive and root of all evil. According to research, it has signification factor in decrease of the  performance. Sadly is very popular in finance based companies and team and scrum master should do reduce harm caused by performance bonus as much as possible .
    • If you cannot eliminate , you should move performance bonus from personal to team .
    • Performance based bonus is root evil .
  • Sprint planning 1 should have timebox of  45 minutes or less.
  • On question about How Less work with distributed team Craig said that answer is in 2nd LeSS book, chapter 12 to make multi site teams (he said that answer will take 1,5 hour).
  • Continues integration is to integrate continuously . It is not a building tool but It is a behaviour.
    • Naming wise, people should replace Continues integration with integrate continuously to avoid confusion with building tools!
  • In XP you commit your changes in shortest cycling time which is usually 1 TDD cycle:
    • Write 1 test 
    • Write small amount of code ,
    • Refactoring
    • Commit
    • (and it should go through rest CI process)
    • This should happen every several  minutes.
    • If u do slower than 30 minutes then u don't integrate continuously.
    • CI system it is run 24/7
It was quite interesting meetup.

Less -  http://less.works
Adventures with agile - http://www.adventureswithagile.com