Agile Is Dead – Pragmatic Dave Thomas [video]

https://www.youtube.com/watch?v=a-BOSpxYJ9M

by dsego • 10 years ago

84 53 10 years ago

jeremiep• 10 years ago

I've seen that talk last year, great talk! I really like how he makes the distinction between Agile and agility and compares the values of the manifesto with the consultancy industry which spawned around it.

But I have yet to find a manager deeply believing into Agile who'll questions those beliefs after watching the video. I feel the problem with Agile is that a lot of the people who enforce it are either not programmers or terrible, terrible ones.

I have also yet to find an Agile project with actual agility, but that's just my own personal experience :)

Cypher• 10 years ago

I saw this a year ago too, its was a good watch.

forloop• 10 years ago

It was on /r/programming 4 months ago[0]. As far as I can tell, HN is behind the times, these days.

Not only with stories, but also world view.

[0] https://www.reddit.com/submit?url=https%3A%2F%2Fwww.youtube....

brightball• 10 years ago

Very much worth watching. Agile is not a noun. :-)

nathanaldensr• 10 years ago

Agile principles, in an academic sense, are great. However, for agile to work best, it's my belief that the team needs to be of a similar skill level, trust each other implicitly, and have the same value system (i.e., "we believe in writing software for the long-term", "we believe in being disciplined", etc.) Too often this is not the case. Many things are good in theory but once applied to real human systems, fail.

natec425• 10 years ago

I disagree with one of your three conditions; I don't think all team members need to be of similar skill. Particularly, I think agile practices can be very good for knowledge sharing between senior and junior developers.

As for trust and values, I might combine the two and say that members have to trust in each others values. For example, I don't want to bother to get my code reviewed by someone who doesn't care about its quality, and I don't want to put in the effort to review someone's code if they are only having it reviewed to satisfy the process. These differences in values can really suck the energy out of the process.

squeaky-clean• 10 years ago

I tried out Scrum at my company on a small team that matches these conditions, and it was incredible. I think the biggest points are the same value system, we all had the same standards for quality, and we were excited to try a new way of managing ourselves that we were open to adapting and being flexible about. And the trust to allow that to happen, and criticize the process without feeling like we were criticizing each other.

The Sprint Review sections were most beneficial, because we were all quick to say what we felt needed changing, and everyone was excited to try. If we did something radical, we could call a 1-week sprint instead, or plan the sprint that we could easily adjust it and start a new one if that method didn't work, just in case the new method ended up sucking.

The first month of it was weird, and eventually a few months in we were an extremely well-oiled machine running a system that was nothing like the original Scrum plan we followed, because we learned which parts worked best for us, and which didn't, and experimented with adding a few methods of our own to the system.

The rest of the company moved onto Agile/Scrum after seeing our small team, but I don't think the majority of them are handling it well at all. The process isn't adaptable, if devs speak up about things they don't like, the managers tell them to "trust the process" and give it time (BUT THE PROCESS IS ALL ABOUT CHANGING THE PROCESS AND NOT BLINDLY TRUSTING THE ORIGINAL PROCESS!!!), and many of them would rather not work in a management system that should adapt like that. I'll get asked for advice on why their daily standups aren't working, give feedback, "Well that would involve changing things, and we'd rather not do that..."

Really, they're just doing waterfall but with daily standups and a bi-weekly planning session which is mostly meaningless. Whatever, at least the team I'm on now is willing to play it the dynamic way (myself and another member of that original scrum team are in it), and we're enjoying it very much.

spydum• 10 years ago

As with anything, I think folks are trying to sell you tools for the "how" part. The trouble is always in the implementation. His point is very valid about poor architecture is hard to change... And I think over investment in tools/process for agile is precisely that.. When you spend more time and money filling out JIRA tickets and staring at Kanban boards and attended SCRUM of SCRUMs and hours long standups, you need to reevaluate if your process is doing more harm than good.

jamisteven• 10 years ago

So true. Im not a developer but work in production, so much paperwork bogging down productivity.

EvanPlaice• 10 years ago

The question that should be asked in that case is what purpose does excessive paperwork cover?

In my experience, it's usually poor management looking to cover their own ass when deadlines are missed and/or establishing a track record so if they need to fire people they have a legally justifiable reason.

ebbv2• 10 years ago

I think the problem is that people think Agile is a magic potion to fix dysfunctional teams and it isn't. Agile only works if your team works well together. There's any of number of ways for the team or the PO or the customers to make sure a project fails, whether you're operating in an Agile way or not.

