Why Scaling Agile Doesn't Work • Jez Humble • GOTO 2015
ฝัง
- เผยแพร่เมื่อ 3 พ.ค. 2016
- This presentation was recorded at GOTO Berlin 2015. #gotocon #gotober
gotober.com
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:
gotocon.com/berlin-2015/presen...
/ gotober
/ gotoconference
#Agile #ScalingAgile
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
th-cam.com/users/GotoConf... - วิทยาศาสตร์และเทคโนโลยี
Thanks!
Thank you very much, @amiteitan, this is much appreciated! ⭐️
“I love running surveys. Surveys are a really rich source of confirmation bias.” 🤣🤣🤣🤣🤣🤣
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!
*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
⁸⁸uu
U
nih ⁸u⁸
this is excellent. Thanks for uploading this and thanks Jez Humble.
Disproportionately tweaked by "processeees". You said it right twice!
Thanks for talking a lot of sense.
especially liked the answer to the last question (last 3-4 minutes) great idea! great talk. Thanks!
Cool to hear Joshua's Cost Of Delay work mentioned here...
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.
Brilliant!
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?
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.
Sounds like waste Deepa. Remove it. If your company relies on people that demand short term return on investment, your company is killing itself. Easy solution: Don't accept investments from people that demand short term returns. These people will kill your company and are, therefore, the ultimate example of Waste.
Funny thing is Silicon valley and Big tech don't do Agile nor Scrum. They don't need it, you don't need it to build important life changing things
Thanks a lot for sharing your vast knowledge and idea, increased my knowledge, Regards Anup
love the shirt.
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.
I would be interested in what brings you to that conclusion. For me, watching this video from 2016, it was a bit like: "ah cool, someone did see that, grabbed Kotter, Dunbar and Co into one framework and came up with SAFe? But it seems that you made unsuccessful experiences with it?
@UCytaKijEMQkTMI84YwUsgUQ hmm, I dont have practical experience as I just work on my SPC certification test. But After the four day SPC Training I recently had, it doesnt Sound like SAFe was implemented as it is supposef to be. Because all problems u stated should be solved with SAFe and not arise due to it, in my humble noobish opinion.
@@Steveegrim And it seems my comment explaining what happened was deleted. The snake bit us because we weren't faithful enough, eh? Good luck on your projects.
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.
learned helplessness anyone?
that is the practical experience you are talking about?
this is a symptom of the prevailing system of management. go somewhere else where you can make and live your best life :)
wonderfull
Can you talk more about creating feedback loops, especially in SaaS?
Agile works as Emperor's new clothes. If you have guts to speak up, you are the brave little kid.
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.
It's rare to hear such well balanced opinions in the domain of door to door salesmen. Sorry I mean the domain of agile, there's a difference, I think.
You are wrong if you measure software development by counting line by line. So wrong
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.
He is part salesman so don’t take his words so literally.
Agile is an adjective.
In other words, don't let Project Managers run and determine development.
That's no difference than letting Product owners run and determine development ! Project managers with right skills are always essential delivering the whole project successfully. Who should control budget, scope and manage stakeholders? Managing stakeholders is not about giving demo to them - there are so many issues and it is simply not possible for a PO (product owner) to manage these - in fact they in most cases would not have right skills. I know Agile community pride itself eliminating the role of Project managers but then it can't handle the topics I wrote at the beginning. Delivering a successful project is not so simple - as you know.
Well in a value stream financial environment you don't really have program budgets. Your Product Owners should always own scope and manage stakeholders. Stakeholders are where you get your scope from so managing both is easily owned by one role. I agree there are a lot of tasks involved in a "program" and Product Owners should not own them all. In agile most of these program processes are simply removed and managed by very good acceptance criteria and team members communicating and automating.
Agile does not just deliver program, it also delivers project and a project will often have clearly defined budget. Scrum never says it is incapable of being used in delivering projects. If it is expected that product owners will manage project budget then clearly that organisation is confusing the roles. Managing stakeholder is not just managing scope - you may refer to stakeholder management part of any project management methodology.
Dont let developers who dont know why test maintenance ends up taking up more time than anything else and how to solve that issue run anything either
@@rrsrsrtr Are you speaking in terms of consulting or doing contract work? Using traditional project management for planning, funding and delivering a software project doesn't work, you'll be late to market, deliver the wrong things and focus on outputs over outcomes.
This was a great speech, but, I didn't hear anything about "Why Scaling Agile Doesn't Work". A better title for this TH-cam video could have been chosen.
I got an advertisement trying to sell agile courses to me when I tried watching this session.
That four step kata is called the OODA loop in the military
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?
Good talk Jez but unfortunately you almost had no argument about "Why Scaling Agile Doesn't Work"! Looks like a click bait.
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.
I don't understand the title. It seems that he is advocating for using more agile techniques.
The title refers to the way that most companies try to scale agile and how wrong they can get it. Without looking at the portfolio (cost of delay), considering techniques like impact mapping, figuring out how to stop building 2/3's of the features where there's no or negative value, etc. etc. then scaling agile won't work. You can't just swap the SDLC out and insert Scrum (and thereby ignoring everything outside of actual software development) and expect the gains that lean and agile can bring.
Correct. I was taking a pop at the current rash of frameworks for "scaled agile", which are good at taking you from chaos to some level of discipline, but won't typically transform system-level outcomes such as lead times.
My guess is click bait
What do you think of Scaled Agile Framework?
Somebody once called it "Shitty Agile For Enterprises". I think it's a lot better than it was, but most of the implementations in real life have at least some of the serious flaws I discuss in the video that prevent them from achieving significant improvement.
SAFe fills in the vacuum which has been created in the Agile enterprise space. All of the Scrum guide talks of "cross-functional teams" which are in-itself hard to have at the team level what to talk of at the enterprise level across portfolios. I really like your book "Lean Enterprise" and I feel that the organizational and cultural practices discussed in the book combined with the Agile extensions of SAFe makes for a perfect stepping stone for large-scale Agile transformation.
In absense of SAFe or any other enterprise agility model it becomes hard to convince all stakeholders as to how the org chart would look like once the Agile tranformation begins. Yes, SAFe does come across as bloated and for some people as "anti-Agile" but it fills in the gap which scrum left for over a decade by solely focussing on teams and not enterprises.
Wait a minute...HP sells test automation software....
Has anyone actually saw their "business division" work agile? or perform "tasks" ? or report into Jira / Rally?
+Pawel Magnowski Only at the very top, so essentially basic task tracking. It's useful to have everything in a familar format(Jira), but without full adoption most of the benefits that Jira/Agile provides over any run of the mill todo list is lost.
Not effectively. It becomes a formality - essentially a replacement of Waterfall change requests.
But how do we change it? I'm an engineer. I can't change the whole company where I work.
Interesting. We need traditional engineering practices, there are many in software development that are known and work. Proper design, proper documentation, requirements elicitation, architecturing, proper QA and tests.
22:40 UX to the rescue!
When I'm thinking about the stuff presented in here, I just wonder, where on earth does all that bloat creep in, into organizations? Does someone get paid (solely) for creating bloat, charts and that person NOT having a direct, major kickback from the actual product's sales figures?
This is not only against Scaled Agile but against all kinds of Agile. The principles of identifying the features that give maximum value was known in early 90s but finding it reliably at the inception of the project / product development is the problem. Cost of Delay, Impact Mapping, Goal-Based Planning are OK (the latter two were known in early 90s) but can they be done quickly at low cost? Hypothesis-Driven Delivery is sound but that is against Agile approach which scoffs at creating enough UserStories and analyzing them and planning which to implement. Agile recommends implementing each UserStory as it is thought of and releasing the "working code" the user can test and accept. Experimentation is OK but what is the guarantee that the "features selected for experimentation" will some how hit the most "valuable feature" soon enough? What is the method for "selecting the most value adding feature" out of say 100 identified features?
Good to see Agile being challenged but the solution or remedy for flaws have not "clearly" emerged. This skepticism should help.
putchavn@yahoo.com 13NOV17
"hypothesis-driven delivery is sound but that is against Agile approach" ---- that is a some massive contradiction there.
that's why you need a feasibility study done up front as well as user model research. You don't drive features through development.
It doesn't work because agile was never intended to scale, it was intended to create good software with reliable predictability.
Interesting talk, but really should be WHEN Scaling Agile does not work. Current title is clickbaity. A lot of his concluding bullets are part of the SAFe Agile principals anyway
so "when" has to do with time of day or time of year, etc
that's one heck of a mid-level-management, "certified" review
Whoever came up with SAFe should've known it was bad idea.
I work on software development tools. I don't know how to apply these ideas to building a new dev tool. Let me give an example. Let's back up to the early 2000's and let's say my idea was to build a better IDE. Stupid idea, right? At the time there were two dominate IDEs. If you were a Microsoft developer you used Visual Studio, and if you were a Java developer, you used Eclipse. Eclipse was free and VS was sorta free under some circumstances. But for some reason you're stupid enough and crazy enough to try it anyway. What do you do? Who do you interview? What do you ask them? What do you expect to learn? The only thing you could possibly learn was to not do it. Eclipse was free, and my manager won't pay for me to use anything else. What experiments are you going to run? What 3 features are you going to deliver that will let you eliminate all the other features and go skiing 66% of the time? You can't. There's a huge amount of tablestakes features you have to build to even enter into the game. How are you going to deploy to production 150,000 times a day? What will you learn when you do deploy to production? Somehow JetBrains did it and now everyone uses IntelliJ and no one uses Eclipse. Why? Because IntelliJ is really good and Eclipse sucked. Isn't there something to be said for just grinding it out long term and building a great product? That's basically where I find myself. I'm in stealth startup mode building a speculative new product in an existing space. There are no customers to ask. There are no experiments to run. There is no great insight to be learned. There is no vast swath of features that can be eliminated. There is no way to measure anything. There is only my intuition and the steady grind of working on it.
You don't need Agile nor Scrum to build actual industry -changing products. IntelliJ didn't, Google didn't, Amazon didn't, eBay didn't.
Go for traditional engineering approach: analysis, elicitation of requirements (if needed), design, architect, build, deployment. Re do.
Unless you have very good insights about the customer base (e.g., you have worked in that industry for long enough and have experienced the pains but also listened to lots of other people about their own pains), you may be deluding yourself about the features that matter. Worst case is you spend years building something that “nobody” will pay to use (i.e., maybe a few will, but it won’t be a commercial success).
I think the idea that there are no customers to ask, no experiments to run, etc., is just wrong. If there are no customers to ask, why am I building this in the first place? If I can’t even find them, how the hell will I sell this thing when it finally launches? Believing that “build it and they will come” has been proven to be a terrible philosophy for building products (ask anyone in the startup world).
As for feature scope, of course there are endless possibilities, it all depends on what you’re trying to achieve. Are you trying to demolish the incumbent by building a better clone with absolutely every feature they have? Why not focus instead on the most commonly used features? Sure, you will only attract a niche of the total customer base, but so what? You can start by delighting that niche and then grow from there.
You think Etsy tried to mount a full frontal attack on Amazon when they started? That would have been a total waste of their time seeing as how aggressive and competitive Amazon has always been. Instead, they decided to focus on a much smaller niche that Amazon wouldn’t care about.
(2:15-5:18)
17:35
Water-Scrum-Fail is more appropriate.
Often you end up spending more time maintaining tests than writing features. This is discussing in the book clean architecture and is a much more complex and serious issue which gentlemen like this dont discuss. I liked the talk overall though
A good working software that is not used don't deliver ROI. But we may not assume that a software that is used will deliver ROI. Install a nice game. It will be used a lot. The end-users will like it and be satisfied, but won't deliver ROI.
To
The reason why things change so much is because we work based on what the customer WANTS .. yet (s)he has no clue. So the input is very unreliable. That's exactly why years ago the discipline of systems analysis (and all analysis flavours) has been developed. Today, it is still used to "analyse" what the customer wants. This makes it useless. The goal is in fact to find out WHAT IS NECESSARY, to understand the existing systems and environment, to discover problems (diagnosis) and opportunities and to conceive and propose solutions. That's the real purpose of systems analysis (and its flavours like BA, BPA, FA, ..). Check AB6 Framework : bit.ly/2S9aGN3
It would be great if the speakers used a microphone during the speech... 😏😑
⁸u⁸ga u8huì8⁸⁸u⁸uuu⁸
There is no connection to the title (scaling agile doesn't work)
Uu⁸
Pareto distribution.
H8ì
probably because agile is a bunch of BS
this guy needs to stop flapping about
U⁸⁸