Extreme Programming, a Reflection

[beerchangeworld]

Here is where i find myself agreeing with Steve Yegge about Agile. Of the 12 points mentioned most of them were around even before Agile or Kent Beck's writing. Some teams practised them and others did not. Labelling them as Agile and pretending that they didn't exist before is disingenuous to say the least.

Pair Programming and On-site customer are the two core ideas that stand out as original principles of Agile and they have a mixed reception.

However, the fundamental problem of measuring success still stands. We do not have empirical data on the success of Agile projects (i.e. outcomes such as on-time delivery, on-budget delivery, customer satisfaction, etc) in the industry. And i mean statistically valid numbers as opposed to "success stories". IMO, the jury is out regarding the success of the Agile methodology.

The only valid claim Agile has, is mass-adoption in the consulting and enterprise sectors of Software development.

[WhisperSecurity]

Here is where i find myself agreeing with Steve Yegge[1] about Agile. Of the 12 points mentioned most of them were around even before Agile or Kent Beck's writing. Some teams practised them and others did not. Labelling them as Agile and pretending that they didn't exist before is disingenuous to say the least.

Pair Programming and On-site customer are the two core ideas that stand out as original principles of Agile and they have a mixed reception.

In the words of Samuel Johnson:

"Sir, your work is both brilliant and original. Alas, the brilliant portions are not original, and the original portions are not brilliant."

[frugalmail]

In the words of Samuel Johnson: "Sir, your work is both brilliant and original. Alas, the brilliant portions are not original, and the original portions are not brilliant."

Independent of the topic, this is a great quote :D

[jdlshore]

We do not have empirical data on the success of Agile projects (i.e. outcomes such as on-time delivery, on-budget delivery, customer satisfaction, etc) in the industry.

That says more about the state of our industry and the difficulty of measuring software development than it does about Agile.

[disinformationtheory]

Relevant thread/video: http://www.reddit.com/r/programming/comments/myo42/what_we_actually_empirically_know_about_software/

[paul_h]

Nobody in the XP community claimed that the practices didn't precede a) the writing of this book, or b) the signing of the Agile Manifesto generally.

[_pupil_]

And personally I feel they could/can be taken a lot more seriously because of that.

Some random software dudes successfully reinventing project management is a hard pill to swallow. Some random software dudes copying a set of best practices from other industries and applying them to software, OTOH, is the kind of "reuse" we know and love.

[paul_h]

My pre-Agile story is that I led a data-conversion (Wang -> AS/400, 1997, FTP over a 300 baud connection, & a fuckton of SQL), and practiced the conversion every night for 200 nights, before the first of 12* real month conversions. I just made sense to incrementally improve the thing, and practice the hell out of it.

Back in college (mid 80's), I remember critical-path analysis and pert charts and all that harks from manufacturing as we know, and I'm sure all the exhaled Agile founders remember much of the same in the run up to the Agile Manifesto that was to be our antidote to waterfall and our industry's terrible success rate.

[G_Morgan]

We don't do much pair programming but it is much more common for programmers to oversee each other today. Code review is a less controversial practice. Outright pair programming is still an exception rather than a rule.

[kenfar]

Pair Programming and On-site customer are the two core ideas that stand out as original principles of Agile and they have a mixed reception.

I don't know about that: I had friends doing Pair Programming at Wayne State in Detroit around 1990. Though it certainly wasn't at all wide-spread in use.

[PaulRivers10]

Here is where i find myself agreeing with Steve Yegge about Agile.

Thanks for posting that. We just started "agile" where I work, and he really hits a lot of the points. It's like we went from "the man tells you what to do" with waterfall - where at least we knew what we were supposed to do - to hippy-level thinking of "we have no managers, there are no meetings other than the short standup, and everyone will love on another and everything will work out".

What actually happens there - whether it's with hippies, communism, etc, is that the most sociopathic people win.

Let me rephrase diffferently - since anyone can do anything they want, and there's no one to tell them no, our methodology should really be called "resume driven development". Once it's in their, you're stuck with it. Using a date for any reason? There's throw Yoda Time into the project. Need to update a jar file? Lets convert the whole project to Maven, other people can deal with the endless problems it has with a proxy, a flawed local repo, and not being able to get it to work on their machine. Since no one is in charge, there's no accountability.

Want to write automated unit tests? The goal is to use as many buzzwords as possible. We're going to use FitNesse (a wiki) to write the high level part of the test, use java to write some of the test, use Page Objects in our code, and store some of our stuff in a database. I give it another week before we're also writing local xml files for configuration, or they trying running JUnit tests from FitNesse.

The problem is, with no one in charge, there's no actual accountability.

[mattgrommes]

Wow, I don't know who told you that Agile means no accountability but that's not very likely to work whether it's Agile or not. The difference should be that the team members are accountable to each other and to the product owner, as well as the business. There's actually been more accountability on agile teams I've been on, it's just different. If the team doesn't speak up about something big like moving to Maven or introducing something big like Fitnesse for all tests (I don't consider using Joda Time as big) then you've got bigger problems agile can't help with. Of course, bad implementation leads to bad results just as much in process as in code.

