August 30-31st: The 1st Large Scale Scrum Conference in Amsterdam

The first ever Large Scale Scrum (LeSS) Conference took place on August 30th -31st of 2016.  Budgeted to accommodate around 150 people, it was oversubscribed (around 180).

The event took place in the beautiful city of Amsterdam, in the cathedral style audience hall Rode Hoed.

What you will find summarized below, are the topics that were that were most interesting to me (Gene) personally.   But also, my friend and colleague Vicky Morgan made a thorough recap of the entire event at the bottom of this page.  So, please, spend some time reviewing as well.

Also, please check out:


But first, a few entertaining Kodak moments (hover over images to see who got caught in scope):…

day_2_15

day_2_2day_1_1 day_1_2 day_1_3 day_2_1day_2_11day_2_19

day_2_3

Large Scale Scrum Communities Discussion

There was very high interest from many conference attendees in local LeSS communities.  People wanted to learn how the can ensure continuity of learning LeSS, once they leave the conference and return home.   Since NYC LeSS community is the oldest and the biggest at this moment, I (Gene) was called upon share my experiences of creating and supporting the community.   I covered the following aspects of NYC LeSS community:  Birth/Life Span, Count/Composition/Growth/, Venue/Frequency/ RSVP vs. Attendance statistics, Format, benefits for Local Community, potentials of Global Networking, Communications/Announcements, Public vs. Intra-company communities (pros & cons).

Among many other people that attended to the discussion, the folks from Germany/Berlin, UK/London, Italy/Rome and Finland/Helsinki  seemed to have more interest.  As a an immediate result of that, Berlin LeSS Community was born:

day_3_18

day_3_14

day_3_2 day_3_3 day_3_6 day_3_11 day_3_12

LeSS Bazaar

At the beginning of the conference, all participants were split in multiple teams, with each team working throughout the conference to produce something “shippable”. It could be an idea, a concept, a tool…anything.  At the end of the second day, there was LeSS Bazaar, facilitated by Craig Larman, where each team had to present its product to others.  Each conference member was asked to used “LeSS money” to vote for what they felt was the best product.

day_3_25 open_space_7 open_space_12 open_space_11 open_space_10 open_space_8 open_space_

open_space_3


Event Summary by Vicky Morgan

day_1_4

Self Designing Teams Workshop, by Ahmad Fahmy

  • Forming Communities – Facilitation Techniques – Constellations
  • Discussion vs. Dialogue  – Peter Sengue

Story of LeSS, by Bas Vodde

  • We can go really fast un the wrong direction or slowly in the right direction;

LeSS is about focusing on going in the right direction

  • Shu – ha – ri
    • The original books were written at the ha-ri level
    • New book is at the shu level
  • Framework Prescriptiveness
    • add prescription around the points that create transparency – Scrum does this well
    • LeSS is prescriptive on organizational structure as structure has to be changed in order to have an effective transformation
  • LeSS
    • Basic rules – LeSS rules
    • Guides clarify how you adopt the rules
    • LeSS complete picture
    • LeSS principles are retrospectively added
  • More with LeSS
    • Build your method up – don’t tailor it down
    • LeSS is about how you do scrum with multiple teams vs. one of the product teams doing scrum

Port Of Rotterdam, by Rutger Van Dijk

  • Business value – what’s important and how do you measure it?
  • Simple visual reporting to upper management; do not try to force “agile” reporting onto upper management
  • Exploring user stories
    • Analyzing users and their behaviours
    • Gemba – go see
    • Users visit the team
  • Obtaining Management buy-in
    • Stop building features for management, build for customers / end users; PO has biased assumptions
    • Physically delete stories – indicate symbolically that you cannot build everything
  • Distributed team
    • Team bonding activities
  • Culture
    • How are consultants/freelances treated? Are they “resources” / a pair of hands or valued team members?
  • Hire for mindset
    • Learn while doing
    • Lunch sessions with online courses (plurosite)
    • Pair-programming (with expert)
    • Special code camps
  • This worked:
    • Build what you know will be needed, not what you think will be needed
    • People need to be around to explain why something is needed. If not around then do not build or cancel the sprint
  • This did not work:
    • Every team member working on their own stories
      • Less motivated
      • Less productive
      • No project hygiene
      • Complete disarray
    • Reduced involvement of management (and you definitely need them)
  • The Wave
    • There is no sea without waves
    • Everything is changing all the time
    • Experimentation and learning

 

