Agile Is Dead (2015) [pdf]
youtube.com
youtube.com
I then ask them to justify what they've offered against the Manifesto. If they're thoughtful about it (the Manifesto isn't always correct, and if you read it carefully leaves open the need for some of this stuff). If they simply insist it's correct they're cargo culting and we can move on.
What I've found is that the ceremonies are appropriately named in that many of the practitioners seem to not know what they're for or why they're done. The teams that seem to really excel are the ones that seem to have thoughtful managers that shape the practices of their dev group to the specifics of their work. The ones that seem to always be bogged down and require huge numbers of staff to get even small amounts of work done seem to be the ones that follow a checklist of getting as many of the agile practice "things" jammed into their work processes as possible.
I don't think Agile is dead, but I think it requires smarter team leads who look at what's come out of it as a set of tools to be employed against specific development challenges rather than a religion that needs worshiping.
I think it comes from a lack of experience which further creates fear and lack of self-confidence to challenge the practices of the cult.
It's also similar to the "nobody got fired for buying IBM" issue.
It's "nobody got fired for sticking to the established cult ceremonies".
They are people who are afraid and don't care about the team or the company. They are only concerned about their own job security and paycheck. So they never risk trying something that is not in the book.
The only way to get them to do something else is to make that thing the "new best practice".
Give it a tacky name. Send them to some conferences and get them a "Senior Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony and they will do it with their eyes closed.
Or maybe ... just fire them.
I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change?
I must at this point point out that I consider myself agile. I absolutely have skin in the game.
Now, to the language of managers.
I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile.
That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv.
So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.
The points made in the Agile Manifesto having me nodding my head in agreement more often than not. But the implementations, like Scrum, are another matter entirely. It has become a management methodology, further and further removed from the developers. And that comes complete with all of the trappings you'd expect: process for the sake of process, empty metrics (like "velocity") that can be passed up the management chain, and so on.
I read this all the time: The agile folks were right about software development, but Scrum/consultants/managers/process sucks! Everyone likes the Agile philosophy but then they all say it's never been implemented right. Reminds me of the "communism is the way--it's just that every time it's implemented it's done wrong!" argument.
My criticisms of Agile are: 1. It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress; and 2. it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc. A methodology that does not address these artifacts is going to have a hard time fitting in.
You don't ask the business if a refactor is okay, because the business doesn't know how to value or risk it. You refactor because that's what a disciplined professional does, in the course of their work.
Think of another profession, if that helps. Teachers don't ask students or administrators if a test would be valuable after a given lesson. Builders don't ask if a hammer would be appropriate for a nail, or if they should use an air gun. There's a certain expectation that they should know and do these things.
Scrum works if the scrum master functions as a mediator for the team to collaboratively prioritize work- ideally, this would be a role, not a job title. Scrum fails if the scrum master is just a project manager tasked with making sure the whole backlog entered by the product owner is done on time.
I'm not sure where this leaves things, but it seems to me that the differing incentives and negotiation between stakeholders is perhaps inevitable.
The teacher analogy depends entirely on the school district, and perhaps might apply more to a university setting than a grade school one.
As for the builder, of course there's a discussion between the builder and the client... On the desired results. What a disciplined builder won't do is ask "can we" when they know that the current status is structurally unsound or flawed. There's some substantial differences in cost / financing and risk between the professions, so it's a bit of a stretch no matter what, I'll grant you that.
If we can at least agree that there is a certain amount of discipline that embodies a profession, and that the agile manifesto emphasises priorities characteristic of that discipline (correctly or incorrectly) rather than a "business process" or "project management" scheme, then I think we're agreeing on the important points.
"Sprints" alone are toxic. To sprint is to exhaust all of one's resources, and rest. When was the last time you were allowed to rest as a developer? Most companies just say, "Sprints start every other Monday".
"Respond to changing markets" becomes "managers don't have to plan."
"Developers are in control" becomes "all jobs now belong to developers."
And finally, the most toxic element of all is the misapplication of agile. Agile works for websites and mobile, THAT'S IT.
You cannot plan infrastructure in 2-week increments (yes I've seen this attempted).
What is a sprint in RL? It's a race in which you only go a very short distance. As in: "Wanna run a few miles?", "Nah, let's just do a sprint and leave it at that."
But stick-management willfully misinterprets Sprint as a very fast speed implying you should get an immense amount done in a short time by magical means.
Which has led to the Agile guys backing off from the word, officially, I do believe. You won't find it in the Alliance Glossary, just "iteration": https://www.agilealliance.org/agile101/agile-glossary/
If overtime by software engineers were not exempted by law in many jurisdictions from being paid, I don't think this willful misinterpretation would happen so often.
The other remarks are all good responses to "cargo cult" Scrum.
No, it's not about death-marching the teams, it's about keeping a sustainable and realistic pace by time boxing activities, and constantly assess the velocity. The end goal is to increase predictability and reduce the number of concurrent activities in all stages of the "delivery pipe". Limiting the Work In Progress is a "Lean" thing.
Managers should have a goal and identified the needs, but premature detailed planning should be avoided. (Also a "Lean" thing)
"All jobs now belong to developers" is clearly not ideal but probably a reaction to a high ratio of non-developers which is typically not a good thing if the main product or services are software or produced by software.
I'll give you that dividing complex deliveries with many dependencies can be very hard - you probably can't plan or replace infrastructure in 3-week increments, but measuring and possibly delivering some sort of value in 3-week time-boxes is most likely doable, although realistically you'd probably go live in larger chunks. You still need a plan and most important a goal though.
One reason to be a bit fundamentalist here is to challenge the structures within a product or a company - maybe the bottlenecks just get more visible? Is it possible to divide complex behemoths into smaller parts, for instance? Maybe centralized solutions drives down fixed costs while increasing dynamic costs - those are typically much harder to understand.
From your experience.
This is a kind of No True Scotsman. If agile is working on massive multi-team, multi-site, multi-timezone, multi-company projects, then apparently it ain't agile.
My experience is different. I've seen it work and not work. Right now I'm seeing it work. It works well; the core of which is asking what's sucking and how we can fix it.
This seems to be a taboo for a lot of managers. They'll do almost anything to avoid listening to their own people and fixing the problems they mention. Only outside consultants or management further up can be listened to but not the people they manage.
The biggest risk in engineering is always the "dealbreaker." Some fundamental philosophical incongruity in the project. Usually, they take the form of a broken invariant.
When I was an architect, it was my job to front run my team, management and plan for every conceivable scenario such that I would never have to utter the phrase, "That is not possible."
You cannot plan a multi-year project in 2-week increments if I spoke metaphorically about websites / mobile apps-- what I meant was, you cannot design anything that really matters in weekly increments.
Imagine trying to design the space shuttle two weeks at a time.
Cloud Foundry is a multi-million SLOC distributed system developed by dozens of teams over many years, one week at a time. Yet it has an architecture that evolves on a multi-year scale.
Nothing in agile precludes architecture. What's precluded is ignoring change.
I don't know what else to tell you. A counterexample to your universal claim exists. So it's not universal.
I work for Pivotal, so I'm going with "yes".
> It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress
It says "over processes and tools", not "strictly instead of". If anything, good tooling lifts a lot of overhead out of the way so you can go back to individuals and interactions.
Of course, scaling this stuff is hard hard hard. But that doesn't make agile irrelevant, it just means you need to keep thinking and rethinking what you're doing.
> it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc.
Evolved XP+Lean is pretty much where Pivotal starts from. Engineers asking product and design questions is taken as status quo.
Sure, it's hard, but it's not about "agile can't scale". We've scaled it and doing so is painful and difficult. But any organisation passing the Dunbar limit is hard to keep on track. The classic methods work, we're surrounded by their fruits. But we're also surrounded by their waste. It's always worth questioning yourself and why you do a thing.
As far as I can tell the best implementations lean heavily on the Lean rather than Agile tradition; Lean has very similar values, but much better early operationalization of those into high-level practices which helps resist cargo culting low-level processes.
I'd guess most companies that call themselves Agile or decide to try Agile won't do that, but great companies can implement the Agile Manifesto in ways that make both developers and managers happy. It seems like a lot of agile consultants sell Agile by trying to convince management of it's benefits. That top-down approach conflicts with the Agile Manifesto's bottom up approach.
I'd think developers would generally be happier with Agile implementations that were led by developers, not management. I'm not quite sure how that would meet specific business needs, but I think that a lot of developer complaints come from management decisions. I agree that a lot of problems can occur when trying to let "individuals and interactions" drive progress. Of course, a lot of these thoughts are because I've worked at places with really corporate versions of agile, like SAFe.
Is there any methodology that scales that way beyond the fuzzy and personal "get somebody competent divide the work into small independent chunks"?
Any methodology that treats developers as replaceable gears will have the same failure cases. It's not Agile that is the problem.
If the captain and the navigators are incompetent, and the shipping company send you to the wrong port, then no crew can save the company.
The places were "Agile" goes bad, are the places where just about every management process goes bad. If too many don't know how how the sausage is made you get "list guys" running around with lists and metrics that don't make sense, reporting to committees filled with other "list guys", an ever increasing admin-per-developer ratio, and a productivity that slowly falls down to zero.
Faking process and order is much, much easier than actually managing the semi-chaos that a large development process is.
I have worked at two startups and there I think we implemented the Agile Manifesto. We talked to each other and got things done. There were no pure management types whose only job it is to report further up the chain. But these were teams with a max of 20 people so I am not sure how well this will scale up.
Religiously following the 'process' is the opposite of agile.
Being able to use your judgement to decide to do something is agile. In scrum you always do the same thing regardless if it's needed. Well in the implementations I've been in.
For the teams I've been on, daily stand-ups have been a drag, and it has been a major improvement to eliminate them. Similarly, 100% pair programming has been unpleasant for the majority of the team, and it has been an improvement to stop feeling guilty about doing a lot of solitary programming. The criticism that scrum tries to get you to run a marathon as a series of sprints also resonates with me. It never seemed to allow time for more complex and vaguely defined projects to flourish, but rather we would look back and see an accumulation of short-term thoughts, but little cohesive whole.
What has worked for me: code reviews code reviews code reviews, copious automated testing, a prioritized backlog, estimating size of work in some sort of abstract unit, burn downs, demos and retrospectives, short meetings with defined agendas, ignoring anything that makes up terminology, especially if any use of that made-up terminology includes a (TM) superscript.
The only worthwhile external measure of value is features that the team deliver (i.e. broadly counting improvements to non-functional requirements as features too). Velocity is meant to be constant (in an ideal world) to allow the Product Owner (i.e. someone _inside_ the team) a broad brush to provide estimates on when things may be ready — even used in this way, they depend on a stable team with a velocity that's not too volatile. They shouldn't be shared externally to try and show how productive the team are.
For example, I've previously had management ask if our team can try a bit harder & deliver another 30 points per sprint. As points are meaningless outside of the team though, that's a false economy: I think they got the picture when I said our team could deliver another 1,000 points per sprint if they wanted us to.
I'm not against meausring velocity, but I think it is a tool best used from within the team rather than from a management level
> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Or: They start comparing story points between teams which in reality is a totally meaningless thing.
Most companies have never cared and do not care for anything agile or anything manifesto.
For them Agile™ is nothing but a brand name and a weapon that legitimises the way they want to exert power over their employees.
They cherry pick elements from the methodology. Change it to their liking and slap the professionally accepted label on it.
That's how the pointy-haired manager turns daily standup to daily micro management meeting and daily beatings with a stick.
Basically no development methodology survives the conflicts of interest at play in the long run.
The behaviour is too sophisticated for it to be merely an innocent misunderstanding. On some level it is being knowingly manipulated and weaponised.
It's inevitable because essentially every methodology is a very fuzzy description of a set of ideas and practices so people and groups will interpret it in a way that benefits them.
If you think about the term polymorph ("many shapes"), that describes the world of differing objects that have the opportunity to satisfy an interface.
One of the things that still slow me down sometimes when designing something in C++ is its somewhat muddled concepts. The overlapping concepts make it harder to divide and conquer the problem to solve.
Rust is quite different regarding interfaces and benefits from many more years of research and experience, so I have reason to assume it does better.
My point is just that it's not only "modern" languages like Rust that have better support than C++ for this distinction.
Also, I haven't ever seen deep C++ hierarchies. That seems to be invented for Java.
Deep inheritance hierarchies are easy and cheap in Java (in fact, Java is deliberately designed to be good at them), but their popularity is older and wider; historically the early development of complicated OOP took place mostly in C++, with Java attempting to facilitate further complication with more modern tools.
For a well-known (and not too unreasonable) example of C++ deep class hierarchy, see the streams in the standard library of 20 years ago. The Java standard library copies them as closely as possible.
I meant "more of a contemporary" as more so than Rust (which my parent comment was talking about). Certainly the design decisions (especially when it comes to object orientation) appear to me to be driven by thinking more contemporaneous with C++ than Rust's do.
One way is to assign function pointers within a struct which is shared across top level functions. This is very common in C, such as in the standard i/o library. It is also very handy in dynamic module initialization in both C and C++, such what Apache httpd supports.
In-process C++ polymorphism of course can be done the same way, but using classes is the idiomatic approach. An interesting and highly useful form of polymorphism in C++ is tag dispatching[0] in templates. This can be complemented with usage of traits to achieve very flexible implementations.
A book I highly recommend which discusses these techniques as well as C++ templates in detail is "C++ Templates The Complete Guide"[1].
0 - http://www.boost.org/community/generic_programming.html#tag_...
example: see golang
OK, this is on topic, I swear. This notion of ownership can apply not just just to individual contributors but scales up to teams and even larger organizations. A team can own an entire major system for example.
Software organizations of any size at all need a process in order to ship usable software. Well-run software organizations don't just have a process, they own that process as in the sense above. The organization has the responsibility for the process, they have the authority to change it, and they understand it well enough that they can. Obviously such an organization can respond to deficiencies in the process and adjust it to work better. They can even revamp it completely if they need to.
Your Agile software development process isn't going to work well if you organization doesn't fully own it.
To get back to the point that I was trying to emphasize, a big problem with software development organizations is that often they do not own their software development process, making it essentially out of anybody's control.
I guess in a scenario like that upper-level management (e.g. the CEO) could try to take ownership of the process, but that's unlikely to ever work out well.