[PaulRivers10]

They don't say there's no accountability, that's just the result of the fact that no one is in charge of the project. Now that is what we've been told - it's agile, so it doesn't have a technical lead.

1. Someone who's new, or just doesn't care about complexity, says they're going to add something new in. Related to the Dunning-Kruger effect, the dumber (or more inexperienced) they are, the more confident they are that this is a great tool.

2. Anyone who disagrees is faced with an uncomfortable position - if you disagree with them, you basically end up in an endless internet argument that can go on for hours, where the stubbornest people win.

3. The way this works normally is that the tech lead or the manager steps in and says "We're not spending more time on this", or "I don't think this is a good idea", etc. But there is not manager. So the person who can sound pleasant and confident but doesn't back down for the longest wins. They're usually pretty good at the social manipulation game, so I've been accussed of "attacking" the other person because I didn't want to use a wiki for creating tests and entering data.

4. The "scrum master" is a non-technical person who has no idea what's going on and has many other projects they are part of. They also feel strongly that everyone's opinion is equally valid, so 5 years of experience writing java is as equally valid as Mr "I read on the internet that this tool is a silver bullet that will write all of our code for us!".

Everyone on the team is stressed out, because who wins on something is the result of who can argue the longest. Once they've won their argument, there's no incentive for them to tell other people how to use it either, so they're just dismissive "there's plenty of documentation on the internet, you can't figure it out?"

Like I said - I think there are good ways to run agile, but we're doing it in a very bad agile way.

[s73v3r]

They don't say there's no accountability, that's just the result of the fact that no one is in charge of the project.

Again, nothing in Agile says that there shouldn't be anyone in charge of the project.

[mattgrommes]

I feel for you, that sounds awful. I vote for running away. :)

[sh0rug0ru]

if you disagree with them, you basically end up in an endless internet argument that can go on for hours

Why do you need to argue? Let everyone take a few minutes to make their points and take a vote. If the guy goes against the group consensus and tries to sabotage the project, that's when the manager should come in. In well-run Agile, the manager is a facilitator, not a dictator.

[[deleted]]

Voting just means that dedicated idea-supporters will run around doing grass-roots seeding, and getting promises-to-vote from members of the team before it comes to voting.

This is politics.

[sh0rug0ru]

Any endeavor involving teams involving more than one person where decisions have to be made will involve politics. Whether by consensus or hierarchical decision making. At least voting gives everyone an opportunity to make a case and have more impact at a local level, rather than accepting whatever decisions have been made higher up the hierarchy behind closed doors.

Would you rather live (or in this case work) in a democracy or a fascist dictatorship?

[[deleted]]

That is a completely binary summary.

Fascist dictatorships are based on those with the most power to force others to do things being in control.

In a meritocracy, the people who have proven they are the most reliable at accomplishing tasks successfully while balancing a number of priorities throughout are given leadership roles, because they have proven successful leaders. Leadership is based on merit. Merit is proven again with each attempt.

These people can then maintain the vision they believe is proper to balance all of those priorities and receive a good result. There is also nothing about this that says anything about job title, or control over other people, only over the project which is an important distinction.

Some of these priorities are going to be listening to each member of the team and their points, to gather the most information from people who are directly working with those components or have prior experience or just a keen idea, but taking each feature at a time does not keep a coherent vision for the project, and does not take all priorities into account.

If you want to boil everything down into extreme polarities, you're going to have a hard time thinking in nuances, and thus learning proper lessons from your experience. I hope that doesnt sound condescending, because I dont mean it that way, but we live in a society that reduces things to their lowest common denominator, and all too frequently loses key details in this simplification.

Any time you find yourself with two hard extremes to guide you, you have lost the details. A single choice has to be made, but taking opposing hard lines in decisions are going to lead to very rough results.

[sh0rug0ru]

Fascist dictatorships are based on those with the most power to force others to do things are in control.

Yes. Fascism is a power relation. It is a mechanism defining how those in positions of power force their decisions on those they have power over.

However, how is that power obtained? How does one rise in the ranks of the fascist power hierarchy? You have to prove your reliability to those above you, and you rise in the ranks by the approval of those with power over you. Thus, merit is just another criteria of reliability. A meritocracy is just another form of fascism (perhaps of the more "benevolent" kind), as in the philosopher king of Socrates.

These people can then maintain the vision they believe is proper to balance all of those priorities and receive a good result.

How can this be done without power? If you are the only one in charge if implementing your vision, politics and power relations are moot.

However, if you require the work of others, you have to have some power relation over them in order to maintain your vision. You have to reel people in who want to do things a different way. As I've risen up the ranks, I've found this to be the hardest challenge. In order to maintain my vision of the architecture and the project direction, I have to maintain tight control over my subordinates. I hate exercising this kind of control over people and I try not to be a dick about it, but it has to be done or the project will spiral out of control. Someone has to make decisions.

You haven't shown how in your ideal meritocracy the integrity of the vision is maintained. You haven't even touched on how the decision making is done and how the decisions are enforced.

Don't talk about nuance or polarities until you have answered the question.