Owning (versus Renting) Your System, by Craig Larman 

  • We need to own our ideas
    • Employees should be involved with the decisions themselves – leads to employee engagement
    • When you give a person an idea, they are renting the idea and thereby do not own the idea
  • 2014 study: 5 keys to a successful Google team
    • Psychological safety was far & away the most important of the 5 dynamics unearthed
    • The foundation of psychological safety is that team are empowered to ask “why” enabling them to understand “why”, thus enabling teams to own ideas
  • Meaningfulness
    • Connection with real customers
    • Involved In the whole rather than the part (degree that employees are involved in end-to-end
  • Why Feature teams vs. Component teams
    • In LeSS feature teams work directly with real customers
      • This intentionally translates into teams owning the ideas and improving the system
      • In addition to reducing coordination and hand-off waste
  • Local thinking vs. system thinking
    • System Optimizing Goal
      • Although there are many system optimizing goals, what is really important is that the group decides what the system optimizing goal is. This is a very important question
      • Is the current system / team optimized for this goal?
      • What is the behaviour of the organization/system?
    • Why would employees care about the system optimizing goal?
      • Are the team involved in strategy?
      • Are the team directly engaged in owning the idea of the product?
      • Are the team directly engaged with the customer?
      • Are the team just ditch diggers?
  • Owning the answer
    • Why is there 1 and only 1 backlog in LeSS?
      • Team should find the answer themselves

 

Technical Practices In Less. Why Are They So Important And So Hard?  by Terry Yin

  • Organizational agility is constrained by technical agility
  • Technical agility = people problem
  • Organization
    • Self-leading teams instead of maximizing resource utilization
      • Resource utilization – utilization of what people already know – known-known
        • Delivery culture
        • Prevents learning from happening
      • Focus on known-unknown instead of known-known
  • Education
    • Help people to overcome the CS cliff
    • Be the village
  • Model
    • Adopt the craftsmanship metaphor
      • Craftsman model
        • Apprentice
        • Journeyman
        • Master
    • Don’t cheat too much
  • Technical Excellence
    • Iterations: product > feedback > improve
    • Practice & More Practice
    • If the organization doesn’t promote practicing then you cannot have technical excellence

 

Impact Mapping with Innovation Games, by Gojko Adzic

  • Squirrel-driven product management
    • Agile at scale – BBC – 75M  spent with no clear definition of benefits
    • Large scale failure – FBI Case delivery system $450M spent before discovering something was wrong
    • Status report was green and occassionally amber for years
    • Analysis: 10000 inefficiencies in the system. Nobody was following any process. The only reporting was reporting on delivered activity
  • Scrum reporting focuses on delivery activity – delivered user stories/ features / burn-up & burn-down charts / velocity / story points
    • velocity reporting = this many people working this many days of the week.
    • Story points = how much money you have spent
  • Underpants gnomes progress reporting (story points)
    • Phase 1: Collect underpants
    • Phase 2: ?
    • Phase 3: profit (lagging indicator)
  • Study: 1/3 of initiatives delivered expected results. 1/3 no visible business impact, 1/3 = damaged the organization
  • Can we find something to report on that is indicative of success? Anton Zadorozhniy.
  • Successful initiatives tend to change somebody’s way of working.
  • Doug Howard – “How to Measure Anything”
    • People measure what they think is easy to measure
  • Impact map  = visualization of the plan.
    • Helps visualize what you are doing and why you are doing it
    • Helps solve underpants gnomes reporting problem – report on achievements instead of delivery reporting
    • Helps with business analysis in general (business analysis often fails as you analyze an option that someone else had already chosen [Tim Brown])
  • Innovation Games: Impact Trump Cards
    • A lot more options to analyze behavioural changes
  • Open Impact Mapping

Leave a Reply

Your email address will not be published. Required fields are marked *

Please help us fight spam. Lets make sure you are not a robot !!!