Agile Is Dead – Pragmatic Dave Thomas [video](youtube.com)
youtube.com
Agile Is Dead – Pragmatic Dave Thomas [video]
https://www.youtube.com/watch?v=a-BOSpxYJ9M
54 comments
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.
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.
Capital-A Agile is essentially collectivized micromanagement, and brings together all the well-known advantages of collectivization and micromanagement.
Why? Microsoft consistently develops some of the most popular products.
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.
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.
Visual Studio is awesome
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 :)
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 :)
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.
So true. Im not a developer but work in production, so much paperwork bogging down productivity.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Quite simply the order you do things is radically different.
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.
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.
> 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.
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.
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.
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.
Oh don't get me wrong, you have planning. You just do everything in a different order.
It is radically different because waterfall has distinct phases at a "global" level.
Planning(All planning upfront) Implementation(Implement all the plan), Testing(test it all) UAT.
Agile has these but does them at a feature level. So the order is radically different. Planning(Plan feature or small groups of features) Implementation(implement feature), Testing(test the feature).
You do this over and over again for each feature or little iterations. You may have more loosely defined global plan, but it is not ridged and is expected change as the world changes.
Waterfall also encourages to complete parts of the website in distinct phases. Either horizontally or vertically. Complete all the Data access layer, or complete all of the "account functionality".
Agile takes small vertical slices. You may want to implement just the login for the account management, but leave the user profile pages until after some other more important vertical slice in some other area like checkout.
It is radically different because waterfall has distinct phases at a "global" level.
Planning(All planning upfront) Implementation(Implement all the plan), Testing(test it all) UAT.
Agile has these but does them at a feature level. So the order is radically different. Planning(Plan feature or small groups of features) Implementation(implement feature), Testing(test the feature).
You do this over and over again for each feature or little iterations. You may have more loosely defined global plan, but it is not ridged and is expected change as the world changes.
Waterfall also encourages to complete parts of the website in distinct phases. Either horizontally or vertically. Complete all the Data access layer, or complete all of the "account functionality".
Agile takes small vertical slices. You may want to implement just the login for the account management, but leave the user profile pages until after some other more important vertical slice in some other area like checkout.
It's amazing to me that people compare a job that we have 7,000 years of experience with (making buildings) to a job that we have 70 years of experience with (making software).
Also the construction of physical objects obeys unchanging physical laws. The construction of software is the coalescence of arbitrary logic.
Real engineers decry the lack of discipline in software engineering, but I don't think it's possible to impose anything approaching the discipline of physical engineering without radically more constraints, but to do that would require subdividing software into a large number of much more focused domains, and even then, the divisions would be somewhat arbitrary.
Real engineers decry the lack of discipline in software engineering, but I don't think it's possible to impose anything approaching the discipline of physical engineering without radically more constraints, but to do that would require subdividing software into a large number of much more focused domains, and even then, the divisions would be somewhat arbitrary.
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.
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.
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.
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.
There were plenty of successful projects written using waterfall. Not a great fit for all, but not an anti-pattern.
You're just making things up now. Proof?
You really think there were no successful software before Agile came along?
https://www.quora.com/What-are-names-of-successful-projects-...
https://www.quora.com/What-are-names-of-successful-projects-...
Your proof is found in the entire canon of software engineering prior to the late 1980s, when the concepts of "prototyping" and "RAD" became feasible.
When code was written by hand with pencil and paper, then translated to punch cards, "prototyping" was an exorbitant amount of work. Moreover it added little value, as the first two entire generations of information systems were little more than electronic implementations of very-well-understood business processes.
I studied systems analysis / engineering in the late 1980s. At the time, the entire paradigm of software engineering was waterfall, with the exception that the idea of prototyping was just getting started as something you could do iteratively in the "design / build" boundary.
When code was written by hand with pencil and paper, then translated to punch cards, "prototyping" was an exorbitant amount of work. Moreover it added little value, as the first two entire generations of information systems were little more than electronic implementations of very-well-understood business processes.
I studied systems analysis / engineering in the late 1980s. At the time, the entire paradigm of software engineering was waterfall, with the exception that the idea of prototyping was just getting started as something you could do iteratively in the "design / build" boundary.
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.
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.
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.
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.
If your team is dysfunctional Agile will not fix that. Agile requires a functioning team that can communicate together and invested in working together.
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.
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.
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
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
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.
...
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.
> 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.
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.
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.
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.
2 weeks? I'd kill for two non-multiplexed days...
Yeah, it's a constant fight to keep things that way.
For teams that need to be more reactive/responsive to constant change (like my own), scrumban has actually been a pretty good fit. We're a small 3 person team who is expected to turn high priority items around quickly, while also running longer term projects at the same time. Scrumban let's us track both needs pretty well, and we even pull tickets from other team's boards that we get matrixed into, onto our own internal board. Highly recommend trying it if you're in a similar position.
For teams that need to be more reactive/responsive to constant change (like my own), scrumban has actually been a pretty good fit. We're a small 3 person team who is expected to turn high priority items around quickly, while also running longer term projects at the same time. Scrumban let's us track both needs pretty well, and we even pull tickets from other team's boards that we get matrixed into, onto our own internal board. Highly recommend trying it if you're in a similar position.
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.
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.
You seem to be using "Agile" to mean some particular methodology, probably (at least, this is usual when this mistake is made), Scrum.
But Agile isn't a methodology; it is a set of principles and priorities for use in determining (and adapting over time) the right methodology for a particular operation.
There are a number of methodologies that have been described as a result of (in theory, at least) applying Agile principles in particular environments. Scrum is one of those, but so is Kanban (and so are hybrids of the two, sometimes called "ScrumBan".)
But Agile isn't a methodology; it is a set of principles and priorities for use in determining (and adapting over time) the right methodology for a particular operation.
There are a number of methodologies that have been described as a result of (in theory, at least) applying Agile principles in particular environments. Scrum is one of those, but so is Kanban (and so are hybrids of the two, sometimes called "ScrumBan".)
I can't edit it now, but, instead of saying "Agile (sic) doesn't work well for service teams" I should've said "Choose your own flavor of Agile Methodology to suit your needs".
Kanban is an Agile Methodology.
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.
[deleted]
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!
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 >
[0] < https://news.ycombinator.com/item?id=11544367 >
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.
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).
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).
Just like in software development, a framework/methodology is not a replacement for competence. People apply idioms blindly without putting things into context.
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.
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.
I saw this a year ago too, its was a good watch.
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....
Not only with stories, but also world view.
[0] https://www.reddit.com/submit?url=https%3A%2F%2Fwww.youtube....
Very much worth watching. Agile is not a noun. :-)
if only.
I knew Agile was dead the moment that Microsoft managers started to "implement" it.