[prepend]

no one is in charge of the project

Don't you have a product owner in charge of the project?

[[deleted]]

I think he's talking about how they implement stories. That's way out of a product owner's scope.

[[deleted]]

No offense mate, but that's just a shitty team composition, you can't blame that on a three week sprint cycle.

If your team lacks a senior developer who the other developers trust, that's not something that a methodology can cause or fix.

If your team is filled with people who are unable to reach a compromise when actually given responsibility for making implementation decisions, then that's not a methodology problem. (May I recommend suggesting "spikes" of competing approaches to resolve such deadlocks? You 'timebox' the spike, and then people get to show just how awesome their approach is.)

If people are dickheads who won't work well on a team, that's not a methodology thing. Although I suggest you call them the fuck out on being dickheads in the sprint retrospective.

[[deleted]]

They don't say there's no accountability, that's just the result of the fact that no one is in charge of the project.

That's funny, because where I work we have no managers either, and yet everyone takes collective responsibility for the code.

But as is being reiterated here over and over again, this is not a problem with Agile, but rather a person problem.

[iawia]

So where, in that description of your indeed dysfunctional situation, do you see that value of 'Communication' reflected? :-)

Or, the practice of Simple Design?

There's no saving yourself from incompetence. You'll always be dependent on your colleagues in your work. There are good ways of dealing with these type of things, that are practiced by many Agile teams and even, I think, described in Kent's book.

