Why Scaling Agile Doesn't Work • Jez Humble • GOTO 2015

This presentation was recorded at GOTO Berlin 2015. #gotocon #gotober

Jez Humble - Vice President at Chef, Author of "Continuous Delivery"

ABSTRACT
There are now several frameworks designed to address the demand for "big agile."
In this talk Jez will explain the flaws in such frameworks, why they so often fail to produce the desired effects, and what we should do instead. He will also address some common [...]

Download slides and read the full abstract here:

#Agile #ScalingAgile

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[Well_Earned_Siesta]

“I love running surveys. Surveys are a really rich source of confirmation bias.” 🤣🤣🤣🤣🤣🤣

[ruslanbes]

*Timecodes*

01:30 The industry-standard process is _Water-scrum-fall_
04:40 The most miserable moment in my career
05:53 How the companies make investment decisions for products?
08:25 What's the main analysis activity we perform to make sure that we really should do the project?
11:45 Cost of delay
14:40 What should we do?
17:15 Whose requirements are they?
18:40 Impact mapping
21:03 Hypothesis-driven delivery
24:15 We could be spending 2/3 of our time on a beach if only...
28:00 Case study from hp
37:30 How they did it?
40:00 Improvement kata
45:45 Questions

[nez]

This is the best video I've seen this year and I've been watching dozens. I love your ideas Jez, this is empowering stuff!

[patrickbuick]

I find it interesting what you said about HPs testing. When I was fresh out of EET school, I was asked to build a test jig for our navigation integrator. I didn't think it was so tough, so I did. They provided the inputs for various conditions to the sensor inputs and we collected and tracked the output. Slightly smaller number of inputs I guess, but. Amazing what you can do when nobody has told you that you can't prior to trying.

[deepagoyal]

I like how you explained "Lean works by investing in removing waste so that you can increase throughput." But these are shown on an example of benefit over 2008-2011, three years. However, in Silicon Valley, where people do not invest in an organization more than a year or two and mid-level management needs to put together slide decks each month, nobody pitches or entertains a investment over 3-6month returns cycle since they don't see themselves reaping the benefits by then.

[ChaunceyGardner]

this is excellent. Thanks for uploading this and thanks Jez Humble.

[gilian]

SAFe -- It will pretend to work convincingly enough if you're too big to fail... and it may single handedly tank the company if you are not.

[ronnyreichmann]

Apart from the Agile movement being right about most things they’re in my opinion way off in targeting. He’s using “we shouldn’t” and “we should” all the time talking to programmers about problems caused by the more powerful more influential part of our organizations. In my experience those parts just don’t care about the puny opinion of a bunch of nerds. So please stop saying “we this”, “we that”. We don’t have a realistic say in this kind of things.

[shadeblackwolf]

As much as i like this in theory... in my practical experience, we get contracts where the services we need to provide are iron clad, and not yet built. Yes, we need a better sales team, but it is a major problem for us, that our software is usually an implementation of a contract, rather than us developing our own product.

[stevecarter]

Disproportionately tweaked by "processeees". You said it right twice!
Thanks for talking a lot of sense.

[CharmedQuarkSystems]

To me I wonder why this would even need to be argued. When is ANY large organization actually agile? It's just a matter of organizational physics that people add mass and mass adds inertia. But, OTOH, you generally can't create large software products with a tiny group of people in a commercially viable time frame. If the time frames were longer it could be done. I've created a personal code base of 1.1M lines by myself, but that took two decades. Not exactly a viable business time scale.

So, anyway, there's a certain amount of "you can't fool mother nature" here. You just can't weigh a hundred tons and turn on a dime, but you also can't weigh a hundred pounds and still move a mountain unless you are willing to wait a long time and do it a bucket-full at a time. It's a conundrum, and I'm not sure any process guru is going to get around that basic physics.

[BryonLape]

In other words, don't let Project Managers run and determine development.

[youyouma]

Agile works as Emperor's new clothes. If you have guts to speak up, you are the brave little kid.

[greacen]

Cool to hear Joshua's Cost Of Delay work mentioned here...

[PeterPerhac]

especially liked the answer to the last question (last 3-4 minutes) great idea! great talk. Thanks!

[IntraFinesse]

While the presentation is ok it doesn't really address the title of the talk "Why Scaling Agile Doesn't work".
Change the name of the presentation.

[ab-nmxi]

Listen to this for 15min and still no answer why agile doesn't scale. The first 15 minutes are why projects in general don't work, nothing about scaling. Can anyone who watched it to the end answer why agile does not scale?

[SurfviewTV]

This was a great speech, but, I didn't hear anything about "Why Scaling Agile Doesn't Work". A better title for this YouTube video could have been chosen.

[assadha]

Very good talk. Water-scrum-fall seems to be common but I have to wonder if that model is inherent in the way organizations are structured. Scaled agile doesn't promote disparate testing and operations roles outside a project team. If those disciplines were to be embedded into a scrum / kanban team, would that not accelerate value outcomes?

[bigayysfromspace]

I got an advertisement trying to sell agile courses to me when I tried watching this session.