Frankenbuilds: If Agile is so Good, Why Are Our Products so Bad? • Gabrielle Benefield • GOTO 2012

This presentation was recorded at GOTO Aarhus 2012. #gotocon #gotoaar

Gabrielle Benefield - Agile Trainer @GabrielleBenefield-g8d

ABSTRACT
It's not about building the product right, it's about building the right product.
Scrum and Agile teams can go fast and deliver high quality code, yet the product still fails. When this happens people look around for a new framework, only to see that fail as well.
Rather than continue to build more code faster, we need to look at the systemic reasons for failure. These are tied to a lack of deep understanding of the causes and impacts of the problem to be solved or opportunity to be exploited, unclear and unquantified goals, and a lack of validated learning with rapid user testing.'
It doesn't matter if you use traditional methods, scrum or lean, if you don't set the right direction it won't matter which framework you use.

RECOMMENDED BOOKS

#Agile #ScalingAgile #Scrum #GabrielleBenefield

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[GOTO-]

Looking for books & other references mentioned in this video?
Check out the video description for all the links!

Want early access to videos & exclusive perks?

Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇

[BryonLape]

Customers who don't know what they want. Requirements that cannot be found. Tests that cannot be defined. Programmers who have no methodological discipline. Belief that agile is a process when it is a philosophy. Project Managers who are certified, but cannot manage. Take your pick. Most likely every failure is a different mixture.

[bitwize]

Part of the problem with Agile is that it is a _programming_ methodology rather than a _systems design_ methodology. It was designed by programmers to make programmers' lives easier, but there is more to an information system than the hardware or software. You need to start by identifying the business problems and deriving a set of well-defined requirements from those, then start work on the systems (which include technology, but are mainly people) that will fill those requirements and solve those problems. Then after designing and documenting the systems you intend to build, you can write the necessary computer programs. Done properly, programming is a simple act of translation from the requirements and system design into code. Such translation may in fact be undertaken automatically by machine, in whole or in part. With Agile, the requirements are vague by design, because the methodology by design encourages writing code before the requirements have been clearly defined. That's why Agile teams find themselves "building the wrong thing more rightly". Building begins without understanding even what the right thing is. The construction crew breaks ground before even having a blueprint! It is hoped that feedback from disgruntled users will allow the team to course-correct and eventually converge on the right thing, but it never works this way in practice. Without a long period of up-front planning and design, during which a vocabulary and procedures are standardized, there really is no hope of getting the right thing within reasonable time and budget constraints. "If America built bridges the way it builds information systems, we would be a nation of ferry-boats", as Milt Bryce put it decades ago.

Milt Bryce, inventor of the first comprehensive information-systems methodology -- PRIDE -- and indeed the coiner of the concept of "methodology" in information systems development, forgot more about designing and deploying technological information systems in businesses than the Agilistas ever knew.

[BrisLS]

I can't believe I am the only programmer/developer who sees Agile as nothing more than a management hammer under a glossy name. It is an excuse for a manager to be in a workers face once a day for a good hard brow-beading, without a negative review making it to Glassdoor. This is the biggest blatant pre-announced bragged-about rip-off of labor by capital that has ever happened. If you have been in I.T. for more than 5 years, you can remember not seeing a "boss" type of person for months at a time, maybe seeing a technical "leader" lead a meeting once a week, other coworkers only at the water cooler. This is just a Genie that has gotten out of a bottle, and producers/testers of code may never get their mornings back.

[rchin]

2021, the 12 became 21, and this is still so relevant. Great talk, so true, but for many in our industry still not a reality unfortunately.

[HakunaMatata]

7:10 that's exactly what I did in the startup I worked for, focused of the core feature, improved it and fixed all bugs, faced a lot of resistance but insisted, customer churn dropped from near 50% to zero, defects were eliminated. We were able to scale the app and acquire more customers and our revenue more than tripled in 7 months... And Yet!! the senior management didn't see any value in what I did because I didn't ship many new features! as if the above numbers improved on its own!!....I finally quit with a very bad taste in my mouth, regretting everything I did, and every late hour I spent working!... I.T. is F'ed up, senior managements are usually clueless. And a lot of this has to do with what agile and what scrum teach!!

[stevecarter]

Agile allows the business to control the software effort, and the business cares about lead time and sort term revenue not sustainability or user value

[megpmp]