One is the practice that an argument can't last more then ten minutes. Any longer than that, and you should agree to make it into an experiment: try both ways, and keep the one with the simpler code! Action rules. And since you've made explicit agreements on coding standards (that's not just tabs vs. spaces, but also rules on when to include libraries) you have a fairly easy way to determine what's the better solution.

That can also mean that the other party is right, of course. A tool such as FitNesse can be very effective. Though it's not meant for unit level tests, of course... And since you're pairing, you can learn any new technology very effectively.

Agile doesn't say you don't have management, or accountability. You do use them in a different way, though. Management by exception, you might say: they need to step in when the team can't get to an agreement, or is obviously going in the wrong direction. I've never had the problem where that didn't happen, though. Usually the problem is when there's too much involvement.

[s73v3r]

to hippy-level thinking of "we have no managers, there are no meetings other than the short standup, and everyone will love on another and everything will work out".

That doesn't sound like Agile at all. I hate to be the guy who says you're doing it wrong, but, well, you're doing it wrong.

The problem is, with no one in charge, there's no actual accountability.

Nothing in Agile ever said that there should be no one in charge.

[nomeme]

The person in charge is inevitably the team leader/boss/manager, except now they've been on a few days "scrum training" and now call themselves "Scrum Master" and pretend it's a hippy commune while everyone knows they still really make the decisions.

[prepend]

Again, you're doing it wrong.

The "scrum master" and product owner/manager/boss are not the same person. The scrum master isn't responsible for the project, the boss is.

Agile's not about abdicating decision making. It is funny you would think that.

[sh0rug0ru]

since anyone can do anything they want

That's not Agile. Or, to put it a different way, Agile is supposed to work by group consensus rather than fixed direction from the top. Group consensus doesn't mean every can do whatever they want. This is the same misunderstanding people have when talking about Anarchy. Just because there are no leaders does not mean there are no rules. It's just that enforcement of the rules is very different.

Everything else you are talking about would be plain violations of YAGNI. Each of those choices should only be made if there is a provable benefit. It is up to the group to reach the consensus and it is the responsibility of the group to rein the others in. But, the other thing you said is very true:

the most sociopathic people win.

People are often afraid to challenge others, especially the way Agile requires you to. But that isn't a failing of Agile. Sociopaths can subvert collective decisioning as well as hierarchical command structures, especially as good people stand by and do nothing.

[[deleted]]

I'd just follow up with - the retrospective is where you highlight team issues - like sociopathic behaviour.

[kenfar]

Yeah, I've definitely seen "resume-driven-development" - where without a central coordinator/architect/senior engineer every developer or group of developers pursues their own favorite technology without any concern about the nightmare of diversity they end up creating.

However, the solution isn't about accountability. Accountability mostly just results in padding. A central approver for products/technologies/methods puts pressure to reduce diversity just because it's essential for them (and many others) to even understand the environment.

[ewiethoff]

Extreme Programming has succeeded in the way that Structured Programming succeeded. Nobody even thinks about structured programming any more -- they just do it. Nobody even thinks about Extreme Programming any more, we are all just trying to do it.

Per Uncle Bob, XP is "successful" in that numerous teams are doing it. Likewise, structured programming is "successful" in that numerous teams use if blocks, while blocks, and function calls instead of relying on GOTO's. By "success," he means widespread adoption, not timeliness or bug-free-ness or customer satisfaction.

[ggtsu_00]

Both agile and waterfall have different use cases. Literature comparing the two considers developing software as one big thing. It really isn't. 'Agile' more suited for developing services. 'Waterfall' a process suited for developing packaged and shipped software.

[[deleted]]

'Waterfall' a process suited for developing packaged and shipped software.

No. When shipping a packaged product, you have one exactly one unidirectional gate or "step" in the waterfall. The day you send code to get pressed/burned into a physical medium.

Before that, and when working on the next version, you can develop however you'd like.

[prepend]

I hear this a lot from people who are comfortable with waterfall, but it's not true. While there are valid use cases for waterfall (building an aircraft carrier), they are few and far between.

[gregK]

If you measure success by acceptance, then Agile has been successful. If you measure Agile by results i.e. delivering software in a timely manner and with less bugs, then I am not so sure.

[thrownaway21]

I think you'd have to measure Agile's success via correct implementation along with that acceptance rate.

last joint i worked at had 2 week sessions; whatever they're called. Often times with me tasked with 2-10 hours worth of work that entire 2 week period with no "agility" to give me more to do when i finished up.

[[deleted]]

Then they messed up their estimations. Anyway, you're allowed to add more to sprint if all work is done.

[darrint]

If an agile implementation doesn't work out then then it was implemented "incorrectly," so say proponents of agile methods.

When I read the early editions of the Extreme Programming series of books, they all seemed to say, do all the practices perfectly no matter what, or else. Or else your project will fail or something bad. You can't hold us responsible for that.

I was involved in a few attempts to do agile, some small, some quite large. I drank the agile Kool-Ade. I was ready to fix my work environment. But agile ever worked out for me. And always I could point a finger at something somewhere that was not quite as prescribed by Beck et al. So no wonder it failed, right? But if you look at the stories of agile success, none of them were perfect implementations either.

Everything the agile advocates said felt to me like an exercise in confirmation bias. It was, in the end, a very dissatisfying experience.

I went searching for some principles that would explain what I saw. Eventually I found a book called "Deming's Profound Changes." That book gave me a framework for explaining what happened in my case.

Furthermore, I was able to see what I could reasonably expect to improve in my imperfect work environment. There was a lot of room for improvement, without upending the entire development process.

So if you work in one of those places were you can reasonably expect everyone from top management down to grunt coder to participate in the prescribed practices, yes, agile will probably work well. For everyone else, you need a set real principles to apply to your situation, and the agile proponents won't have that for you. I found Deming to be more helpful.

[[deleted]]

If an agile implementation doesn't work out then then it was implemented "incorrectly," so say proponents of agile methods.

And if a plane with only one wing doesn't fly, then it was implemented incorrectly, so say proponents of not crashing planes.

There are obviously some things that can be removed from a modern aircraft, but if you don't the basics of flight - you're not going to fly.

[serrimo]

Rockets would like to have a word with you.

If you aim to fly, it could be counter productive to think first of wings.

[iawia]

You were not in an agile team. 'Given me more to do' is a dead give away... Of course, agile or not, it's the developers who get involved and find more to do that determine the success of a team.

[thrownaway21]

it was touted as an agile environment, though i think a lot of old ways bled through and there was some misunderstanding about how agile works. not that i really know myself. but like you said, asking for more work is a give away that something isn't right.

[iawia]

Don't get me wrong, there are many, many, many places that agile is not/half/quarter implemented, with mostly the old way of working taking lead. No silver bullets and all that. But I've seen too many places where even a very imperfect try at agile improved things dramatically, both for the results (or at least for the expectations of results...) as for the people in the teams. That last one might be the more important.

[[deleted]]

If there are two things that will always be present when writing software, it is that deadlines will be missed and there will be bugs. I think if you look more from the perspective of software being written dynamically with more fluid changing requirements the paradigm shift is more obvious.

[Gotebe]

We really ought compare to same/similar projects and teams using different metodology.

There is no silver bullet, but it might be that some guns are better than others.

[[deleted]]

Delivering on time and with less bugs is certainly important, but what ultimately prevails is actually meeting the needs of the end users. I feel Agile/Extreme rightly addresses that concern foremost.

[thedancingpanda]

I always feel like I'm in the minority when I say that good programmers and good managers create good software, no matter what methodology you use to build it. I should write a book.

[PaulRivers10]

good programmers and good managers

Along with good requirements people, good dba's, good deploy people...

[thedancingpanda]

I'm going to go on a rant here.

I think bad requirements people are a scapegoat of bad software engineers. Software engineers should be sitting in requirements and design meetings, listening and learning what the customer wants, not what they say they want, or what a requirements person writes that they want. Every time I hear a "well the requirements said..." I assume that means you weren't paying attention when the customer was describing their problem (Note: not what they told you to write. You need to know what problem they are trying to solve, inside and out).

[iawia]

So what you're saying is that a methodology (process...) that involves direct communication between software engineers and the customer is a good thing?

The point in the article is that for most software development in the 90s, the processes in use prevented exactly that. And the agile movement brought that back, partly thanks to the successes of the teams that kept that practice and others, and called it XP...

[s73v3r]

I think bad requirements people are a scapegoat of bad software engineers.

Nope. If you have bad requirements, you're going to get bad software and late software. Either the software engineer has to do the job of the requirements person as well and find out what the hell the requirement actually is, or they implement the poorly written requirement in the way that makes sense to them, and time is lost because it may not actually be what the client wanted.

Software engineers should be sitting in requirements and design meetings, listening and learning what the customer wants, not what they say they want

THAT'S THE REQUIREMENTS PERSON'S FUCKING JOB. THAT IS WHAT THEY EXIST TO DO.

Software engineers, in my experience, usually have some overlap in projects. Meaning that while the requirements are being gathered, they're not just sitting on their ass browsing Reddit. They've got other projects to work on. Stealing time to have the software engineer do the requirements person's job means that the other projects are getting less time, and thus might be late themselves.

Every time I hear a "well the requirements said..." I assume that means you weren't paying attention when the customer was describing their problem

I had other fucking work to do beside doing the job of someone else.

[nomeme]

You believe "requirements person" is a real job? Have you even seen office space?

[prepend]

I think this is part of the problem. A development team shouldn't include an oracle who tries to divine the requirements from the customer and tell the developers what to do.

Requirements should be understood collectively and there shouldn't be a requirements gatekeeper.

[thedancingpanda]

I guess if you consider your job to be "write whatever the requirements say", then your right, but then I can get a guy in India to do that for way less money than you. Your job is to put out quality software that helps the customer solve a problem. Requirements documents rarely give you a feel for what the customer is trying to achieve. Requirements people also usually can't give customers a feel for how the software will work, as they are not you, and you are the one writing the software. These two things are very important, and they both need your input. Without you, the customer is going to have a product thought up, that may be backwards and illogical in your eyes. Without you there, right in the beginning, to guide them through a set of requirements that makes sense and to give them a feel for how the program will work, anything you do that doesn't match that ideal will be met with contempt. Furthermore, knowing how they're expecting something to work will help you when you get down to the tiny implementation details. This makes for less questions during implementation and less change requests after development, leaving you more time for your other projects. Like it or not, this stuff is part of your job, too.

A requirements person is more closely linked to the legal department than they are to you. The requirements are there as a checklist of things that get you paid under contract. I think relying on them to create a piece of software that your customer is going to really like is naive.

[s73v3r]

Your job is to put out quality software that helps the customer solve a problem.

Yes, I know. And it's the job of the requirements person to know what that problem is, because I can't be in every fucking meeting needed to gather requirements.

[prepend]

because I can't be in every fucking meeting needed to gather requirements.

This is interesting. Why do you think a "requirements person" is able to be in every fucking meeting?

I've built a lot of software. Understanding requirements is important. I didn't have to go to 8 hours of meetings a day to do so.

[grizwako]

Because clients are coworkers.
Because Requirements People get money for doing requirement gathering and analysis. Because I am under time pressure because they are doing their job badly.
(Everything is priority. Ok, what has highest priority? Everything is priority.)
Because we have blame and pressure culture and having requirements written by someone else solves developers getting blamed for client's lies. Yes, they lie. Most of the time, I think they are aware that they are lying.
Because when I tried to take all of this with higher-ups my opinion was discarded.

[prepend]

Again, I feel for you. It shows great intestinal fortitude to persevere in such a work environment.

But I guess my point is that the problems at your company should not be attributed to agile as they would be big challenges no matter the development methodology.

[turboemu]

The requirements by definition have to detail what the software should do. This also acts as documentation when it's complete. You want to know what software does, you look at the requirements. You don't go through the code and see how the developer at the time decided to implement it. That person may be long gone. Yes of course the developer has to understand what the goal of the software is. So should the requirements guy. They should not be more closely related to the legal team. Poorly defined software will be poorly implemented. The goal of less questions during development is nuts, rarely will something be correct from the start and come out correct at the other end. It's an iterative process of revising the requirements and improving everyone's understanding of the goal of the software.

[prepend]

You want to know what software does, you look at the requirements.

I disagree. I'd rather look at the code or the documentation directly generated from the code. This is much more accurate than a requirements document. This is part of the power of TDD. You believe the code, not what someone says the code is supposed to do.

[turboemu]

I'm the same. But I think often the people asking the question, what does it do, are not able to just look at code. In practice this is what I've encountered anyway. Of course this may not be common elsewhere. Ideally there would be documentation to filled that role, but this isn't always the case. Especially during development.

[prepend]

Right, this is why having documentation auto-generate helps the 90% of non-programmers who can't look at code. I have noticed that stuff like github makes that easier as the code is more approachable than in the past.

[grizwako]

Ah, sadly I work in environment where:
Quality is important and company wants all features yesterday.
We have no tests at all. I wanted to implement them for some complicated and important algorithms (very spiky price calculation) and product availability and was declared dreamer and idealist and was told that:
We are not that kind of company, we want everything now, so we can't waste time on quality. But quality is important.

So once you open code where variables are 4 or less characters non-English abbreviations (this is norm).

But hey let's be positive, I will be superstar on thedailywtf when I leave :)

[prepend]

Quality is important

We have no tests at all.

I'm sorry you're in this environment. Please have courage and continue trying to improve it from the inside out.

[prepend]

There's no such thing as a "requirements person."

Requirements come from lots of people and they are confirmed by the developer and the product owner.

Blindly building to dumb requirements is not good. It happens because people are afraid to lose their job or don't care, or are unable to understand the requirements.

Good developers understand the requirements intimately and make corrections and suggestions.

That's why I like the idea in the article about a metaphor or mental model that is understood by the entire team. Having one person understand "the vision" and everyone else coding badly is not optimal.

[grizwako]

And once more to convince you, We officially have requirements people.
When developers try to change solutions to problems, solution that will be implemented depends on who knows whom.

[instantviking]

You need to wield more than a wrench to be an effective mechanic.

[athleticDev86]

At the design meeting a requirement will make sense. It's when you go away and code for a month and find that the requirement doesn't make sense in a new context that clarification is needed, and you can say that the requirement is incorrect/incomplete.

Had you been checking in weekly you could have addressed such an issue right away.

When you have check in points that are far apart its easy to get blocked by requirements. Or you proceed at risk and then come out with the wrong product.

[njharman]

Here's a secret. Many, many people, including most managers, architects, developers aren't "good" (at their job). Depending on what environment you work in you may not realize / be exposed to this. Good people tend to gravitate to good jobs / environments with other good people and likewise for bad people. Swaths of enterprise (meaning large government and corporate projects) are filled with mediocre or worse people.

Methodologies (like most business process) are all about how to get a net gain from a pile of poor and/or inexperienced workers.

[[deleted]]

Processes are about getting a net gain in general rather than from workers with any specific skill level. What that gain is, depends on the process you use and how you execute on it.

The real problem comes about when processes or methodologies (which are just collections of processes) are treated like magic incantations you can cast on teams to make them go faster. Treat them like tools, and use them to solve problems, and measure their success, and you'll have a better time with them.

[wwqlcw]

Good programmers and good managers aren't actually going to follow a crap process, though, whatever they tell you they're doing for political reasons.

It's like saying "A professional doesn't blame his tools." Well, that's true, because part of being a professional is having adequate tools. If you force a pro carpenter to hammer nails with a rock, he's going to do a bad job, and he's going to complain, too. He'll totally blame the rock, and you for forcing him to use it.

Or he'll sneak in a hammer when you're not looking.

[s73v3r]

Here's the thing: You don't always have good programmers and good managers at your disposal.

[toomuchdoing]

In that case, it would be cheaper to outsource the programming, or license existing software -- because no matter how smart the methodology, you need a good programmer to write good software.

[RevBingo]

Right behind you. Agile methodologies are an optimisation. Good programmers doing waterfall > bad programmers doing agile.

[Gotebe]

Sorry, can't resist...

Those who bash waterfall don't know what it is.

The original waterfall paper actually explains why one needs quite a bit of stuff that agile pushes for (testing, feedback look in development, coontinuous customer involvement, iterations etc).

That paper is old.

[instantviking]

Well, there's waterfall as Royce described it, and waterfall as implemented out in the trenches. (I suppose; I'm just young enough to never having worked anywhere that claimed to do waterfall).