We switched to SCRUM last year at work and things have been amazing. My tune may change over time, but when we stick to the system we've developed things are great. 80% of our time is about getting work done. We focus on one project at a time and we deliver high quality code.

But there's more ways to make things fail than there are to make it succeed, and Agile is not a solution to people being terrible.

JoeAltmaier• 10 years ago

I was under the impression Agile was just the opposite - used to give structure to dysfunctional teams so they could learn to work together? Old established teams don't need more structure - they have grown processes that work for them.

ebbv2• 10 years ago

Agile doesn't give structure when compared with Waterfall (traditional project management), usually an Agile system is less structured (at least IMHO), and will have less meetings, shorter planning discussions, etc.

If your team is dysfunctional Agile will not fix that. Agile requires a functioning team that can communicate together and invested in working together.

jschwartzi• 10 years ago

People don't get dysfunctional just because they have no structure.

When people talk about dysfunctional teams, they're referring to behavior similar to that found in a dysfunctional family.

https://en.m.wikipedia.org/wiki/Dysfunctional_family

UK-AL5• 10 years ago

Agile has a lot less structure compared to traditional project management.

Decisions are made by developers, peers review each other instead of managers etc

Agile is about letting go of the traditional command and control thinking(Managers controlling employees, managers approving work, managers setting deadlines), and into trusting your developers to make good decisions, trust that they are not slacking and peer review.

inanutshellus3• 10 years ago

As a counter--FWIW--Agile works really well for me and my team. We work with 8 people in a "pod", we dogpile onto backlog items and destroy them. We pivot when the needs change. We trust each other but review the commits anyway. We don't do scrum-of-scrums (they're a symptom of a problem IMO), we minimize and mitigate any effects of external dependencies (e.g. our very first task in a project requiring them is to mock their expected/future implementation)

...

We also eschew software solutions to sprint management, which matters. We also don't bother with morning stand-ups. ("Wait, you don't do morning stand-ups?!" - Yep. Morning stand-ups are training wheels for effective teams, and are necessary for folks that aren't co-located.)

Anyway. I know that "wait, no, this actually works" doesn't sell books or tools or get clicks, but just know that folks proclaiming its death are probably selling you something. Like... video clicks for ad revenue.

vonmoltke• 10 years ago

Morning stand-ups are training wheels for effective teams, and are necessary for folks that aren't co-located.

They're also necessary for teams where people are working on multiple projects at once. All the happy stories I hear about Agile come from people in your situation, where you have a team of X all concentrating on a single project. I'd love to be in that situation for once in my career.

pbrb2• 10 years ago

This is so true. I see Agile be incredibly effective for teams with a single focus, and no (or very minimal) matrixing of team members across other teams. Once you start matrixing team members or adding additional focus, you start getting the 45 minute long stand ups. It's nuts.

One insanely massive benefit I've seen from agile for any team is time blocking via sprints. Getting 2 weeks of effort without changing priorities is a huge win in our company.

inanutshellus3• 10 years ago

Agile does not work well for service teams like tech-ops and stand-alone qa teams. Strict kanban works better for those.

It still does work well for us even when we have multiple projects. Those multiple projects are time-sliced rather than resource-sliced whenever possible. In other words, keep your team focus on one thing for a given day. It's harder to get buy-in from your team to try it than it is to actually do and see succeed.

kabdib• 10 years ago

Management: "You mean there's a software development methodology that lets us track dev progress with a microscope, and that eschews planning (which we hate and suck at anyway)? And bonus it makes us look hip and with-it? Sign us up!"

I knew Agile was dead the moment that Microsoft managers started to "implement" it.

UK-AL5• 10 years ago

Why? Microsoft consistently develops some of the most popular products.

na85• 10 years ago

Microsoft's products are popular due to excellent marketing, not because of their technical merits.

Most of their products are mediocre at best, and many of them seriously suck. Particularly their operating system.

IMHO the only thing MS has produced that's actually good is Excel.

kps• 10 years ago

Capital-A Agile is essentially collectivized micromanagement, and brings together all the well-known advantages of collectivization and micromanagement.

simonswords82• 10 years ago

Hmmm....I understand what you're saying but we still use agile at my software company and as one of its managers that's not my take. Here's my view on the points you've raised:

It does allow us to track dev progress, but with great power comes great responsibility. We don't micromanage our devs but we do use the data this produces to keep clients up to speed on development progress. This allows us to be mega transparent, generates trust and this makes clients happy and less prone to worrying.

