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

• 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
  • https://Github.com/impactmapping