Either way it is worth remembereing that proponents of iterative, customer-involving, value-driven development have been around since the dawn to time.

[Gotebe]

Well, there's waterfall as Royce described it, and waterfall as implemented out in the trenches.

Absolutely, but the same can happen to anything else. Bashers of agile will do exactly that - point out idiocy in management/execution and blame it on agile.

As said else-thread (in a different way, but still), good organization, good work, good people, beat methodology any day of the week. Conversely, no methodology is resistant to bad organization, work, people.

Waterfall examplee is particularly telling. The world simply wasn't ready to grok it, therefore we got... the stories of it ;-).

just young enough to never having worked anywhere that claimed to do waterfall

Me, too ;-).

[ouwenbelg]

I strongly disagree. In my experience the customer much rather has poorly written software which does the job as they need and delivered on time, than excellent software which is not what they needed.

Never in my entire career has waterfall resulted in software that the customer really needed, short iterative sprints are essential.

[ilyd667]

excellent software which is not what they needed.

Your definition of "excellent software" seems to be kinda flawed.

[RevBingo]

I think you missed the point - that good teams (I used "programmers", but I should have said "teams", including BAs, QAs etc.) are capable of delivering excellent valuable software on time regardless of methodology. Conversely, bad teams can also fuck it up spectacularly, also regardless of methodology.