We still plan, but we don't try to plan the full project ahead of time, we all know that never ends well. We work with our clients to plan 2 x two week sprints. When those sprints are complete we pull them back in to get their feedback and decide what needs to be done in the upcoming sprints. This gives clients flexibility as they often need to change their minds when they see the finished sprint. It works for them and us.

Agile in and of itself doesn't make us look hip unfortunately. Trello, the tool we use to map out sprints and report on progress does though. Our clients love it and it's revolutionised our relationships with them. In fact, a major reason we won another big contract just last week was due to the approach I've outlined above.

mrharrison• 10 years ago

Agile works fine. I find that people are broken and don't want to change, or they want to adopt some magic formula by talking about it a lot but don't actually practice it and when they run into problems they blame the process they weren't practicing correctly. If somebody has a process to change people's bad attitudes I would love to learn that.

character0• 10 years ago

I've definitely seen the benefits of agile for my teams, but where it starts to fall apart is when the focus is velocity. This means management doesn't really have a clear goal, only that they are getting somewhere quickly. This leads to burn-out and typically those dev teams have no connection to their customer either.

riprowan3• 10 years ago

The problem I have always had with agile is that it's held up as an "alternative" to waterfall, when in reality it's orthogonal to the two areas where waterfall excels: top-down project planning and contracting / expectation-setting with stakeholders.

Agile is something that team programmers really love for its team-building qualities, but stakeholders / project sponsors / angel investors will always think in terms of deliverables and timeline.

Waterfall project management is useful because it provides a framework that stakeholders understand. It is also a requirement any time you are dealing with a bureaucracy of any sort, where deliverables and dates will be required.

TL;DR don't use waterfall to break down tasks and assign work, use agile for that. Use waterfall to understand and communicate your project from your stakeholder's / customer's point of view.

UK-AL5• 10 years ago

If your team uses agile, but you report using waterfall. Your reports are not mapping reality. It's just lies to keep people happy.

Quite simply the order you do things is radically different.

douche2• 10 years ago

It's just lies to keep people happy.

That's like 99% of business, anyway. There's a difference between what people think they need to know, and what they actually need to know. Unfortunately, just doing the work isn't enough, most of the time you have to play the game and tick the boxes. The key is not letting that bullshit consume your time.

ssmoot• 10 years ago

It's not though. This is why Agile is such a failure. Because people don't actually read the Manifesto.

It doesn't say planning is unimportant. It doesn't say contract negotiation is unimportant. It doesn't say timelines and knowing what you're doing is unimportant.

You can and should do all these things. It's amazing to me that Software Developers seem to believe their job is somehow unique and it's just not possible to do simple things General Contractors and real Engineers do every day.

Agile is just a set of values that amount to "be pragmatic and flexible".

You can totally do that without Scrum and avoiding any sort of planning until the last possible moment.

IME actual requirements almost never change in software. They're just frequently not surfaced until code hits the page because little to no due diligence was done on them. And I very very rarely see a case where an issue with fulfilling the client's desires as given couldn't have been surfaced and resolved very early on if someone had just sat down and thought about it for a few minutes before going off and promising something that couldn't be delivered in the time or budget allowed.

riprowan3• 10 years ago

The idea that waterfall and agile paradigms aren't compatible is incorrect in my opinion. They are orthogonal.

Waterfall is just a paradigm that people comprehend because it maps to reality:

1. First you have to initiate something and define some sort of scope, otherwise, why are you even here?

2. Then you have to refine your understanding with more design

3. Sooner or later you have to actually build something, otherwise

4. Eventually you will have to deliver and implement it with humans in front of it

5. Someone will have to live with it for a while.

That's reality, on any project. How you choose to step through these phases - rigidly or fluidly, linearly or spiral-y, or linearly but recursively, doesn't mean that they don't exist in reality.

Likewise, agile is a paradigm that developers comprehend because it maps to their reality.

If you build software for customers, how you do it is your business, but you will be best off if you can frame it in a way that makes sense to the customer. Especially if that customer is the Department of Defense or some other customer who will demand deliverables on a timeline.

I've been building software professionally since the 1990s. As someone who learned programming at a young age, prototyping is my natural way of problem solving, and I think it's intuitive for most "natural programmers." So while I was taught "waterfall" in school and have always used it with my customers, I have always built by prototyping. My customers love it, because on the surface they see a software design process that they expect, and I can communicate my progress with pretty Gantt charts and familiar terminology.

