Agile requires a bit of fudging around the edges, but it already admits that that is required (people > processes).
Yeah, YAGNI and its ilk may apply, but sometimes you -do know you're going to need it-. That story is in the pipeline, your users are demanding it; to design and code only to the current story, dismissing the design considerations that that future story would impose upon the current one, is shortsighted and self-defeating. You shouldn't be delivering -features- from that story yet, but by all means recognize that "Oh, we'll need a hook for that, and it would make sense for me to implement this with an event manager so we can add subscribers, and keep these decoupled, rather than just make a direct method invocation", etc, so you can easily tackle that future story when it comes up.
Oh, hey, the build and deploy process sucks, and that has no direct user value, and thus no story. Well, deal with it anyway; you -know- that is costing you time, and being able to rapidly iterate = faster development time = less cost = desirable to the user.
Etc.
Really, agile always seemed to me to be two different things. One was a series of processes. The other was a series of values (among which was people > processes). And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around.
EDIT: I've also seen teams that take the values as excuses to ignore the processes, which also fails hard. "People over processes? Okay, no process then, everyone just code! Get shit done!" The point is to take on the processes, modify them in accordance with the values as experience leads you. Something doesn't work for your team? Change it. As someone mentioned elsewhere on this thread, that's what retrospectives are for.
And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around.
The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
Like many other products, if the person buying doesn't actually understand the difference, the bad stuff will tend to drive out the good. This is not a problem of Agile, it's a problem of the people who choose to hire consultants and adopt methodologies.
It might be a problem for Agile -- it damages the brand -- but that'll be a problem for any set of principles in the same space. You're always going to need to keep your eyes open, do your research, and carefully employ both reason and lessons from experience.
> The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
If you are substituting reliance on marketers and consultants selling canned processes telling you what to do instead of your engineers developing their own knowledge of what Agile is and applying it, then, yes, you will get some canned thing sold by marketers and consultants that has an "Agile" label stuck on it but which is the exact opposite of what Agile is -- since any canned, externally-defined, process sold across the industry by marketers and consultants is not only "not Agile", but exactly the problem that Agile was defined to solve.
OTOH, that's not a problem with Agile, that's a problem with outsourcing the basic function of engineering your own internal processes without developing internal understanding.
In an environment where employees stay with a single company long enough, consultants may be a valuable way of moving information between companies. I'm skeptical that much software development work sufficiently resembles that, though.
I'd not go so broad as that, though I tend to agree.
Bringing in outside consultation can help when the team is fractured, or when there's a disconnect between the team's needs and what management is willing to allow (that is, an outsider saying to management "Look, you've already agreed to be agile; that means you have to give the team autonomy to try this" can be more effective than the team saying "We want to try this"). But yes, there's a lot of snake oil salesmen, "Agile is good for what ails ya!"
Agile has no process, your complaint is with Scrum and I mostly agree. The amount of rigidity in scrum has gotten out of hand. The concept of stories on a backlog and the very iterative approach is the crux of the process and I think it's great. You will always need non-user stories to get set up. Developer stories are fine by me. I also think sprint schedules are artificial and prefer a looser more KanBan approach. My biggest challenge that no one seems to have adequately addressed is working in a multi-discipline team. My scrum team includes UX, visual design, content, and we are all interdependent. It's really, really hard to get them on to scrum because their work has no clear point of completion. You just have to keep it loose which is really the core principle of scrum. It's designed to react to change more than making long-term plans.
I think that one problem has been with some people promoting TDD by saying to write "the simplest thing possible to get the unit test to pass".
I've seen "Uncle Bob" do his bowling game demo, without using the expected classes for Game, Frame, etc. It's an interesting exercise, but would be a horrible way to write any large-scale business application. However, some people walk away from that with the idea that they should write quick "hacky" code, instead of doing any thinking about design.
When I write a program, I use my [constantly-evolving] set of "best practices", based on what I've experienced when writing other applications. Writing a factory method for object instantiation is not "the simplest thing possible", but I've seen it come in very handy at times, so that's what I'm doing in my projects now.
After all, aren't retrospectives, and modifying your process based on what you've learned during your project, one of the huge points of Agile - even though I've rarely seen them done, let alone done well.
As someone who has been programming for a living for a couple of decades now I have seen more than one methodology come along and propose to solve all the "problems" with my craft. Like any young discipline we still have a lot of things to work out, however I find that as I get older I have less tolerance for the view that "the problem" lies in the way programmers do things. I think rather that "the problem" lies in the way customers treat the process of creating software. They approach it with a casualness and an indecisiveness which would not work in any other context where something expensive and custom was being built from scratch. I can honestly say that in over twenty years I have not been acquainted with a project that failed because the people who were responsible for writing the code couldn't get it done, or couldn't get it done fast enough. On the other hand I've seen lots of projects fail due to inadequate executive commitment, off-the-cuff estimates, evolving feature sets, etc.
I agree with this but I think at least part of the problem is that we don't have good tools for specifying precisely what it is we intend to build. If we could create software plans as detailed and exacting as blueprints for a new building we'd have far fewer failures. Instead we toss together a few wireframes and start hacking and by the time we're done the final product is nothing like what we were originally tasked to build.
As far as I can tell this just isn't the case in any other field of "engineering".
Perhaps, but how useful are those detailed plans and blueprints to the actual consumer of the construction service? They get studied, sure, but I think the customer is still working at the level of features and their expression in the plan, not the plans themselves which are more of an internal tool for the architect and builders. It's true that we lack widely accepted formalized design tools like blueprints, but at the same time it's interesting to note that one of the recognized problems with extensive planning and design documentation in software is that it can't keep up with evolving requirements :). So again, we can't plan because the customer has been taught to think everything is open for discussion at all times.
I agree that client requirement sculpting is a major issue. But I think if we could give them something like the kind of detailed 3d walkthrough that's possible now in architecture, for example, we could possibly also get them to agree that no significant changes will be made once they've signed off on the plan. I have no idea how this could actually be done though. So many of the implementation details are opaque to any non-technical client.
User stories work when the user interacts with every part of the system. But for backends or libraries or engines, there is no user but other developers. We're not trying to delight developers probably, but to enable them. That different impulse drives different coding behaviours/ project plans than 'put up another screen for the web user'.
I disagree that technical debt == bad code. That's just a cop out. Code can be golden and still not cover all the cases or perform as well as a better-but-larger-effort solution. So we cut corners, write golden but small-scale code and move on. Its a startup after all. Then later when the fires are out and we have time to breath, we'd like to spend 12 hours and put in more golden code, that takes longer to develop but performs better or covers more cases.
> In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse, component-based software development.
Many of us are doing just this while practicing Agile. It's not an either or situation. Are people really this out of touch with contemporary software development practices?
Worked with a good bunch of developers that didn't even know SOLID existed (but what do you expect when developers now a days have a 30 day bootcamp or read a Rails book and are able to get developer jobs?)
Fair points, for the most part I think. To write good software, you need good people who know what they're doing. Whatever process you follow without that you're always in trouble (requirements, design, coding, testing, etc. all those need good people). What I really hate about the Agile consultants, etc. is that many say switch to Agile and the world becomes a better place. Not with bad people it doesn't.
However, I think a lot of the Agile stuff can really help get the best out of the good people. For the bad people I have seen it work the opposite way - they lose the safety net of structured requirements analysis, design, etc. and end up creating a mess.
Best part for me was the link to the anti agile manifesto:
One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. Developers become responsible for their own individual tasks but don't take responsibility for the project as a whole or how that task might fit into it. For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results.
> One if the issues I see with Agile in practice is that it draws clear lines around individual tasks.
There are no doubt methodologies that do that, and some of them are probably sold as being "agile", but there is nothing particularly agile about doing that and most writing son Agile (and its close relative, Lean) actually recommend doing the exact opposite and eliminating most role distinctions within development teams and finding ways to establish broader collective ownership of the product as a whole (different authors differ in the specific approaches they recommend trying in order to achieve this.)
> For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results.
That sounds like you didn't adopt Agile -- the orientation toward software development encompassed in the Agile Manifesto -- but some externally-defined canned process that some consultant slapped an "agile" sticker on to sell to people who don't know what Agile is.
If your existing pattern of interactions is working effectively, "adopting Agile" shouldn't mean much change besides something like periodic discussions of how it is working, and what any pain points are in it, and how to tweak it to resolve those pain points.
In fact, even if your current processes aren't working, that's what adopting Agile should look like at first -- any bigger changes should come out of what the team discovers in those discussions (which may then lead to adopting, on a trial basis, particular practices that have been defined externally that appear to be designed to address the issues that the team is having to evaluate if they work for the team, but adopting a set of canned externally-defined processes without reference to the specific needs of the team isn't adopting Agile -- its something opposed to Agile that puts process over people and interactions.)
You need better developers and managers then. What you're describing is a personality trait, not a side-effect of adopting AGILE practices.
The developers have to care about the project as a whole and the managers need to communicate upwards, downwards, and horizontally: that's how a team maintains a high-level view while implementing in the weeds.
I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs.
Of course, whether "other areas of engineering" are like this is another question (I suspect that when there's a five billion dollar cost overrun on a bridge, we have our answer about predictable processes).
But in the larger sense, I think this is the dream of every geek -- a process, a system that works independently of the people involved. We're going to keep chasing that one down for as long as our business is around.
I think Agile changed the way we all work, but it didn't fundamentally change the nature of the endeavor, which is full of guessing, hunches, miscommunication, dropped balls, and overreach, as well as insight, heroism, eleventh-hour refactors, and (above all else) lessons learned through bitter experience.
> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people
I don't know where you got that idea from, given this vital line in the original manifesto:
> Individuals and interactions over processes and tools
that's because there is no engineering yet in software development. it is at the stage of middle ages production, a manufacture in its original sense.
client says 'i need a shoe' and developers start from scratch, everytime. it's as if you're tasked with buidling a house and first you design bricks, nails, ... (libraries, frameworks, languages).
the fact that shit like i18n to this day is not natively handled by the frameworks itself and does break software in 2014 is amazing. oh you entered a date with saudi locale and their business days do not match ours? oh shucks.
outside of large scale public infrastructure projects construction is entirely predictable and safe now.
it all starts with education and there is no software engineering one - engineering is all about known entities, process and safety margins. best practices, gathered for hundreds of years.
it also explains these massive successes with software right now - it is a very young industry, public utilities do neot exist yet. you can reap massive rewards by offering sewage removal in a better way (facebook).
"outside of large scale public infrastructure projects construction is entirely predictable and safe now."
My last three home remodels and the recent corporate construction we are in the process of finishing beg to differ with you. Heck, every house flipping/building show on HGTV disagree.
The same holds true for mass produced items, especially once they've been deployed. My last pick-up truck was occasionally a nightmare to get parts for since what was on the truck didn't match what the dealer/auto-parts store said should be on there. Figuring out what brake pads to get for the after-market brakes took myself and the old guy behind the counter at autozone an hour and a half of eye-balling and trying stuff.
Building anything is hard, and when it comes time to change/fix it it become worse, especially if you need to keep using the item in question during the period that you are "improving" it. You never know what you're going to find once you start poking holes in the walls or pulling parts off.
> I think Agile is (was?), in the end, yet another attempt to make software development behave like other areas of engineering -- a domain in which processes can be trusted over people, and in which a certain set of predictable inputs will reliably produce an assured set of outputs.
No, Agile is exactly the opposite of that: the first value statement of the Agile Manifesto is "Individuals and interactions over processes and tools"
The problem is that Agile -- outside of the highly-skilled, highly-motivated, groups that initiated it -- is often a term that the kind of people who are looking for a process that they can trust over people have heard about working without understanding what it means, and so they look for someone to sell them a guide to applying this thing called agile which they imagine to be a canned process, and there are plenty of people willing to cater to that demand and preconception by selling canned processes as "agile" to people expecting canned processes that have some vague awareness of the term "agile" without understanding of its meaning.
So many, many venues are implementing some canned process, often defined externally to the organization (the most common, but far from the only, version being Scrum) and valuing strict adherence to its ritual over individuals and their interactions, and believe that by doing so they are "doing Agile" -- and so in the marketplace (though not among people who are more thoughtful and knowledgable) "Agile" has essentially lost all substantive meaning.
A little history, folks. The Agile Manifesto is 2001. Scrum is 1995. Extreme Programming is 1996. ASD is 1997.
Easy enough to say that you're valuing "individuals and interactions over processes and tools" after detailing methods and processes that do not set forth this idea at all. Agile (in these earlier formations) was all about processes and tools.
Telling me that these formations (in which agile is effectively invented) is "not the true Agile," is like telling someone that the reason they don't like Lisp is because they have not meditated long enough on the Lambda Nature.
>Now the question is: what will guide Agile through the “slope of enlightenment”?
Ditch the Agile consultants. Let each team build its own understanding of Agile principles, and implement Agile in its own way. Once Agile stops being an over-hyped cash cow, it may again bring some benefits to software development.
In other words, and as the author says, back to basics.
The thing I see every time someone decries the death of agile is that they fail to mention or probably aren't doing retrospectives after every sprint. Good retrospectives aren't complicated and don't take that much time, but they are arguably the most important part of a successful agile team.
Most of the best ideas in agile come from lean manufacturing concepts and arguably the most important part of lean manufacturing is continuous improvement. Continuous improvement in software process comes from retrospectives.
When teams fail to do retrospectives, they fail to learn from their mistakes and discuss ways to improve. I don't care what your process is, if you do retrospectives consistently and commit to take action after each retrospective, you can make any process more awesome.
Teams that don't improve their process end up with a crappy process that nobody likes. This is not an agile specific problem.
This is a poor argument. The first three "myths" in the article are all straw-men. First, Agile isn't a design process, it's an implementation process. How you arrive at those user stories is up to you, and nothing in Agile proscribes using OOD, SOLID, patterns, or any other software design process your heart desires. And please show me the Agile article that says that you should constantly refactor working code, or that technical debt should be accumulated freely because it can always be repaid. Myth #4 might make the basis of a good article (and has), but it hardly means the end of agile to suggest that just blindly following agile rituals doesn't guarantee agility.
Heinz von Foerster has spoken about the interaction between properties of the observer and the observed. In the quote below, one could replace "obscene" with "agile" -- each is impervious to objective measurement.
"There is at aperiodic intervals a ritual performed by the supreme judges of this land in which they attempt to establish once and for all a list of all the properties that define an obscene object or act. Since obscenity is not a property residing within things (for if we show Mr. X a painting and he calls it obscene, we know a lot about Mr. X but very little about the painting), when our lawmakers will finally come up with their imaginary list we shall know a lot about them but their laws will be dangerous nonsense."
That appears to be the only point in that page that resembles a process. And really it's self-reflection as a principle. But really a process is more mechanical. The manifesto says "Hey! Reflect regularly." That is not the same thing as saying "We must have a retrospective every 2 weeks using the force direction exercise..."
Your calling it a "meta-process" implies to me that you also get that distinction.
'Your calling it a "meta-process" implies to me that you also get that distinction.'
I interpreted "meta-process" as simply a remark that the process (presuming it is one, but that seemed to be the orientation of the author) addressed processes.
So? I really don’t see the problem with this. Sounds like you’re trying to make common sense into a bad thing ;-)
“Process” seems to be used as a stick for both sides to beat their opponent with… you are either doing too much or too little.
To me, a process is just an agreed way of doing things between a group of people. When it becomes a problem is when circumstances and experience tell you that this now isn’t the best way to proceed any more, but you still have to do it that way (and anyone who has worked for a large organisation will know what I mean)
Processes ought to change with time, and a lot of problems arise when they don’t… and so regularly checking whether your way of doing things is working is just sensible.
I may be misinterpreting where you're coming from, but I'll give it a shot:
"Individuals and interactions over processes and tools"
...
"...there is value in the items on the right..."
I think that's a recommendation of process.
IMO the decade of Agile has been a cluster, mostly because individuals pushing for it (IME, as a generalization) ignore the all important "there is value". Because it's not as fun/convenient/appealing/whatever (early on I was definitely one of those people).
I prioritize time with my kids over doing the dishes. That doesn't mean I shouldn't do the dishes.
Agile recommends you value people and try not to put barriers in front of communication, but that doesn't mean you shouldn't have a plan, scope of work, estimate, etc. Nothing in the manifesto at least says that. If you're doing fixed scope (yes, everything changes, but within reason it's generally easy to differentiate), fixed bid projects, then not having a plan is a guaranteed way to generate re-work, burnout and budget overruns for any project beyond the trivial.
Planning happens, wether it happens ahead of time or just-in-time, it happens. Trying to do the inevitable rework while it's still just paper is better for developers, your company, your clients, anyone.
I dunno, it seems like common sense to me. I get a contractor to bid a job in my house. The worst possible thing to happen is it takes longer than he thought and costs more. He can tell me all he wants about YAGNI and evolving understanding. My question to him is why he didn't anticipate this wall might have studs every 16" when I asked him to bid on the installation of in-wall speakers. If he'd planned it, thought through the process of performing the task each step of the way during the bid, then stupid stuff like this wouldn't happen.
IMO the Software Development world is a lot like Contracting. Mostly capable people (and some brilliant), but more often than not it's hard to find a contractor who can plan their way out of a wet paper bag. Sometimes there are good reasons for needing to change a plan. But not having one in the first place is not such a reason.
You want to thrill clients? Do what you say you will, for the price you say you will, when you say you will.
Sounds like the premise for a good article. Not, however, this article unfortunately. This article instead throws out a handful of straw-men and chiefly complains that agile doesn't help you with software design, something it's never claimed to do.
With any story like this there's always one bit that's understated. There's agile as it is practiced and agile as it is described by the founders. They're quite different.
Agile as described by the founders is so squishy it can almost never be wrong. How so? There is no process. There is no explicit denial of waterfall process. There's only values and stated preferences. If an agile project fails one can always say "Why didn't you choose a better process for the people?"
Ultimately the whole point was to deliver working software and optimize for change. That hasn't died as far as I can tell... We just achieve it in many different ways. What could be more agile than that?
"In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse," - Err, Agile is based on those principles to. Agile takes quality above all else, a task is not finished until its finished well.
Agile has always been combined with software craftsmanship, especially XP style engineering principles.
The article to me feels like the author has a high appreciation of his own understanding of software development - and maybe even very rightly so - but doesn't want to put this in a certain language other people developed (in this case "agile" methods).
I don't believe technical debt can be avoided. And it seems counter to the "debt metaphor" that you take time away from working on current demands to save time later. There seems to be no real evidence that time spent now is necessarily worth more time later (beyond reasonable planning or avoiding really stupid decisions). The debt metaphor would actually mean that time now is worth more than time later (time value of time, if you will).
Probably it depends on where the time for "avoiding technical debt" is actually taken away from...
My Software engineering Prof. Once wrote, those agile methods were first used by highly skilled teams that knew what they wanted. There has never been any evidence for them to be a silver bullet.
Big planning slows down experienced engineers, but can help the unskilled quite well...
My Software engineering Prof. Once wrote, those agile methods were first used by highly skilled teams that knew what they wanted. There has never been any evidence for them to be a silver bullet.
This is the case for pretty much anything new and cool.
Big planning slows down experienced engineers, but can help the unskilled quite well...
Plans serve (at least) two purposes.
One is so that you know what you're doing. This doesn't have to be formal and can live partly inside your head. Experienced people probably do more of this, they just do it faster and don't bother writing as much of it out (because recalculating on-the-fly is faster and less error-prone than looking up last week's overly-detailed predictions).
The other is so that other people know what you're doing and when you'll be done with it. For this the proper amount is whatever provides the most useful information (for all combinations of "most" and "useful"), without taking so much time as to cost more than it's worth.
The reason Agile worked is because skilled professionals who wanted to do software better did it properly.
Sadly there was lots of money to be made by certifying unskilled professionals who suddenly flooded the market and couldn't do software better but made it hard to find the good guys.
I knew there were serious issues when at an Agile meetup recently I had attendees having a go at me for daring to suggest that some process might be needed for dealing with staff who are either inexperienced, or unprofessional.
Agile may be dead, but not for any of the reasons the author describes. The first first two 'myths' are not something that Agile claims, and the last two 'myths' are in fact true.
> Myth 1: Good design will emerge from the implementation of user stories ... However, in practice the code does not have this tendency to self-organize.
Code may not self-organize, but a small team of programmers can. It is not the implementation of simple user stories that produces good code but rather the ability and willingness of the team to constantly refactor the code. The main point of Agile development is that you get better quality code written faster if you take a somewhat messy codebase and refactor it, instead of try to come up with a great design before writing any code.
> Myth 2: It will always be possible to pay the technical debt in the future ... However, in practice it is not so easy to pay the technical debt.
Agile doesn't claim it's always possible to pay technical debt in future, otherwise there would be no need to refactor code. What it does say is that programmers have a tendency to overestimate the chance that the chunk of code they are working on will need to be clean and flexible in future (ie. "You Ain't Gonna Need It") and to overestimate the cost of future refactoring if it does. A good example is copy-and-pasting: It's generally fine to copy and paste a chunk of once or even twice - only on the second or third copy should you start to refactor it.
> Myth 3: Constant refactoring is an effective way to produce code ... However, in practice refactoring is consuming an exaggerated amount of the efforts invested in software development
There's no question that constant refactoring takes as a significant chunk of time in Agile, but not much more than the design phase in other workflow processes. And in my experience it is simply the way to maximise the long-term addition of value to the codebase. It's a bit like that old story about how the fastest man to chop down trees spends most of his time sharpening his axe.
> Myth 4: Agility can be assured by following an Agile process ... However, in practice the process alone is not able to provide change-resilience
Again, this simply has not been my experience. The only time I have found refactoring to be painful and difficult is when the codebase has had bits of code gingerly tacked on over the years without any refactoring - and that certainly isn't The Agile Way.
> The consequence is that some teams implement new features very fast in the first iterations, but at some point their work halts and they start spending most of their efforts in endless refactorings.
News Flash: It is ALWAYS easier and faster to write code on a greenfield project than a large, old codebase - dumping Agile will not change that. At the risk of sounding elitist or relying on the 'one true scotsman' argument, maybe the author has simply not worked with people who are good at refactoring. It certainly is a skill and many programmers don't have it. Here's a great quote [1] written seven years ago on this point:
> "for me, a lot of the differences between the best programmers I've worked with and the worst are simply the quality of the abstractions when they pull out pieces of code to reuse. Often, even when it's clear that someone needs to build a piece of reusable code to call from many places, the results will be very different. Some people are naturally good at producing clean and elegant abstractions to reuse, while others' abstractions tend to leak and be a little hairy looking, making them harder to work with."
> maybe the author has simply not worked with people who are good at refactoring
I agree with you 100% but this line got me thinking... shouldn't a methodology/process in principle lower the skill level required to be effective? I understand that Agile does to an extent, but perhaps the fact that "refactoring" is hard means the process has shortcomings?
That's one possible purpose to a process. Another is to increase reliability e.g. get the same outcome every time. Like 'complete on time'. Anybody can benefit from that, even the most senior of developers.
Having done a lot of agile development, I'm not convinced there is any more refactoring involved than any other methodology. The difference in agile is that incompatibilities are not swept under the rug for months, only to erupt into crisis near the delivery deadline.
Yeah, YAGNI and its ilk may apply, but sometimes you -do know you're going to need it-. That story is in the pipeline, your users are demanding it; to design and code only to the current story, dismissing the design considerations that that future story would impose upon the current one, is shortsighted and self-defeating. You shouldn't be delivering -features- from that story yet, but by all means recognize that "Oh, we'll need a hook for that, and it would make sense for me to implement this with an event manager so we can add subscribers, and keep these decoupled, rather than just make a direct method invocation", etc, so you can easily tackle that future story when it comes up.
Oh, hey, the build and deploy process sucks, and that has no direct user value, and thus no story. Well, deal with it anyway; you -know- that is costing you time, and being able to rapidly iterate = faster development time = less cost = desirable to the user.
Etc.
Really, agile always seemed to me to be two different things. One was a series of processes. The other was a series of values (among which was people > processes). And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around.
EDIT: I've also seen teams that take the values as excuses to ignore the processes, which also fails hard. "People over processes? Okay, no process then, everyone just code! Get shit done!" The point is to take on the processes, modify them in accordance with the values as experience leads you. Something doesn't work for your team? Change it. As someone mentioned elsewhere on this thread, that's what retrospectives are for.