Tag Archives: agile

long live agile. is agile dead?

Pick your favorite agile luminary. Chances are, this year they’ve been saying they’re done with agile. No more, after this year.

I’m not positive my list is precisely correct, but I’m thinking I’ve heard this from Rachel Davies, Brian Marick, Michael GeePaw Hill, Andy Hunt, and I’m sure more folks (though I hesitate to name names, in case I’m wrong).

At RubyMidwest, I asked Andy Hunt about this. I’m sure I wasn’t at all articulate, but what I wanted to ask was this:

“I get that agile has become mechanical, and that’s a bummer. But as someone who fell in love with agile pretty recently, I don’t want to lose the… agility? The emergent design stuff, the inspecting and adapting. When I hear y’all saying you’re done with agile, I wonder what comes next? What do you envison is the alternative?”

And even though I’ve gone round and round with GeePaw about this, I think Andy is the one who finally convinced me. You know what he said? He said that

agile was a solution to a problem. And that agile worked to solve a bunch of them. Whatever replaces agile, he told us, will be the thing that solves the problems we have now.

Holy crap. That was convincing.

It also meant I can actually love all the empirical, emergent, collaborative stuff agile brought us, while I head off into the future.

WOW

What do you think? Is agile dead? Do we keep preaching it, coaching it, putting on conferences about it? What do you think the next decade looks like?

Functional agile: how does it work?

So I was thinking in the shower about how agile technical practices and functional programming both aim for something like “good” code, but then it occurs to me that — no surprise — “good” doesn’t tell me much.

I want to listen to what each “side” is excited about — not for “niceness” or for getting along or for unicorns and rainbows, but because I am all juiced about both, and I want to share that juice so I have more people to play with.

My first thoughts are that functional talks about correctness, and agile talks about utility. Functional programmers want clarity of vision, I think, with a precise understanding of the solutions they create, so they’re as simple as they can be, reusable and composable. And maybe agile developers are thinking about extensibility, maintainability, helping coders with stuff like staying focused, learning new stuff, avoiding getting buried in complexity.

I am guessing each would smile heartily at the things that motivate the other.

The thing that got me excited this morning was noticing that agile — even the technical practices — is about people. Pair programming, test-driven development, specification by example, and continuous integration are strategies for getting working, extensible, maintainable code, given that we are creative beings, going through life reaching for treasures without being able to predict the results of what we do. I call us mistake-makers; we poke at things and sometimes like what happens. We have brilliant days, and low energy or sad or un-brilliant days. We often don’t know what a solution will look like until it begins to take shape, and our solutions often involve learning, collaboration, discovery.

Here’e what I want to know: how do collaboration, discovery, emergence of solutions, and other agile values fit with functional programming? And as agile devs become fascinated with functional programming, what changes? Does this mean they leave their agile peeps behind? Or does the new functional stuff they’re discovering become part of their agile world?

Are commitments the only way?

Have I told you folks lately how much I appreciate the answers I get here? I mean I’m grateful, and feel all warm inside, but also, I just really love reading them and learning what agile looks like in different places, for different people. I learn so much from you! So, if I haven’t said so lately (or even if I have), thanks.

So, last night, Justin @searls lit up twitter with this:

Agile friends: anyone out there still believe the “agile commitment” is worthwhile? My writing wants your (starkly opposing) viewpoint.

Later, once the conversation had taken off, he added this:

an agile team guesses what they can accomplish in an iteration, commits to it, and submits to ritualistic beating upon failure.

On the subject of commitments helping with trust, Zach @zspencer said:

Promises that are kept help. Promises that aren’t don’t.

To which Justin replied:

success is never certain, or commitment would be unnecessary. You’d recommend a team risk promising an uncertain outcome?

Wow. Big conversation. And there’s a question coming. First, the part where I ramble. :)

Are promises part of life?

…I don’t typically make promises. I have intentions, and I share values with people. I care about them having what they need to be happy, and I care about me having what I need, too. I love collaboration and I love getting things done. That’s something I want. But it seems to me a promise would mean I’ll do something even if I don’t want to, even if something changes so the original plan won’t work. Or even if I was wrong about what would, in the future, be possible (or a good idea).

If I “promise” to finish something by Friday, and I don’t, it may well be because I choose to do something else rather than finish. For example, maybe it took longer than I thought, and I valued getting some sleep and taking breaks more than finishing, for example.

Maybe I chose to organize my collection of e-books instead of working on the project.

Would a promise help with that?

If I did choose to organize files instead, we’d have a problem that’s not about promises, and not about Friday. It’s a problem the moment I lose interest in the thing we both want to create. Maybe it’s too hard (I feel stuck). Maybe I’m not engaged. Maybe I don’t have the tools I need. Maybe the environment at work is so pressured that I can’t think. A good retrospective might help us figure out what’s really going on.

But if we’re on the same side, you know that we both value what we’re working on together. Maybe in a particular case, “you” means a manager or business owner, and “me” means a developer. We share an agenda, a devotion to something of value, and we work toward that at a pace we find, not just sustainable, but exciting, interesting, productive. We work out a shared intention, and then watch what happens.