YMMV, but it has worked great for me for decades.

sbuttgereit• 10 years ago

I can definitely endorse this point of view. I've had success with it a number of times now. I think part of the key here is to recognize that you are working on a project (including managing it) in service of those that will consume the results.

The mistake I often times see is that people forget that and end up in service of one methodology or another. Too many times I see a project manager types that can't reason out the distinction between the mechanics of a given project management process and the goal that process is setting out to achieve through the mechanics. Once you focus on what you're trying to achieve in any process, rather than how you're trying to achieve it, you can adjust your process to be optimal to the team/customer/etc. It's not all mutually exclusive and there are rarely benefits for being loyal to a methodology for purity's sake.

ap222132• 10 years ago

Until recently, 'Waterfall' was used to describe a process anti-pattern. At least, it was prior to 2010 or so.Software engineers have known for decades that iterative and incremental processes (spiral, UP, etc.) work best to manage risk, to prioritize important requirements, and to align with user goals. I'm not sure exactly when people started to use 'waterfall' as a real process.

Recently, I've started educating my team on OpenUP (a simplified RUP), and they were surprised by it. I guess they imagined that software management didn't exist before SCRUM.

collyw2• 10 years ago

There were plenty of successful projects written using waterfall. Not a great fit for all, but not an anti-pattern.

lanestp• 10 years ago

That was a fantastic talk, well worth the time. If I can summarize my takeaway it would be that Agile or agility is a holistic thought process to guide all your software decisions. The way people have implemented it is to have rigid guidelines that lets middle managers micromanage us to death. Sounds about right!

p4wnc62• 10 years ago

This is very related to a comment [0] I made on another post yesterday, and some of the follow-up comments there.

[0] < https://news.ycombinator.com/item?id=11544367 >

daxfohl• 10 years ago

I agree with the view on testing. I mostly use testing as an excuse to shape up bad old code when starting work on existing products, then delete the tests afterwards.

perseusprime11• 10 years ago

Agile is dead from day 1 as you can never be truly agile by simply changing the software development process to agile. What about financial processes like setting annual budgets. This is what happens when you put a bunch of white guys in a Lodge in Utah.

p4wnc62• 10 years ago

One of the main ideas put forward by Thomas is that the generic agile principles are basically a reflection of gradient descent: take a small step in the direction you think you should go, evaluate the value of doing so and the error generated, then repeat. For a well-posed problem, you'll converge without taking huge steps generating tons of short term inefficiency.

Real world Agile is effectively like taking this gradient descent idealization espoused by the agile creators and turning it into simulated annealing instead -- a vastly slower, dumber optimization method with no guarantees about avoiding local extrema.

This analogy carries you pretty far. It's all the extra political, bureaucratic, micromanagerial stuff that creates the effect of random displacements, as in simulated annealing, instead of calculated, deterministic displacements as in real gradient descent. (And hooking up user and customer feedback as a major driver for the displacements is one of the worst failure modes for this.)

For me, the trouble is that "real agile" (i.e. the "good" and "not manipulated" principles) doesn't provide any mechanism for explicitly preventing this kind of political subversion. It's just too easy for middle managers and bureaucrats to subvert for their own purposes, while shoving all the negative externalities of doing so onto lowly developers.

I don't particularly like Agile because I don't think one-size-fits-all approaches will ever work (e.g. every sprint must be 2 weeks long, every workflow must involve story points, etc.).

But if I had to think about a way to vindicate Agile and protect it from subversion, I would suggest it needs some kind of explicit statement that short-term business concerns are not valid excuses for modifying the process. Of course, then managers won't like it ... because they only like things that give them metric surface area with which to politically manipulate the situation for their changing agenda, and so Agile would become impossible to sell to huge companies.

It's a Catch-22. Actually good software dev practices that make money, make customers happy, and live up to quality standards instead of just paying lip service to them are completely at odds with executives and managers who want to torch the commons for the sake of short term bonuses and couldn't give two shits about whether it makes customers unhappy, etc. (because they will have secured blame insurance against that anyway, and may even make more money from endless irrational tech re-orgs).

matdrewin• 10 years ago

Just like in software development, a framework/methodology is not a replacement for competence. People apply idioms blindly without putting things into context.

ljw1001• 10 years ago

if only.

Agile Is Dead – Pragmatic Dave Thomas [video]

Related Stories