Agile Is Dead: The Angry Developer Version
rubiquity.com
rubiquity.com
That last point--the key role of intuition--is one of the biggest reasons you can't package up effective coding as a book, a manifesto, or a training session. Which implies something managers may find distressing: There is no silver bullet; a coding team's only salvation is smart coders.
80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.
Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtful use of tools.
About tools: My tools are important to me, but I don't see them as a silver bullet. It's like if you asked a carpenter about a "hammer-centric methodology." She would laugh. She'd say yeah, she uses a hammer all the time, but her hammer use doesn't amount to a methodology or a philosophy. Hammer use just comes about naturally as a consequence of recognizing nails that must be driven in.
Similarly for software: I don't use to-do lists because they're "agile." I use them because I need to remember the 20 different requests my client made yesterday. Could I live without Asana, Basecamp, or what have you? Sure. I'd just write my tasks in a text file. What if I couldn't use a text file? Then I'd put sticky notes on my wall. I need tools (everyone does), but I don't deify them.
> 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company follows this is the most accurate single predictor of whether it succeeds. So methodologies do, in fact, get projects done.
I agree with all of the above except for the statement that "methodologies do, in fact, get projects done." I think the reason we disagree is that we mean different things by "methodology." I take "methodology" to mean a formalized process, like a recipe, that you can follow mechanically. By that definition, agility is the explicit rejection of methodologies.
But then, I'm not the god of word definitions. I don't get to say my definition of "methodology" is right and yours is wrong. So perhaps it's fair to say that we're each right insofar as we're permitted our respective definitions of "methodology."
Then I remembered one I saw just the other day:
> We offer a highly configurable Agile and tools-based software development methodology
They also have an "execution-focused leadership team" and "offer a number of flexible outcome-oriented engagement models assuring the success of our projects"
The whole page is like that!
So many companies write this way. I could believe they do so only because their staff never learned how to write good sales copy. Or is there some actual merit to it? Do they know something I don't--namely, that buzzwords sell?
> We are an innovation focused services firm with 100% focus in the emerging technologies. This razor sharp focus has allowed us to differentiate from our competitors in many different ways:
The larger team definitely produces more intermediate artifacts than the smaller team. You could say there's more process in that team. But it's still not formalized as a methodology. The larger team mostly just muddles along. I'd actually prefer to organize the larger team's tools a little better, e.g. maintaining a single, sane VCS. Even if we did that, I wouldn't claim we're following a methodology. (By my definition, artifacts and tools do not a methodology make.)
None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.
In that metaphor, traditional waterfall is a land mine filled with plutonium shrapnel and anthrax spores.
Some times you have a clear and well understood problem, and failures are very expensive. You'd be crazy to work on such kinds of environments with anything but waterfall.
Some people have to do underwater welding, but the methodologies there aren't appropriate for building cabinets, even though they are both types of construction.
Good craftsmanship is usually correlated with a good end product, but craftsmanship for its own sake is a hobby, not a career.
Yes!
Smart coders who understand that they're part of a team.
I've seen at least as many problems caused by people not working with those around them (whether they be other developers, users, testers or whoever) as caused by rank stupidity.
That's not to say there needs to be a massively formalised way of working together, just the fact that other people are involved needs to be a central part of everyone's thinking.
EDIT: A central and constructive part of their thinking I should say - thinking "I need to steer clear of all these other bozos" I guess qualifies as a central part of someone's thinking but isn't what I was getting at.
Believe it or not, I've seen waterfall work, I've seen waterfall fail. I've seen agile work and unfortunately I've seen agile fail more often as people who don't understand what they're supposed to do create a clusterfuck of a process that just gets in the way. there was an article on HN not too long ago by an old school developer about development methodologies and how he didn't really think it made a difference. What he saw made a difference was how well the team communicated. People over processes, the very discussion of "Agile" ad nauseam violates that very rule. For crying out loud the process will not save you! try to find a process that will not get in people's way while allowing people to communicate effectively. I'm sure that some social scientist might have a better idea on how to solve it than another random developer who thinks he's God's gift to mankind.
Not in my experience. If there are a bunch of PMs and managers, you're going to find that they keep right on doing management and PM stuff, no matter what Agile Manifesto they think they latched onto.
Management: "This project is going to take you 13 sprints."
Right away, you're in trouble.
Management: "What's with your burn-down rate? We're four days into this sprint and we don't see any progress."
What replaces management is micromanagement.
Manager in the middle of the daily scrum: "Okay, let's go around and get status from everyone."
Yup. Status. For management.
Management: "You need to drop what you're doing and work on feature X for next week."
"But we're in the middle of the sprint."
"Oh, that."
To make it really work, you have to start nuking job positions. And at a big company that is hard.
Bingo. You know the MacLeod Pyramid (Losers, Clueless, and Sociopaths)? Most of "Agile" methodology is Revenge of the Clueless. It's a great way to replace a company with one long meeting that never ends.
But you can hit an impedance mismatch before that. You can hit it within your team, if you have developers who think in terms of following procedures instead of in terms of working code that creates value for the user.
* Agile Critisism: The snake oil is all over and getting worse!
* Agilista: It's not done properly!
* Agile Criticism: No True Scotsman!
I think the NTS is where things usually leave the line and end up in a lot of splutters and anecdotes.
Sometimes I wonder if the great flamewars and their arguments should be canonized into standard textfiles and passed around. Much like the old story of joking by only using numbers. :-)
Outside of this kind of concrete instantiation, "Agile" seems to diverge into, on the one side, a combination of empty buzzwords and arbitrary churn where no one knows who is responsible for what or what standards are because there is no process, or externally-defined prescriptive processes of exactly the sort that the Agile Manifesto was a reaction against.
People over processes has to mean processes are tools that serve the people on the team, not "no process" or "process taken as received wisdom because of respect for the person or institution originating it".
More importantly, they're daily status reports to each others, internally to your team.
Some examples: standups becoming daily status reports, the customer demo becoming it's own production, and let's not get started on retrospectives.
Agile certainly isn't unique in this regard. I've seen an MVC project with only one action on only one controller which had a ton of parameters to control its behavior. There's a balance between "I need to thoroughly understand how to use this concept idiomatically" and "I don't have time to read up on another buzzword."
Further remark: I figured I'd just bypass the otherwise-upcoming NTS yell and just clear the air so we could all go for the random anecdata and general arguments about Waterfall! Bad Agile! Scrum Masters! and how they caused problems.
The Agile Manifesto is a simple set of 4 values and 12 principles to aid in building software, that's it. The different signers of the manifesto had different visions of implementing it, Schwaber's was Scrum, Beck's was XP.
Saying that a particular methodology isn't a silver bullet therefore it's Agile's fault is a bit like saying science is dead when we disprove a theory.
If I had the memory erasing device from the Men In Black movies, I would use it on people who advocate for by-the-book scrum.
But, I feel like the boss is more interested in the methodology than actually finishing our project, which is frustrating. He came from big corporate, went to all the seminars on scrum, and things it's the answer to everything.
Adding/Removing stuff is the whole purpose of the retrospective, the last feedback loop of scrum, feedback on the process itself. That should be the first thing you add and the last thing you remove.
"By-the-book" scrum is like applying all the GoF Patterns in your project. But yeah, I'm nitpicking, I know what you mean: I see around me plenty of positions for "Scrum master, good at removing impediments, x years line management experience, expert with Microsoft Project, no development experience necessary ..." and I'm thinking WTF ...
RUP is agile. You are not supposed to implement everything that's in it - even better, you are supposed to pick one stuff at a time if you face the specific problem the new stuff is supposed to solve.
Don't you really see a problem on describing a ton of rigid procedures, that only work well in concert, and expect people to "pick just the ones that are usefull, be reasonable"?
That is your problem right there.
7 years ago, scrum was taught as a toolbox. Each "procedure" had a goal. Reaching the goal mattered, not following a recipe like a lemming. It was for example perfectly reasonable to get rid of the daily standup in a 3 members team, if you have plenty of interaction with others already. The core of the methodology fitted in a single page.
All the above FYI only, no need to call the True Scotsman to the rescue, I'm convinced: from the other comments, scrum looks more like Prince2 than anything else.
a) To get a collective frame of reference going, especially if the team is not just 3 dudes who already know each other.
b) The most open and direct way possible to confront a disfunctional organization with all the elements (mostly, people) that stop them from being agile.
Of course, once you get into the swing of things, take off the training wheels and fuck Scrum.
As Dave says, there are a whole bunch of people selling heavy tools and frameworks and calling them "Agile" where they are anything but. Safety, to pick the obvious example, is not an Agile value, and numerous commentators have called SAFe nothing but RUP in Agile clothing.
Declaring Agile dead seems a bit naff, but obviously the manifesto lacks values and principles to address Dave and Richard's concerns.
So I've kicked off an initiative to do exactly that. Agile: The Next Generation or A:TNG for short, augments but does not replace the Manifesto values with four new ones specific to Agile at scale. It offers pattern languages (not frameworks or methodologies) based on Kurosawa's The Seven Samurai" and the thousand year Iroquois Confederacy.
Most importantly it rebases the whole Agile Alliance shtick on github, where it can be properly open and we can properly self-organise and evolve it without some clique of middle aged white guys dictating to the community at conferences.
Details and some starter patterns are up at http://agiletng.org .
So, yes, Agile is dead. And long live Agile! -- Peter Merel.
This can be done in a pseudo-Agile way and coupled with a continuous integration process, which is what most companies call "Agile". Releases get cut every few sprints, so the product guys are happy. Developers hate it because all process that interferes with coding is bad, but it's still better than a traditional 6 month waterfall cycle.
It's not really Agile if you're being a purist, but it's a good compromise that keeps the business happy with the visibility they get while still releasing code on a relatively short cycle. There will always be process in any sufficiently large organization, since we all have different opinions on how to do things but we need to be on the same page.
Agile is about a team and how to make it deliver a product as fast as possible. (that wording can be misinterpreted, but that is for HN audience not PHB)
The key tenet of agile is that people just can't estimate - so sure fine, use magic PM formula - experience, whatever, anything to have a budget approved, but as soon as the real work start, don't bother your developers with it, just get it done ASAP. Agile can help you to estimate better on the long run but not really because of agile directly, but because agile facilitates creating a consistent more uniform development team.
As for developer productivity, at best it will because more apparent who is slacking in a agile team, but if management listen to metric rather than their team lead or the developer themselves all they are measuring is people successful at producing the right metric.
Accountability, that's a corporate issue. When accountability is an issue in a company, it means that somewhere along the line it lost the ability to stay focused on the end product. Your teams are not working together toward the same goal so you need to find "people to blame". Not quite sure how that is related to agile, you do not make people working together by having them stand up everyday 15 minutes with others or fill a whiteboard with stickers.
The problem is that following a methodology like SCRUM, it is possible to produce a shit-ton of metrics, and that's what make managers wet. Those metrics are useful feedback for the team, but if you use it for anything else, you have just recreated the old 90's LOC stupid productivity metrics with fancy looking new terminology.
They are usually so clueless that the concept of thinking outside the box and adjusting what they 'learned' from book/seminar is unknown to them.
So if company you want to work for has a 'SCRUM MASTER', do your self a favor and run.
If you see them as a practice, it vary team to team, project to project, time to time. Agile is NOT dead. It was not there at all.
The top-down closed-allocation organization cannot hit technical high notes. At that, it is unfixable. The best solution (see: large companies) is to let your best people work in an effectively open-allocation setting (while the peons toil under closed allocation) but, as has been discussed in other threads, that becomes politically difficult.
Rather than trying to fix closed allocation, which we can't, we should be throwing it out. It might work for a hedge fund that can afford to pay $5 million per year to a mediocre trader. It doesn't work for tech. Never did, never will.