Frankenbuilds: If Agile is so Good, Why Are Our Products so Bad? • Gabrielle Benefield • GOTO 2012
Vložit
- čas přidán 2. 04. 2013
- This presentation was recorded at GOTO Aarhus 2012. #gotocon #gotoaar
gotocon.com
Gabrielle Benefield - Agile Trainer
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
Subramaniam & Hunt • Practices of an Agile Developer • amzn.to/2XjbWor
Uncle Bob • Clean Agile • amzn.to/3tpAqb5
Derby, Larsen & Schwaber • Agile Retrospectives • amzn.to/3hB4eNk
Jeff Sutherland • Scrum: The Art of Doing Twice the Work in Half the Time • amzn.to/2X4GQAD
/ gotocon
/ gotoconference
#Agile #ScalingAgile #Scrum
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
czcams.com/users/GotoConf... - Věda a technologie
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.
While it is true that developers deal with a mess in terms of what is asked from them, I don't think that can be extended to customers. There are plenty of people with very well defined needs who expect very specific things from a computer program, and they are consistently left high and dry by our current model of development, and my hypothesis is that this is the result of "keep growing at all costs to add value (and justify our existence)" rather than naive, uneducated users, and Agile is part of that "keep delivering" mentality. Updates are shoved down our throats even if we don't want them, and we are charged for them. Features are sold in big packages like Adobe Photoshop for which users pay all of it while using maybe a tiny subset. The faulty dynamic is associated to our economic model that keeps pushing for growth at all costs while failing to see the sustainability aspect of it.
Nothing wrong with customers. Try questioning your own ability to ask right questions.
@Vorraboms You may also question your ability to ask right questions. It's about neither you nor your job, it's about needs of those who pay you, but first you need to grow up to get it.
When people have no idea what to do it always results in this kind of long useless excuses.
@Vorraboms Sorry, I am not paid for reading your word diarrhea.
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!!
Fix a thousand bugs and you're a hero. Write software without bugs in and you're overlooked.
So many unsung heros.
That's feature-addiction. The industry is addicted to features and sprints and Agile is a great drug provider for this multi million dollar addict.
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.
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.
You are not alone, we have noticed and we are many
Updating this after 4 years, I think pay has certainly jumped to match the increase in demand for output. And the WFH has become more available. But gone are the days of 3 month coding assignments with little oversight. Seems standard to be providing daily results now.
That's why I intend to leave the industry after a while. I can't stand programming with a boss. It's as pleasant as writing poetry or painting with a boss, except there's a lot more that can go wrong.
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!!!
Why are you making a cake?
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.
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.
I think Agility does not guarantee value but that agile behavior is a driver /catalyst for crystallizing that value far earlier as better sens and respond reactivity happens and outcomes emerges from that better ..
So In à way , does agile guarantee value maybe not but it should guarantee faster reduction gap between real value vs perceived /unrealized value 😊
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
Some of my best work was on projects that died, usually to politics.
I once even had to finish a project where the client of our client for whom the software would be in the end, canceled it midway. It was highly specialized and made no sense as a retail product, no other use for it, so that was both confusing and frustrating.
This is the most intelligent and articulate thing I've heard in years.
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.
:-)
I'm grateful to anyone who gets User Experience tools and processes into the public domain.
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.
Yes indeed. Especially the last part... it gives non-technical managers an illusion of control over something they don't understand. Also there is a lot of guilt projected onto the developers.
No amount of tests and code quality will save a project from failure if the product itself sucks and nobody wants to use it
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.
If you're building the wrong thing, what're your business analysts and your product owners *doing*? Do you even do backlog refinement?
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.
easy "solultions" to difficult problems with very difficult verification processes
result: cargo/religious cults
It IS a religious cult -- magic phrases, holy signs, heresy, and the Inquisition.
I concur. As of 2023, Agile/Scrum is OUTDATED. So much have changed in 20-ish years
@@ericpmoss Masters, Owners, Manifestos, refinement, _"Uncovering truths"_ and so on.
Managers saying Agile is bad, go figure...
wow this lady sums it up if Agile is so good, why are the products that come out of it so shit ..... 2019 still relevant
Agile = mini waterfalls. Structured worked.
madmax101 (Eddy Eddy!!! ;) ) Gabrielle is correct. Delivering customer value is the #1 item on the Agile Manifesto. I was one of the contributors to the creation of Agile when I was at Apple in 1992. The whole reason for the Agile concept was requirements were incorrect, or incomplete, or changed after we started developing.
We could already build anything nearly perfectly. More quickly delivering working code was a side effect of Agile iterations, it was not the purpose. What kept happening is we would build it then customers would reject it because it didn't do what they wanted so we had to start all over again. The only reason for iterations is to check to make sure you are building the right thing, what customers actually want.
Additionally, at the time we realized that software would not sit on a single computer, it would be spread over many clients and servers. You could not build software as a single monolithic item. It had to be flexible and allow pieces to change and be added later. Building that type of software needed totally different methods from the Waterfall method.
+Mark Proffitt No Mark, the number #1 on the agile manifesto is valuing Individuals and interactions over process and tools... yet another idiot that doesn't understand Agile.
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." agilemanifesto.org/principles.html
tenminutetokyo You are confusing features with results. That is a typical mistake, especially for engineers. Customers want the results, not the product. Your example of a skyscraper missing some floors and some windows could be a perfectly valid option if the owner wanted to start renting the finished floors. The owner could have revenue before the entire building is finished. That would maximize value.
Regarding an airplane, the result is a vehicle that can safely fly from a desired location to a desired location. Comfort, cargo capacity and some other results may also be important. If an airplane could be made without a tail that delivered those results the customers would be very happy, especially if it cost less or could be delivered sooner. EKIP is an airplane design that doesn't have a tail and has 3X more lift.
Focusing on product instead of results causing the better options to be missed.
Superb!!
+Mark Proffitt , I always understood the "valuable software" expression as equivalent to a kind of ROI from both the customer's point of view and the ones developing the software.
I understand that the ROI perception might change through the process and the context, but it is almost all there is to say. Through the process means customer ROI vision can change. Through the context means ROI requirements per se have moved from "I need this stuff to go fast" to "I need this stuff to be on the market fast". The "built it all first" versus "rent a floor at a time" example applies well here.
Now, it might be a "valuable software" for many other reasons, but generally, it seems to me to be for ROI purpose . Am I missing the point ?
References
- hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1 (see the section "A case for Microservices")
- www.agileconnection.com/article/how-being-agile-can-maximize-your-return-investment
Thanks,
Can you please shed more light on the "Minimum Viable Contract" you mentioned?
No methodology or amount of technical expertise can help an unhealthy organisation. That said, capable / humble teams will naturally gravitate towards the approaches mentioned here - though it's still exhausting in an unhealthy organisation as no-one will celebrate or realise why something was a success.
It's easier than all of this... 1.) Build up a team that you are confident in; which means, refine hiring process first off. 2.) Developers should be comfortable where they work. 3.) Make sure communication amongst the team is rock solid. 4.) Develop and refine your product *continuously*. 5.) Don't stop learning and researching new ideas; product must not go stale. 6.) Everything will fall in line organically, naturally, without introducing too much process.
Did you ever accomplish that?
I once learned a valuable lesson: "Only accept advice and teaching from those who already accomplished what you try to accomplish and then ask: 'How did you do it?' "
Mate this is wayyy too optimistic.
1.) When were you able to build a team of the engineers and keep them together for 2 years. HR is much harder than you think.
2.) Just the fact that "work" is in this makes this a difficult task, and everyone will want different things.
3.) Ok, this one can be worked on but then, communication is a big distractor.
4.) What is technical debt?
5.) So more technical debt?
6.) Now this is beyond optimistic.
I get her point here. Have goals that will require less skilled developers, make developers comfortable with the work they are doing(so less work), require less communication, less feature = less technical debt and management, the less number of items you need to work on the better chance you have with them falling in line organically, while making the most money. Basically get the most output with the least input. Do less get more. That is the easiest goal I can imagine. what you described is the opposite.
IT profession dealing with the triple constraint problem, a problem real engineers have been dealing with for over 100 years - everything old is new?
I really like this. I have been involved in developing a number of large enterprise systems with a significant number of 'back end' users (Think whoever does the buying for Amazon). I have found that they will frequently focus on features that are useful to them but don't really add value to the business. If you present those features to your users at the end of the Sprint then they will like them, but you won't have created value for the business
+Steve Green That sounds entirely opposite to agile though? That the customer's wants are what are important (they are the ones paying, after all). Why is "created value for the business" better than what the customer actually wants?
+Bradley Berthed Imagine there are two candidate features: One will save $50k by making the work of 200 people (who work for the company) slightly easier. The other will create $1m in revenue but is being promoted by 1 sales & marketing exec. Which one should take priority?
Kanban is also Agile and it's about continuously adding value to the business, in an over-simplified statement. I think you are describing the way Scrum has been implemented in some companies as opposed to what it should be. You have very good points, though.
If you read the agile manifesto, or extreme programming or any of the other variants -- they're all about working closely with stakeholders in short iterations in order to make sure they always produce value.
But.. as you say, most companies simply don't do this... sadly. They take a bastardised version that skips the inconvenient bits, like talking to the clients.
Neither Scrum nor Kanban is agile.
@@BryonLape huh? What is it then lol
I like your seminar, but your title is a little misleading.
We are just moving into agile from traditional model, Switching over next week. We are a small web agency, catering to many small and medium scale businesses. The differences we see here in agile is that it helps us to push the uncertainty risk in the scope on to the clients side. It helps us build a fast paced development team which does what its supposed to do. Altho with respecting between "Building the right thing" and "Building things right" , Agile clearly focuses on Building the thing right" and we assume our customers who want the product better knows the "The right thing"
However, your seminar has brushed on a lot of aspects for "Building the right thing" , I think if we have a system as you suggest to make sure we are "building the right thing" + Agile ( "Building the things right" ) it would be a brilliant combination to get the right thing delivered fast paced.
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).
I /think/ we're in agreement. I might phrase things slightly differently: Regardless of what methodology you wish to employ, the actual decisions involved in what make a product great live entirely *outside* that box.
I really think that our focus on methodologies (Agile/XP/TDD/etc.) has caused us all to completely lose track of what we're actually trying to accomplish in this discipline. None of these techniques improve a thing AFAICT over the years, and what they actually accomplish is fairly risky: It puts an unwarranted faith in the *process*. As if process somehow saves the day.
Actually, only 3 1/2" diskettes were "idiot-proof". In contrast, there were 8 ways to insert a 5 1/4" diskette, and 7 of them were wrong. There are 4 edges to a diskette, and for each edge you decide to put in first, there's a way to have side A up, and a way to have side B up.
Watching the the current "tech bubble burst", there are lots of "spend lots of money, deliver lots of half-baked features" startups that wont make the cut, and I hope this lights the alarms in the software bussiness world about how that's not a good way to go making software.
Yeah. I thought about this at the beginning of the year. Scrum being on top of this financially irresponsible behaviour in the midst of massive layoffs
Outcomes over output is key.
What is this, marketing/management talk? What kind of products is she talking about and what kind of clients/consumers/customers?
Georg Wilhelm Friedrich Hegel, the founder of the modern idealist system used to say, "History teaches that mankind has learned nothing from it." Unfortunately, this statement from the late 18th remains true today.
Hard to believe this is from 2012. Still great relevant info
hard to believe you think this problem didn't exist for the past 15 years years
@@judgedbytime hard to believe you assume i have been programming for 15 years.
@@MobiusNavigator totally agree! Thanks for the great content!
Tom Gilb as she points out was from 60s.
RUP Agile has improved the development process which is key to good projects. We have an opportunity to improve the customers side of the process to get the right things built.
RUP you mean? I am interested in RUP, haven't heard about "RUP Ágile".
You all forgot about the motivation of developers. If we work just for the salary than we want to have as much work as possible so that we keep our jobs long into the future. That is why we want to implement as many features as possible.
No, not true.
People over complicate stuff most of the time and it mostly comes from non-tech people. Like if you have corporate environment and big projects for the customers that need like...new software but with the same features as old one and some minor changes, just use some kind of waterfall and deliver a quality product. If you are a fresh startup building something new, and you don't know how the market will react and what customer wants, use plain simple agile...that's it. There is no magic bullet (Scrum)
The most damning point to make against scrum(or most agile methods), is that, despite the fact that software engineering is an *applied science* , and we are all therefore supposed to use scientific principals when doing our job, despite this, **there isn't a SHRED of empirical evidence to support so much as a single claim made by scrum(or any agile) proponents** . This relegates scrum to the SAME category as aliens, bigfoot, Q conspiracy, flat earth, etc. That is, a category, for claims that are made, that are devoid of **empirical** evidence to support them.
Belief in claims devoid of evidence, is by definition, **irrational** , and is borderline delusional. Being the opposite of rational, it is therefore the opposite of science, and therefore, NOT applied science.
The most common excuse you get is, "agile is beyond the abilities of science to study" . Which is of course COMPLETE nonsense. The ONLY things that cannot be scientifically studied, are phenomenon that **do not manifest into reality** . They like to ignore that case studies, are considered the poorest form of evidence in science. They also like to ignore, that the handful of studies done into the matter, **show no advantage** to agile techniques. Fun fact, other things that are "beyond science" are aliens, astral projection, and bigfoot ROTFL.
It is also important to note, that agile consulting, is a **multi-billion dollar industry, and it is ONLY growing** . So billions of dollars and hundreds of thousands of people stand to lose a lot if this little factoid about lacking evidence, is paid any attention. Quite the opponent. **One would think, that the biggest selling point to agile, to a bunch of scientifically minded engineers, would be empirical evidence of the claims.* "Here is undeniable proof it works" . "Sold" . Engineers use what works. **However, have you noticed, despite having billions, that industry refuses to provided any proof of the claims, by supporting the studies?? Now why do you think that is hmmmmm ROTFL????**
My favorite argument "against" me, is "Well, that is just BAD agile" --> ROTFL ROTFL
My favorite response: "For a system that is claimed to be superior, it is certainly inferior to ALL other methods, with respect to its ability to get it right. That is the opposite of superior, especially since none of your other claims about agile are supported by evidence."
38:07 - "Save the feature, save the planet" ...haha well said.
How about Customer Development?
Lean is not under the Agile Umbrella, You should study lean, and you wiĺl see that the focus is on the quality, not deliver something fast.
I think the Poppendieck couple did the wrong thing trying to mix Lean with Agile.
Lean focus on the whole picture,but separates the jobs to be done much granular than something like Scrum,and all other that relly on SPrints.
Software development is a Marathon, not a series of 100m lines.
I wrote an article about that,it is in Portuguese,but google translator does a good job.
www.linkedin.com/pulse/por-que-escolhi-o-lean-kanban-ao-inv%C3%A9s-do-agile-scrum-oliveira-dias
7 minutes in and I want to go work for this gal.
These issues are not unique to tech, the economics field address(incentive analysis and such) it but few people have ever bother to study econ beyond the superficial bits spewed out by hack politicians.
I'm not mad at all!
SOUNDS ARE GREAT
what about the idea that you can't measure value, because value is subjective...sorry coming from economic background -- subjective theory of value. not sure if relevant...
I don't understand the comment about not asking users what they want. I know people only know what they do now, and maybe they don't have a vision for the future, but don't you have to ask them what they want sometimes?
Don't ask what they want, ask them about the "pain" they have with what they are doing. Then you get answers for what they need, instead of what they want
If that was true, every Interaction Design book would just be one page that said "Idk, just ask the users."
In short, people literally haven't got the first clue what they want, until they see it. It may sound arrogant, but every new service and technology we adopt demonstrates this, time and again. As Henry Ford (of Ford Motors) famously said: "If I had asked people what they wanted, they would have said faster horses."
Agile is an excuse for the boss to push employees working hard and harder and harder
...and self-manage with daily, and self-punish in retrospective
If you aren't learning while delivering in a safe space and being protected from the delivery whip then it is NOT AGILE!!!!!!
Look at levels of war. Agile fits technical and tactical. It is not so good for operational and strategic. Jeff Southerland even wrote so in his book. It is interesting that he was involved in strike planning, a tactical event, and the overlap between strike planning and scrum. Look further to military planning at all levels and at operational assessment. The questions opened here match. Note Eisenhower’s “the plan is nothing, planning is everything” then deep dive Boyd with mission command, unity of effort, understanding intent. There’s reason tasks have purposes.
“One of the key concepts in Scrum is that the team members decide themselves how they’re going to do the work. It’s management’s responsibility to set the strategic goals, but it’s the team’s job to decide how to reach those goals.”
Funny enough this also summarizes mission command. Given their backgrounds, there’s a good chance Sutherland knew Boyd. You can’t scrum strategy.
We should note Sutherland’s book does read outcomes not output. Makes you wonder if like Americanized Lean, is there misreading of the basics?
“It is crucial that people as a team take responsibility for their process and outcomes, and seek solutions as a team.”
“The Product Owner should be responsible for outcomes, but let the team make their own decisions.”
“‘Orient’ is not just about where you are; it’s also about what outcomes you’re capable of seeing-the menu of alternatives you create for yourself.”
“He thinks they should start setting performance-based goals. ‘Okay, Agency X, here are your goals, here are your expected outcomes. Once you have that, you can start writing legislation that is outcome-based,’ he says.” - in this last I’d argue these are effects based goals not performance based; performance is more reflective of what the team has done while effects reflect what they built has done. Did you build it right versus did you build the right thing. But this is a quoted person’s terminology, not the author’s.
“Make decisions as reversible as possible. Make irreversible decisions as late as possible.” Sounds a lot like Sandy Woodward the carrier battlegroup commander from the Falklands War.
Nah. It is also a technical failure too
Smart, beautiful, witty and innovative. What a treat to learn from.
Soooo...the thing she`s talking about is that to make something good you need to understand what you are doing? Alrgiht...thank you?
Are business executives attending these conferences? If not then this is just an echo chamber and nothing is going to change.
Mesmerising talk. Until "We at Yahoo (...)" :T
That was 6 years ago.
Missing the point of Agile "dev process"? The process is not giving you all the recipes you want. Agile is not even a process per se but rather a way to find a process. There are many gaps in there that every team will need to fill with what they find appropriate.
So, there is no point in blaming Agile for bubble sorting in prioritization process. Because some teams will find it just good enough, whereas the other will agree with you and use impact-based sorting techniques.
Similarly, it's not the Agile's goal to magically point you to "the right thing to build". It's the part of the process you as a team need to figure out.
Agile doesn't do what you try to blaim it for. Agile is about short fast iterations with reflection and thinking. That is it.
Please, don't get me wrong. I agree with most of the techniques you're referring to. As an ex-Amazon dev I am data-driven-brainwashed. What I disagree here is that Agile is anywhat responsible for the teams' misses.
+Igor Soloydenko Actually eXtreme Programming does fill in all the holes. Short iterations, spikes to resolve technical risks, sustainable speed (to not hurry up developers and learn slowly since by definition when you are learning you do it slow), high quality (TDD, pair programming, continuous integration), etc.
It has all the ingredients you need.
Igor Soloydenko totally agree, what this person exposes is a lack of a leader steakholder making decisions and lack of actual project management
You sure about a leader steakholder? Not about a roast beef holder? :-D
Florin Jurcovici wow. What a clever appropriate comment!
I don't always make fun of people, but when I do, I do it in serious situations. It prevents tunnel vision, IME.
What she is talking about is fusing a QI team and Principles with a Dev Team and principles
Agile is good if you do not over do it. Daily stand-ups? Short sprint times? (Scrum's take on agile) drove me crazy. I left.
Where you left to? I am tired too of ceremonies and looking for proper development methodologies with engineering practices in place. Design, document, take actual requirements.
9 passed. Nothing has changed.
Wow. Something must be done.
Now at least I see more people openly expressing their opinions
Most features are bugs, yet most bugs aren't features.
So if you are not looking for feedback from your customer, then perhaps this could be a issue. But if you are working with the customer and using the retros to examine the quality, and methods, this talk makes no sense. Gabrielle is describing Agile done incorrectly.
Where is yahoo now ?:D:D
Web development is actually quite harder than most people think. I mean for something that other people will use. Even if the code doesn't change the environment usually always is just very slowly
good softwares are made by good software engineers. You can't take a below average programmer and use Agile to turn into an average programmer.
Focusing on and giving importance to process is not going to improve software quality.
Agile process can not turn a dumb into a genius.
This. You can't create something out of nothing. Agile promises to take 2 number blind men and make them endlessly talk and somewhere in time they will produce a master piece drawing of they endure to keep in the conversation enough time, no matter they are blind nor have ever painted before.
Agile processes can't make a below average developer into an above average developer, but inagile processes *can* make an above average developer into a below average one.
Yeah because products were all so wonderful before agile. The truth is that most projects fail to achieve their goals in any methodology or approach.
But having worked in Waterfall and Agile, you have to be a crazy person to think there's LESS failure using Waterfall.
If you cannot go public because your revenue is increasing, something is really broken with the IPO system, you shouldn't fix the company, you should concentrate on fxing the IPO process.
+gmoschwarz in a world where looking good is all that matters, good luck with that :D
That is because IPO's don't happen when your company has a lot of potential, they happen after the easy potential has already been changed into growth, and the insiders want to cash out.
Point blank, get a good developer, tell them what you want, then LEAVE THEM THE FUCK ALONE TO DEVELOP IT!!! Boom done. Stop micro managing developers, it always fails.
Agile is doing a sloppy work with impunity.
I think you are wrong. I did both for years now. Agile has nothing to do with business requirements and innovation. Agile is how you do things after they are analyzed, measured and developed by business teams. Agile is best at getting business people more into product in an earlier stage. The rest is up to you. Therefore your toothbrush example is off the course.
madmaxl0l "Getting business people into the product earlier" translates to they start asking if it's done yet earlier.
Agile evangelists are explicitly anti design, anti analysis and anti documentation
Use experienced software developers that have experienced knowledge how users are acting. This will have the most money measurable. Get rid off bullshit telling fortune tellers. Or people that want to experiment with very new leading people that have no idea but know how everything might go better.
Kids this is what common sense looks like. Now, forget everything you saw here.
I don't think anything you said was original or interestingly novel. My company has explored many of these ideas and discarded them for very good reasons.
Good ideas but it's a mind fuck for a small startup. Tell you what. Launch a successful self-funded, bootstrap-driven startup working alone out of a spare bedroom, with no existing customers, no partners, no investors, and no existing audience of followers. Get back to me and tell me how much your CI/CD process helped, how you minimized your output, how you maximized your outcomes and minimized waste, how you conducted your experiments, and how you collected and analyzed your data.
I think this talk has a bad title.
Stopped after 2 min: in the manifesto that lady obviously didn't get the concept of "valuable software" if she thinks agile teams are shootings random features....
Clearly didn't watch the rest of the talk where she makes a bunch of examples where this actually happened
she and all her examples misinterpret: Customer collaboration over contract negotiation
Agile is like Socialism, it sounds good until you try it.
Lol
Fantastic skill: speaking for over 11 mins and not having said even a single meaningful sentence. 35 more minutes like this? No, thank you. I have a hint for you though: if your brilliant process is not working try to hire brilliant people, or one or two of them at least and let them drive.
“ Why are our products so bad?”
Speak for yourself please.
..."All they've done is push more through the system faster"... Yeah, that's the main point of Agile. I don't like machine gun metaphor; to that I say if you subscribe to that, you don't understand Agile, which Gabrielle obviously doesn't. She has missed the whole point of the Sprint Review/Demo/Showcase where you get the feedback from stakeholders to narrow in on what the product should be. The better metaphor would have been sighting in a sniper rifle, where you shoot and see where the bullet hit, then adjust the sights or scope and try again. This woman doesn't understand the process and should NOT have been a presenter, she's awful!
Obviously Gabrielle has worked at companies where agile meant just what she said it did. It's not her fault that the term was perverted into "push features through the door as fast as possible". Her talk is actually very good. You need to get over yourself and actually listen to what she had to say.
I found 4 unsupported claims in the first 2 minutes. I'm done.
She is overly self-convinced coming with totally self-evident black-and-white stories completely different from the gray reality and the surrounding politics.
all her stories revolve around misinterpreting: Customer collaboration over contract negotiation
3 minutes and I can't watch any more. WTF is she talking about? Not delivering the right product? What is Product owner job then? Right time, right place for the right people? That's why you have iterative development, so you can inspect and adapt quickly. Who is presenting on this conferences, I really have no idea
You are quit so quick! Anything will have weakness! Just the word seem too hurt you :D
Maybe the remainder of the talk would answer your questions
@Bike Vids Sometimes customer doesn't even know what they're looking for unless we show them the prototype or alpha version. I guess Agile mindset might be necessary in a sense at least other than complex sophisticated methodologies.
girl is actually smart, shame she's into business.
Sexist much?
Yeah, business sucks. It doesn't make the world or anything.