It is the dilemma of speed or accuracy, a cake cooked in waterfall tastes delicious and an agile cake is dietary and light. The Product Owner knows the recipe of the cake and the development team cooks it and the cake is the integration of the ingredients, so there are 3 possible sources of error, the recipe, the cooks or the quality or lack of the right ingredients. It is assumed that the retrospective scrum ceremony should help us improve the process to make the best cake, but this ends up being the cake of the Tower of Babel, a true Frankenstain, which ends up falling to the ground or spreading along the table Cooking. Excelent lecture Miss Gabrielle, you truly have expirienced the agile process. Best regards!!!

[bradleyberthold]

Everybody keeps talking about Software projects are bad, and like 80% of them fail, but then they never provide any examples. Where I work, our projects have always shipped. So I'm having a hard time understanding what types of projects they are talking about

[srin]

IMHO this is a great talk - I'm watching this in 2017 and I think there is a land that our industry forgot: making good products that customers will love to use. This is how all the digital tools we use every day were built. Amazon, Google etc. are a great example. Agile principles and practices are about enabling responsiveness and accelerating the feedback cycle. But they don't guarantee that you'll be making the right product. Value generation is the real thing.

[AutismusMaximus]

Managers saying Agile is bad, go figure...

[MDOY]

Projects go bad because of a lack of focus on good architecture and testing, under resourcing and a desire to get things done quickly, case in point my current company are rushing through an app into production with no focus on quality at all. We have a single front end mobile developer who is over stretched and under pressure to get things finished. The methodology is to add new features, usually within a day, get it out to testers, find bugs fix bugs, push new app, add features, find new bugs, fix bugs, until eventually theres not too many bugs (we hope) .. The weakness in the architecture has exposed problems and needs a review, probably from someone who properly understand software architecture more deeply and the flow of data within an object oriented eco system, the whole thing requires some solid unit testing in the core functionality, there is no test data that simulates the actual operating conditions of the app, only 'live data' that exposes problems as and when they happen.. all because no one has realised that quality costs and trying to save a quick buck here and there is only going to hurt in the long run. The worst planners and managers are those who have never developed a line of code in there lives but want to be in control of everything, make sloppy assumptions and never bother to actually ask there staff what they think, in case they get some kind of bad news.

[MeursaultYT]

How are we still making this mistake 8 years later; in a world where our tooling and deployment processes are better. Agile / Scrum and the role of Scrummaster feels like a religious cult.

[psdmaniac]

And this is a main point about IT industry. Problem is not in development but in product goals and feature value. It all about wise management and Pareto principle. It is pretty simple but must by said loudly over and over again. Louder than "Agile" word.

[Skiamakhos]

If you're building the wrong thing, what're your business analysts and your product owners *doing*? Do you even do backlog refinement?

[mivibecom]

I'm grateful to anyone who gets User Experience tools and processes into the public domain.

[graham]

This is the most intelligent and articulate thing I've heard in years.

[FritzFeuerbacher]

Agile doesn't mean zero systems engineering. Systems engineering should always be out front of development by a program increment. Systems define the inputs to development so the systems products need to be mature enough so that development knows the architecture and avoid building a frankenbuild.

[VideoGundamXYZ]

Quantity is no substitute for quality.

Redundancy, code-bloat, impatience, immature/poor-design and related partners-in-crime can be familiar road-blocks between you (the "coder") and personal project-related epiphanies (say, awesone "light bulb moments") experienced during {design, implementation} phases. Respect yourself more (may need push-back against the "non-coders") and know thyself (your limitations, strengths, potential for adaptability) and you'll get closer to the "light".

Time does not have to be your enemy.
However, your level of character/attitude, philosophy, intelligence, etc. will dictate the challenges you can reasonably challenge.

Just some musings, reminding me of those "superman" moments during coding sessions that imparted the notion that practically "anything is possible". Still true today as it was years ago.

Also, it has to be FUN; a great motivator.
:-)

[amartins]

So if 35 features didn't do the thing you need, and 3 would have, should you have just done 3 features then? No matter how you do that work (agile or otherwise), the product owner/product manager should evaluate what's worth building in the first place. I don't see the WAY you build those things drastically influencing if your features are good or not. In fact, if you incorporate a prototype feature into an early sprint you could start getting data about its success, and have an opportunity to adjust it or drop it. Smaller commitments might have more overhead, but they're consequence is much better controlled and learned from when you need it (before you're done with the project).