large scale agile_svante_lidman
TRANSCRIPT
![Page 1: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/1.jpg)
Driving Large Scale Agile
Transformation
Svante Lidman
[email protected] I have changed employer since
I made this presentation. You
can now reach me at
see: www.hansoft.se for what
we do.
![Page 2: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/2.jpg)
This presentation
• Patterns and anti-patterns for transforming an organization with
huge legacy in product, process, and culture to being lean/agile
• Based on:
– Experience in the large over the last 18 months
– Experience in the not quite so large over the
previous 25 years
– Hearsay, reading
– Thinking, trying to generalize, evolve, reformulate
• It is the story as I see it, others may have other
stories
![Page 3: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/3.jpg)
Outline
• Introduction
• What’s the deal with large scale agile?
• Case study
• Conclusions and advice
![Page 4: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/4.jpg)
What’s the challenge with large scale agile?
• Given a large organization, potentially distributed,
potentially large legacy in product and culture,
what do we need to focus on?
• Practices?
• Organization?
• Tooling?
Individuals and interactions over processes and tools
![Page 5: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/5.jpg)
What’s software development after all?
• Software development
– A cooperative, Finite, Goal-Seeking Group Game (Alistair Cockburn)
– I would add creative and evolving (Svante)
• Software is intellectual property, hence…
– Developing software is an intellectual achievement, hence...
– ... to create an effective SW development organization it is key to:
• Maximimize the extent that everyone’s intellect is engaged and aligned
• Eliminate disturbances that disallows people from being fully effective
intellectually
![Page 6: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/6.jpg)
Outline
• Introduction
• What’s the deal with large scale agile?
• Case study
• Conclusions and advice
![Page 7: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/7.jpg)
The case in question
• Product development unit in a large multi-national company:
– Thousands of developers
– Single product line
– Large legacy system
– Distributed, component-based organization - waterfall process
– Highly successful commercially and of fundamental importance to the
bottom-line of the company
– Fierce market competition
• If it ain’t broken why fix it?
![Page 8: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/8.jpg)
Pain – a prerequisite for change
• Pain
– Increasingly difficult to get even small features
developed with reasonable lead times
– Quality through sweat and tears
– Development capacity not matching the business
opportunities
• We want to do more!
![Page 9: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/9.jpg)
Cause of pain
• Functional organization
– Analysis
– Software development
– System testing
– Waterfall process and an organization that defines
itself in those terms
• Handovers and functional/component breakdown
– Few persons understand the whole product
– Few persons understands the whole process
• Focus on resource utilization by upfront planning Fredrick Winslow Taylor
Insight: We can’t patch on the waterfall anymore
and get what we want, we need to do something
different
![Page 10: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/10.jpg)
Building the vision for lean / agile
• Stories that people can
relate to
• A simple message
![Page 11: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/11.jpg)
The Vision Summarized
• Change to a setup where feature development is
driven in a program decoupled from release projects.
This is called Streamline Development.
• Implement true cross-functional feature teams with
responsibility for a feature from analysis through end
of feature verification
• Enable agility on the team level (Self-organization,
Stand-ups, Iterations, Retrospectives, TDD,
Continuous
Integration and so on)
![Page 12: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/12.jpg)
Key Ideas of the vision
• Focus on flow, customer-to-customer
– It is more interesting to reduce lead-time with constant productivity than to improve productivity with constant lead-time
– It is more interesting to improve quality with constant productivity than to increase productivity with constant quality
• This will expose inefficiencies and force:
– Reduction of handovers
– Reduction of delays
– Reduction of overly detailed studies and gold-plated designs
– Eradication of late and non-repeatable testing as a way to get quality
• The focus on lead-time will act as a forcing function to address quality and efficiency
![Page 13: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/13.jpg)
Objections to the vision
• We have special needs
– It is a very large code base, a single designer cannot learn all
– Some subsystems are complex and requires substantial experience
– Many different technologies, it is too difficult to learn them all
– Some features are very large and span the whole system a single
team cannot handle such a feature
– Weak code ownership will deteriorate the integrity of the code base
– It is a complicated domain, experts need to do analysis and design
• That stuff doesn’t work
– We tried that 7 years ago and it didn’t work
– Organization X tried that 4 years ago and they dropped it
![Page 14: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/14.jpg)
Pilot – first strike
• We wanted select a pilot with the following characteristics:
– Right size for a team of 5-7 to complete in 3-4 months
– Relatively isolated not too much dependencies
– It should have business value but not be too important
• And we failed before the start line!
![Page 15: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/15.jpg)
Pilot – second strike
• Feature that we already looked at:
– Too large
– Too complicated
– Too important – essential for release
of new high-end product
– Work already ongoing
• Waterfall planning now showed that
this feature would delay the new
product with 2-3 months
• Hastily we formed a cross functional team that:
– Sat together (as far as possible)
– Worked iteratively and light-weight
– Delivered the feature in a way that did not risk the schedule of the
new product (took us 7 months)
– About same cost as projected for traditional way of work
![Page 16: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/16.jpg)
This was the right pilot at the right time
• It had very high business impact and
high risk -> Attention!
• At sprint reviews/demos we could review:
– Logic behind our iterative plan
– Challenges / Issues / Impediments
• Low quality on the main/trunk forcing us to
stay on branch using old baselines
• The difficulty in defining good back log items
• Problems with IT infrastructure
• Culture and practices enforcing waterfall behavior
• Challenges in existing within the big waterfall
• Shortcomings in tooling / automation
• Challenges in getting a team assigned, allocated and seated
• Management put a lot of trust in the team!
![Page 17: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/17.jpg)
Advice on pilots
• Don’t run pilots to:
– Prove that things “work”
– Benchmark against current ways-of-working
• Do run pilots to:
– Learn
– Find problems that you need to fix
• The ideal pilot is:
– Critical to business
– Delayed
– Quite large
• Organizational impediments will surface and become hot issues
immediately
• Management will care and chances are you will get focus on
solving some real problems
![Page 18: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/18.jpg)
Find a role model
• Find an organization quite like your own – we got lucky!
– Based on the same platform, using same tools
– Similarities in culture
– Similar order of magnitude of the code base
– Very similar starting position in terms of pains,
processes, organization and culture
• This organization had made a radical change:
– Streamline on the high level
– Scrum on the team level
– Large scale continuous integration
– Massive cultural change
![Page 19: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/19.jpg)
It takes an engine to go the distance
• Someone from top management needs to step up
• Ideal characteristics
– Highly trusted inside and outside
– Eager to learn
– Courageous
– Inclusive
![Page 20: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/20.jpg)
Outline
• Introduction
• What’s the deal with large scale agile?
• Our journey so far
• Conclusions and advice
![Page 21: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/21.jpg)
Keep your eye on the ball
• Ideas
– Continuos improvement
– Respect for people
• Practices
– Cross functional teams sitting together
– Working software every 2-4 weeks
– Visual management
– Go see
![Page 22: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/22.jpg)
Question old truths
• Development should always be done in
projects
• High resource utilization = effectiveness
• You should write the code ”once”
• Quality comes in a sequence of steps –
developers develop the product, testers test it
• You get what you predict so we need detailed
estimates based on detailed specifications
• To be professional you should cleanly separate
the business side from the IT side
![Page 23: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/23.jpg)
Beware of...
• Analysis-paralysis
• Tool mongers and method
gnomes
• Leaders getting detached
• Throwing out your gems
• Parrots
• Masquerading
![Page 24: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/24.jpg)
Advice for line managers
• Educate yourself
• Manage, lead, or teach?
• You cannot delegate this agile / lean ”business”
• What is it that really matters?
– People
– Values and principles
– Practical help to remove impediments / accidental
complexity
– Way of working
• Essentially, line management is a support function, it is not part of
the product development flow
![Page 25: Large scale agile_svante_lidman](https://reader033.vdocuments.us/reader033/viewer/2022060111/55642611d8b42a73298b51ed/html5/thumbnails/25.jpg)
Thank You! Svante Lidman
[email protected] I have changed employer since
I made this presentation. You
can now reach me at
see: www.hansoft.se for what
we do.