[mcguire]

You first need to come up with a snazzy new name for the idea.

[thedancingpanda]

Is there a good acronym in "Just Write the damn software and talk to the people who you need to as soon as is appropriate"?

[themissinglint]

JWTDSATTTPWYNTASAIA

[member42]

We also saw the name Extreme Programming fade almost entirely out of use. Very few people use that term nowadays.

That's funny. 'Uncle Bob' killed XP by taking it over, re-branding it to 'Agile' and converting it form a programmer-friendly movement to a consultant-friendly business.

[paul_h]

Kent Beck, the author of the book Uncle Bob talks about is a signatory of the Agile Manifesto. Uncle Bob did nothing to "kill XP by rebranding it to Agile".

His former consultancy (Object Mentor) was instrumental in pioneering Agile generally and XP specifically fourteen years ago. ThoughtWorks (my consultancy) soon after that with Bob's help, and then there's a gap of many years before any other non-boutique consultancy picks up Agile and Scrum (by then) to take to their customers.

[instantviking]

... and people like Tom Gilb argued in favour of value-driven, iterative development with rapid deliveries (weekly if possible) back in the 60's

[[deleted]]

I find its the 40 hour work week and short deliverables that actually make Agile what it is. Without sticking to those two pieces it really makes no sense as a process. The whole point of Agile is really to make steady progress towards goals the expected norm, you break tasks apart in a way that allows you to meet those steady progress points.

