In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: They advance by leaps and bounds, they stagnate, they regress, they sputter along, they bloat--often all at the same time. Sometimes you write tests first, sometimes you code first. Sometimes you whiteboard first, sometimes you write up a detailed spec. How do you know what strategy to adopt at any given moment? You can try to formalize it all you want, but in reality, the choice is usually made on intuition.
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.
What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that.
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.
> What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that.
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."
I thought you must be kidding about the "hammer-centric methodology": Do companies actually say they have a "tool-centric 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"
Wow. I've always wondered: Is this kind of empty, buzzwordy writing effective? Does it sell?
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?
I think it's a joke, just based on the obvious word reuse:
> 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:
Maybe. Though the page, taken in the context of the overall site, doesn't scream satire. I'd be disinclined to put a joke page on my consultancy's website, but if I did, I'd be sure to make the joke 110% clear. So my suspicion is that the word reuse is just the writer's habit, not evidence of a joke. (Many writers have such habits, especially amongst those of us who aren't writers by trade.)
I've actually had some personal interaction with this company, and I'm pretty sure that the writing style is not satire and not a joke. It's the way somebody actually writes.
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.
Agreed 100%. I like your metaphor of lead bullets. There's no silver bullet that will win a war, but you sure aren't going to win without putting the lead bullets in the right places.
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.
I believe that clear and well understood problems with expensive failures actually exist, but are rare enough that the lessons there aren't really instructive for the vast majority of professional software developers.
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.
I'd disagree here and replace that with "fufilling business needs" - the highest quality code is meaningless if it doesn't do what your customer wants in the way they want it done.
Good craftsmanship is usually correlated with a good end product, but craftsmanship for its own sake is a hobby, not a career.
Very likely, you have agility without even striving for it. I've met some teams that didn't adhere to "Agile" but were still working in an agile way. It's very possible to have agility without labeling yourself. Kudos to you.
Thanks! Yes, I'd say "agile" is an accurate adjective for how I work. It's the work style towards which I gravitate, absent any external pressure. Agility with a lowercase "A" that is, because I don't claim to meet any official definition of Agility.
You obviously have a process. It's just that you haven't formalized it yet and/or that it's too convoluted to be easily expressed in a marketable form for most human beings.
One team varies from three to six people. Another has maybe 20.
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.)
Teams beyond a certain size seem to require some intermediate artifacts. (Bill Joy described an ideal-sized team to be the number of people who can sit comfortably around a dinner table: so 3-6 is fairly perfect for his definition.) It seems like small teams can just keep each other in sync with quick conversations. They seem to be able to keep the design and requirements in mind at all times. Maybe it's the scope of what they're trying to solve or maybe it's some residual overhead that larger teams create due to additional communication "friction". I'm not sure. It's interesting though.
the notion that developers somehow intuitively know agile and management is ruining it is straight up BS. I know plenty of developers who jump on bandwagon x and then without any understanding proceed to screw the pooch for all of us. The drive to look smart is so important to some(maybe most) people that they'll gladly throw the whole team under the bus so they don't have to appear to not know.
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.
> the notion that developers somehow intuitively know agile and management is ruining it is straight up BS
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.
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.
Agile's great. But somewhere up the chain of command, it runs into somebody who views the world through 17-page PERT charts. At that point, there's an impedance mismatch. The "agile" tools help the boss feel better, even if they're a complete misunderstanding of agile. (This is not a trivial problem, by the way. A boss several layers up who doesn't get the expected reports can decide that your project is floundering, no matter how well things are going in reality.)
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.
I've seen this cycle a few times. Let me handwave how it goes:
* 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. :-)
In this guy's defense, there is a lot of Fake Agile out there. People (business people, project managers, mostly) seem to think that Agile means using a new set of buzzwords. Standups? They're daily status reports to management, right?
It was in my organization that I first heard the word "Scrummerfall." People learn the tools (stand-up meetings! Stories! Sprints!) but not everyone bothers to grok the purpose (I haven't seen "good agile" yet so neither have I).
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."
It doesn't have to be that way. Agile has a ton of advocacy, it just needs the right advocates that really understand it to help guide teams in the right direction. Agile has been entirely too driven by salesmen the last few years.
The Agile Manifesto is a great starting point, but beyond that I think Agile is too poorly defined; I think the values of the Agile Manifesto are best made concrete in terms of a high level meta-methodological framework in Lean methodologies with (under various names) the PDCA cycle wherein teams have ownership of their own specific processes, strictly follow the processes they define, have clear success metrics, propose process changes from within the team when there is an observed problem with the existing process in meeting desired results, and do empirical tests of the proposed changes using the success metrics.
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".
This seems illogically dismissive, unless you're criticizing the lack of actual discourse instead of the critics as a group, which I'm not really clear on. It comes off as "The Other Side has nothing to go on but insults and logical fallacies."
If someone wants to intelligently go after the Agilist community or intelligently defend it, they are my guest. But frankly, both sides throw anecdata, insults, fallacies, and feelgoodisms out there by the truckload.
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.
When I get constant messages from recruiters regurgitating phrases like "We're a bleeding edge Agile shop with Angel investor funds looking to disrupt the marketplace," I want to kill myself a little bit. I get so sick of all the buzz words and hype in our industry. Goes with the territory I suppose.
Repeat after me: "Scrum is Agile, but Agile is not Scrum"
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.
Scrum 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.
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"?
> a ton of rigid procedures, that only work well in concert
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.
The only reason I would be hesitant to do that would be the baggage that the term "scrum" has with so many good people. If someone hears me talking about scrum/agile/whatever and I remind them of the last snake oil infused zealot they worked with, I have immediately lost some credibility.
I'm contracting for a small company that uses by-the-book scrum. I like the idea of it and it allows us to easily see what needs to be done.
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.
The choice of syllables is irrelevant. The choice of values is what matters.
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.
All this Agile purism is great. I'm glad we're having the discussion, because that's how we can breed some understanding. The only problem with "pure" Agile is that it doesn't scale past 10 or so developers. If you're developing a sufficiently complex product, you need process. You need specs that can be distributed to other teams so they can build around the planned changes your team is making to its module.
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.
I think it is important to note that the Agile manifesto does not say we don't need the things on the right. Instead it says value the things on the left over the things on the right. For example it doesn't say you only need people, no process - that would be ridiculous. What it does say is that people are more important than process. In other words, make your processes fit your people not your people fit your process. Processes and tools are a good thing...if you use them as aids rather than straightjackets. As a final thought, consider the quote 'Justice, tempered by Mercy'. I hope that we can all agree that all justice, no mercy would be very bad. I hope we can all also agree all mercy, no justice would be very bad. We need both, one tempered by the other, just as we need both sides of the Agile manifesto list -- as long as we value the items on the left more.
I've been saying the same thing for quite some time. What I have no found the answer for is how to respond to managers that claim the "agile" process exists to measure developer productivity and accountability. Thoughts?
"Measure developer productivity and accountability" is already looking at the problem the wrong way. A bit like saying a GPS exists to measure car speed and facilitate insurance paperwork.
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.
Heh, from my experience if the company has 'Certified Scrum Masters' they will try to apply everything they learned (while pinning their certificate to the wall for everybody to see) into development process.
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.
Yea it's sad Agile method is now a marketing word, a marketing trend. Same goes for Big Data, any marketing guy with a 100k row DB think they are doing big Data, sell it as big data...
For me agile is a way of making bringing what's wrong with your development painful and front and center, forcing you to address it. As such many people don't like this and as a result agile tends to get warped into whatever process it is they had before, but now it's just called agile. And this is why almost everyone can say they are agile, even thogh they aren't.
I don't care to compare XP vs. Scrum vs. Kanban vs. Lean. That's just an array of banners for MacLeod Clueless, a way for them to form initiatives and conflicts that don't really matter.
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.
Agile is the Waterfall-aholics meeting of software engineers. I personally could give a shit about chanting mantras that say this -over- that and I think anyone who spews them in a blog post or otherwise is a nutjob. I dont "believe" in any of this crap. I have work to do.
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.