People often tell me I don’t really mean that I don’t make promises, so let me be really clear. My spouse and I don’t make promises to each other, either. If one of us were unhappy, neither of us would want that person to stay. No promise is required when we’re both doing what we value.

So that’s me. I would really like to know how promises and commitments look in your work. (I don’t mean to bombard you; there are a lot of questions here, but I’d welcome an appreciate an answer to one or two that jump out at you.)

Here’s what I’m wondering…

Do you use commitment on your agile projects? What do you mean by commitment? What happens if you “break” that commitment? What causes the commitment to be broken? What are the consequences?

How do you build trust on your teams? Or between your team and the business?

Have you found a way to work — successfully, in the world — without commitment? What does that look like? What changes when you work that way?

What is up with all the apairia?

The love of pairing, specifically pair programming with real geek joy, is seeming quite scarce. I keep finding myself around folks who, from my perspective, don’t get it. I want to really understand this. Get underneath it and inside it and get it.

So I’m asking: What are the causes of apairia? If you have personal experience, what do you hate most about pairing? If you’re a coach, have you seen people go to lengths to avoid pairing?

I am not asking to hear good stuff about pairing. This is all about a•pair•i•a: the fear of, hatred toward, or avoidance of pair programming (esp among fans of collaboration and code quality).

What are the causes? Are there effective treatments?

GeePaw sez…

If you’ve only ever had bad pairing experiences, it can seem like the best thing is never to pair again. I even know several coaches in that camp.

Consider dancing, another highly interactive joy-bringer. Imagine how you’d feel about dancing if:

  • your partners were all also first-time dancers;
  • you only ever danced in a tight closet;
  • your idea of dancing is for you to sit there and watch;
  • you get yelled at for stepping on toes;
  • you had the same partner for days;
  • …you get the idea.

We need to make sure every noob has at least one excellent pairing experience. If we fail to accomplish this, we can lose potentially terrific pairs forever.

Is ‎Object Oriented the best?

I’ve been hearing sincere complaints lately about object oriented programming, about the Craftsmanship Movement, about Agile development practices. I hear from folks who are excited about functional (denotative) programming, who write concise little functions with one character names. (Some have objections to TDD, or think pairing is costly, but those are on the edge of what I’m talking about). And I’ve been wanting to really listen.

And of course, I hear a lot from folks who love TDD, love Object Oriented structure, love pair programming and long method names. And those are the folks I hang with, for the most part. So I’m wanting to listen to all of it, and see what I hear.

Though I sometimes hear that Object Oriented is “just better” or that TDD is “always appropriate” — what I call Argument From Fist-on-Table — that idea doesn’t help me much. In listening, I’m looking for better at what? and appropriate to what end?

So for many months I’ve been wondering why I’ve been pretty content to love OO programming (though I can see the mathy beauty of FP*) and why I love the things that get called “clean code” (without loving the setting of it as a categorical imperative). Talking to @kaleidic this morning in the wee hours, I realized what it is that I love about them.

I love the whole shebang — “craftsmanship”, TDD, the Four Rules of Simple Design, long names, etc. — because I love collaboration. Not just because it’s juicy and fun, but because it supports the emergence of good systems, and things like flexibility, responsiveness, changability. I love having a shared code base, and object oriented “craftsmanship” is a strategy for getting that.

I also love evolution, and folks following the sparkly stuff, so when I see smart friends like @kaleidic and @conal and @tunixman railing against object oriented programming, for example, I’m excited about what they’ll come up with. But I realize that whatever techniques emerge, they won’t just have to be about faster or even more accurate code to make me love them. They’ll have to fit into the collaborative social structure that makes Agile so beautifully effective.

* Really itching to work on Conway’s Game of Life without state changes, in fact.

A question anyway

So I answered this question for myself, but I am still curious. What is important to you about your preferred style of coding? If you’re an Agile developer, why do you love long names and TDD and objects? If you’re a Functional / Denotative Programmer, what do you love most about your code? Can it be made collaborative in the way I’ve described?

Do complex projects need design up front?

“Agile purists”, Bob Customer says, “don’t understand my reality. Nobody ever tells me how agile says we’re supposed to manage the overall architecture.” Without an orchestrated design process resulting in thorough design docs, how could we keep all the disparate pieces together?

What does Agile tell us about big projects with lots of little parts?

GeePaw sez…

Bob, the best way to manage a large project is by continuous interaction between teams and between teammates while coding proceeds according to a work-in-progress-limiting scheme.

Skilled rhetoricians constantly invoke “painting yourself into a corner”, or “the local optima problem”, or they just sometimes jump out and say “BOO-GA BOO-GA BOO_GA!”

This scare-mongering is effective because we all know large complex software is risky, and we all wish we knew some way to make it safe. Architected projects are no more likely to succeed than un-architected ones. Two thirds of all large projects (>1 year), ship 6 months to a year late. The other third never ship at all.

Sometimes you just have to live with your fear for a while. Certainly, utilizing mechanisms that have never succeeded will cost you a lot without helping.

Don’t worry, though. Once you’ve nailed that first big project using agile technique, you won’t have to be scared of them ever again.