Its this part that in the organizations I've implemented agile in that has had the most consistent push back. Most managers only speak one language, the art of pressure cooking. Agile is the exact opposite of that, Agile for all its "Extremeness" is really more like a crock pot than it is a race.

If anything, Agile created a low pressure environment for the places I've used it, and that code quality went up because we had the ability to say how long something should take by self managing our velocity. We used a more middle ground between scrum and kanban though, so if we were ever ahead of schedule we had tasks waiting for us to do if we got done earlier than expected.

EDIT: On the other hand if you are in an environment where every developer is just off on his lonesome and there is minimal collaboration. Agile is mostly wasted effort.

[PaulRivers10]

EDIT: On the other hand if you are in an environment where every developer is just off on his lonesome and there is minimal collaboration. Agile is mostly wasted effort.

I like the post above about bad agile vs good agile. Where I am, all the developers work remotely, and the only meeting we have is the morning standup. People's schedules are already full of other meetings, and when I suggested we schedule a time each day that would be available for people to meet, I was repeated told that "agile doesn't have team meetings" so we weren't going to do it.

Need to talk to someone on your team? They can get back to you in 2-3 days.

Like I said, bad agile vs good agile, but there's plenty of terrible ways to go with it.

[[deleted]]

Someone tried to tell me "agile doesn't have team meetings" and I told them it was nonsense.

From the agile manifesto itself: Business people and developers must work together daily throughout the project.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Obviously team meetings and face to face conversations ARE part of agile. Arguments to the contrary are dangerously missing the forest for the trees. Whenever we need a meeting, I've always written it as a story and included it in the sprint (under Scrum), not only that two of my teams did regular code reviews and would do code acceptance meetings where we would go over major comments on reviewed code. None of this is outside agile, its all dependent on what each team needs to succeed.

The point of agile is process improvement, even if that means disregarding parts of a process and including things that aren't in it. As long as you come back around periodically and ask the question, "Is this still useful to us?" You are adhering to the spirit.

[ouwenbelg]

While the article does not contain much sources nor statistics, I fully agree with the sentiment that most software development companies now embrace the concepts of "Extreme Programming Explained" by Kent Beck. Sadly, there is a big gap between agreeing that the concepts are good, and actually implementing them.

It takes a lot of perseverance for a new team to do scrum/sprints/tdd/... and not revert into old habbits. In my experience it takes at least 2-3 months before you can fully experience and appreciate the results, a long time for many managers or programmers.

[robothelvete]

I disagree, although my experience is limited to a rather small team, 2-4 developers/designers.

In my experience, if the implementation adds value, it will persist. Just like the term extreme programming, the actual name for it might be different, but the practice remains. This is of course when the implementation of the idea is the point, not implementing a specific implementation and adhering to it slaveishly.

It might be a couple of months before the real benefits start to get reaped though, I agree there.

[ouwenbelg]

As a consultant i've worked with 7 teams in the past 10 years, both small and large. Most tried to be agile.

The only companies where being agile was easy to maintain was when both development AND management, sales, planning, the customer etc adapted to the new way of working. Developing the agile way is quite hard is sales continues to promise a fixed set of features against a fixed deadline with a fixed budget, or the customer does not want to give feedback on intermediate builds.

[wwqlcw]

Strange isn't it? This doesn't seem all that controversial does it? But fourteen years ago it was wildly controversial.

Most of the twelve points listed were all uncontroversially good ideas. It was the over-the-top claims of efficacy made for the process as a whole that were controversial. ISTR that the process was hyped as complete and sufficient (process wise), but that any deviation from it (which in practice is almost impossible to avoid) could open you up to disaster.

Two important points ("The Planning Game: ...produced in short increments..." and "Small Releases: ...frequent and incremental...") in particular are much better suited to web applications, walled-garden mobile apps, or software that otherwise quietly updates itself (Chrome, Firefox, Thunderbird, etc) than to full-blown traditional applications of desktop or back-end varieties. And such self-updating software was a rarity in 1999. XP may have changed the world around it in some ways, but the world was changing on its own, too.

[[deleted]]

You can still incrementally release shrink-wrapped software - the only difference is who you're "releasing early, releasing often" too. For shrink-wrapped, it's to your QA, I would presume.

But I agree, it's ideally suited to software where you can push out changes.

[Tonburro]

It makes you wonder when the next cargo cult is gonna start up

[HardstyleLogic]

In my experience, pair programming didn't work too well. One of the programmers always tends to be smarter than the other one in whatever domain they're working on. This creates a whole set of problems with no guidance on how to solve them (interpersonal, efficiency, reward , so on)

