malvasia bianca

I’ve gone to every Agile Open (Northern) California, and it’s absolutely my favorite conference. I’ve learned a lot there, I’ve had a lot of really interesting interactions there, it always gets me thinking. For a few years, the conference was therapy for me; fortunately, that wasn’t necessary this year.

I felt significantly more detached than usual this year, but that didn’t stop it from being great: two of the sessions that I went to were excellent, and just being there got me thinking about what I might want to do with my programming.

 

The first talk was by Josh Kerievsky; I forget the title, but basically, it was about what modern agile might look like. (Update: Here’s his post summarizing the talk.) One metaphor that he had at the start was “getting rid of training wheels” – when teaching his kid how to ride a bike at all, they didn’t use training wheels at all, they instead used a “push bike”, which (I believe) is basically a bike without pedals. So the point is that it teaches you about balance right at the start, whereas training wheels don’t help with balance but instead teach you something that is much easier (how to pedal). In that light, when rethinking agile, we shouldn’t necessary assume that traditional practices are good even as a stepping stone to better practices: maybe they’re simply going down a route that in retrospect isn’t so useful.

Here were his suggestions for what modern agile would focus on:

Outcome. Take Kathy Sierra as inspiration: make users awesome, make them badass.

Lean Startup. Rapidly and frugally validate or invalidate your ideas. Fail fast on your requirements.

Continuous Deployment. Amazon deploys code every 11 seconds on average; Intuit runs 300 experiments a day.

Blameless Culture. His example here was Etsy: a new employee took down the entire website, and ended up getting the “three-armed sweater” award.

Somewhere around here was an interlude: lean startup changed the definition of Done. Done doesn’t mean that code satisfies the acceptance criteria: done means that users are using the code and being badass.

Kanban. Work with windows of time instead of sprints. At the end of sprints, quality goes down in order to cram stuff in; also, sprints work against continuous deployment. Thin vertical slices certainly are valuable, but sprints are bad training wheels for that. (And note, when doing Kanban, you still have to make sure your slices are thin: if something sits around too long, that’s a bad sign.)

My memory was that this got some amount of pushback from one or two people in the audience. Which surprised me, but I also heard other people talk about this in other sessions, that some people really like their sprints and their estimates.

Evolutionary Design. An old principle but still good.

Cross-Functional Teams. Ditto.

Another interlude: in early days, all teams learned managerial and technical agility. Now it all starts with the management side (i.e. Scrum); this starts off fine but turns into a mess a few years later. So he thinks Scrum is a bad training wheel, you need balance. Also, programmers want to badass, to take pride in their work.

Mob Programming. Or pairing in general, not just on programming. His company has been experimenting with mob programming from 11am to 1pm every day; it helps deal with the big problem of knowledge silos. They like the results so far. (I asked him a bit about other types of pairing; I got the feeling that in general he thought that pairing was a good idea that hadn’t gotten the traction is should have.)

Minimize Estimates. Design your process to not depend on estimates: the secret to hitting a deadline isn’t estimates, it’s evolutionary design.

(Blameless) Retrospectives. Another oldie but goodie.

DevOps. Modern agile brings devops into the fold, not as a separate team.

Story Mapping and Personas. This helps inform the notion of what it means for a user to be badass.

Lean UX. One thing he noted here is that this goes against continuous deployment: you get a better user experience if the UI doesn’t change piecemeal.

 

That was an interesting list from a conceptual point of view, but also useful to me from a personal point of view. It’s gotten me thinking about what learning I want to get out of my current job; I’ve long since given up on the idea that my current job will teach me much new about agile, but actually there are two items on Josh’s list, Continuous Deployment and DevOps, that my current job has taught me and continues to teach me about. So, in retrospect, while my job isn’t teaching me much new about traditional agile, there are at least some aspects of a potential modern agile that it’s a very good place for me to learn about. (In fact, my current project is getting me in the thick of both Continuous Deployment and DevOps, which is great!)

 

The other talk that I thought was really interesting was by Matthew Carlson, on What Social Science Can Tell Us about Agile. Here are some slides; I think they’re world-readable? Part of it was going over the Crossing the Chasm ideas: early adopters, early majority, late majority, etc. And part was talking about pressures to conform (“isomorphic pressures”) that are always present, which he classified into three groups: mimetic pressures (imitating others), normative pressures (social conformity), and coercive pressures (do this or else).

And then he talked about decoupling: gaps between policy and implementation. The point is that you have that trio of pressures both on the side of the official policy and on the underlying context that the implementation takes place in; you need to conform to both, but that may be quite difficult, putting you in a double bind. So the upshot is: decoupling is a solution, not a problem: it’s a solution to the very real problems arising from conflict between the pressures of context and the pressures of change in policy.

He presented various results related to this; e.g. that late adopters typically get less benefit from adoption than early adopters, largely (I think) because of this decoupling.

 

And the conference was also a time where I could sit and think. I don’t want to talk too much right now about that, but maybe more will come out in that regard in future blog posts.