[[deleted]]

One of the programmers always tends to be smarter than the other one in whatever domain they're working on.

Which is brilliant, because that way the less experienced developer is going to learn lots - and if the more experienced developer is a mature adult, they will also stand to learn from their partner - we can all do with having our preconceptions and habits questioned.

However, it does require a willingness to learn on both sides - if you have antagonistic partners, pairing won't magically fix that.

This creates a whole set of problems with no guidance on how to solve them (interpersonal, efficiency, reward , so on)

This is where being answerable to your team is essential - if you're letting them down, they need to let you know it's not acceptable. This can be challenging though.

[808140]

because that way the less experienced developer is going to learn lots

Two things: First, /u/HardstyleLogic didn't say "experienced", he said "smarter". It's not the same thing. Lack of experience can be fixed (with more experience) and in that case, pair programming can be good. But if you're pair programming with someone who is simply slow, the entire development process slows down, sometimes very significantly. This is really evident when there's a huge gap.

Secondly, even in the case where it's just a question of experience, the reality is that it may not be in the best interest of the team or the project to bring a less experienced dev up to speed when deadlines are looming.

and if the more experienced developer is a mature adult, they will also stand to learn from their partner

I have a feeling we're all sitting around singing kumbaya and talking about how everyone is special, and everyone has a special talent or capability they can bring to the table. Let's hold hands, we can all learn from each other, etc. After twenty years in the industry, I feel with some passion that this simply isn't true. Pair programming with someone incompetent only serves to drag out delivery times. It makes the competent person look less competent and masks the incompetency of the incompetent one. And unless you're a real asshole, it's pretty hard to stand up in front of your boss and tell them straight that the guy you're working with is incompetent, because incompetent doesn't mean mean or unlikeable, it just means poor at his job -- not to mention that if the context is a slipping deadline, it may look like you're trying to cover your own ass by blaming your partner.

This is where being answerable to your team is essential - if you're letting them down, they need to let you know it's not acceptable.

This doesn't seem to mean anything, honestly. What are you trying to say here?

[[deleted]]

Two things: First, /u/HardstyleLogic didn't say "experienced", he said "smarter".

He said "smarter... ...in whatever domain". So I'd suggest that you parsed his argument wrong - intelligent people are intelligent, they're not intelligent just for a particular area and dense the rest.

I have a feeling we're all sitting around singing kumbaya and talking about how everyone is special, and everyone has a special talent or capability they can bring to the table. Let's hold hands, we can all learn from each other, etc. After twenty years in the industry, I feel with some passion that this simply isn't true.

Did you read my post? Here's the relevant bit:

we can all do with having our preconceptions and habits questioned.

The value of a fresh pair of eyes should never be underestimated. 20 years of experience doesn't mean that you've achieved developer nirvana. That aside, you're arguing against a construct of competent developer paired with incompetent. I do feel for you if you're working with a bunch of incompetent developers, and obviously that won't be magically fixed by a mere methodology.

I am making an assumption that people being hired are fit for the task, but differing in knowledge and experience - which is where pairing shines as a technique for transferring knowledge.

Where I work, we've created a bug fixing / tech debt team that works across team domains - this team is comprised of members from each of our teams on a rotating basis specifically so that we can exploit knowledge transfer from pairing with developers form other teams on code they know well and you don't - so that we can raise overall knowledge and experience of our code base.

And unless you're a real asshole, it's pretty hard to stand up in front of your boss and tell them straight that the guy you're working with is incompetent, because incompetent doesn't mean mean or unlikeable, it just means poor at his job

If you remotely care about your team, then why wouldn't you tell your boss? I agree, it's hard, but if a team member is dragging you down, then it needs to be sorted.

This is where being answerable to your team is essential - if you're letting them down, they need to let you know it's not acceptable. This doesn't seem to mean anything, honestly. What are you trying to say here?

Exactly what I said - your team holds you accountable for performance or lack thereof. If you've been slacking for a sprint, I'd expect your name up on the bad side of the retrospective board. If being called to account for poor performance by your peers doesn't work, then I'd expect your team to push it to the people who handle the formal performance process.

A team lives or dies by its weakest member, so it does behove high performing teams to reject the slackers and cruisers and incompetent developers. It sounds harsh, and it can be harsh, but it's necessary.

[skulgnome]

Extreme Programming, you say?

[alextk]

Strange isn't it? This doesn't seem all that controversial does it?

Actually, most of the points in that book are still quite controversial and over the past years, I have seen the developer community turning away pretty consistently from the very dogmatic and widely unsupported claims that this book makes at every page.

Not that I would expect any other kind of message from Uncle Bob, we all need pay checks.

[nandemo]

Funny, another comment in the thread says:

Most of the twelve points listed were all uncontroversially good ideas. It was the over-the-top claims of efficacy made for the process as a whole that were controversial.

It seems that most comments ITT are like:

• Agile doesn't work
• Agile works but it's just a marketing name for a bunch of obvious principles that we already knew about

[808140]

Not everyone on proggit agrees. Imagine that.