Agile software development is a great thing. It makes people deliver real value faster. Based on the agile manifesto there are a lot of processes and frameworks available (XP, SCRUM or Lean Software Development anyone?), which try to enable teams to develop better and more relevant software. So far, so good.
In our company, we’re only five people – all involved in building and running our web application. We started from a very #notagile approach, and successfully introduced agile practices like user stories, story points, a backlog, and the notion of velocity achieving a tremendous increase in our productivity. But nowadays, we’ve moved on. The strict processes don’t fit our current way of working any more.
Agile, without the processes
We don’t do iterations. We don’t do estimations. We don’t do planning games nor do we track velocity. We’re just cranking out feature after feature, the gold owners giving us new fodder daily. As soon as one user story is out the door, we just grab what’s next on the backlog and get started. Zero overhead. Of course, we have automated tests (a couple), git as our version control and a continuous integration server (at least, if we make it run again 😉 ).
Seems that those few things are the bare essentials we need to go as fast and lean as possible. It took me some time to understand and accept that all the other nice things were just not necessary any more. We reached agile nirvana. But be warned. Chaos is lurking around the corner. As soon as we do one false move into the wrong direction, things might get nasty. This is the challenge: Keep the balance between as fast and lean as possible dropping any non-essential process steps and drowning in total chaos, because you dropped one process step to much.
Agile Web Operations 
Sounds more like “Agile on a diet” –> KISS. I like it.
LikeLike
It’s refreshing to hear from someone really meshing agile with what they observe about their particular situation and making this kind of powerful hybrid. That’s real agile – it ought to be what everyone understands to be the goal.
The practices that we all identify as Agile were reactions to specific problems, experiments that turned out well. There’s no good reason why they ought to be the final iteration on team process – that’s just crazy, a totally incorrect way of thinking about agile. Anyway, you guys clearly get it. I’ll be interested to hear how your process evolves.
LikeLike
How do you refactor without test coverage?
LikeLike
@Steve said:
– That’s one of the really sad things happening nowadays. People are so focused on process without paying enough attention to the agile essentials as described in the manifesto. I think, everybody should cherry pick what works for them and not be enslaved by whatever process others have created in another environment.
LikeLike
Kudos for finding a process that works for you. I’m concerned — hopefully not as a concern troll, but really concerned — that your shortcuts will bite you before long, especially as you’re at a team size (5) where the number of interlinks is really starting to rise up the exponential slope. Currently I’m doing solo coding on a personal project. No CI, no GUI tests, no pairing (obviously), no iterations, no estimation. So I see where you’re coming from. I also expect my (as yet unmeasured) velocity will go way down if and when I add a second person. But the team will thereafter scale to a size where I’m not a bottleneck, and the velocity will eventually go higher than my personal best.
> We don’t do iterations. We don’t do estimations. We don’t do planning games nor do we track velocity.
These techniques are primarily for helping predict the future. If your stakeholder is OK with not being able to predict things like upcoming releases (to synchronize with a sales cycle, or to do capacity planning, e.g.) then their only value is to the dev team itself. Perhaps the next time you start to drag you won’t notice because you’re not tracking velocity, so you won’t be able to take corrective measures. Or you may *feel* you’re slowing down but checking your velocity will make you realize you’re within the norm. Also, having a weekly checkin can help you gain perspective; maybe you’ll realize that feature you were about to spend all week on is not necessary after all, and gain a bonus week.
Are these possibilities worrisome to you? If no, then more power to ya.
> we have automated tests (a couple)… and a continuous integration server (at least, if we make it run again)
OK, now this really concerns me. Without full tests, how can you feel comfortable refactoring? And what good would CI be even if you turned it back on? If you really have poor test coverage then the metaphor of “on steroids” is chillingly appropriate: you may get a short-term power boost but after a while your liver and kidneys will start failing and you’ll grow hair in strange places…
LikeLike
@Alex – thanks for expressing your concerns – they are more than valid. Regarding estimation and planning: Our gold owner does not expect us to predict any specific releases. The only question we’ve to answer is: “Will this story make it into the next release?” – and that one we can answer easily. BTW, we are using Pivotal Tracker and we do estimate every story as soon as we start it. So technically, Tracker is tracking velocity for us – but we do not pay attention 😉 But we could at least come back to it, if ever necessary.
@Alex and @Steve regarding our test coverage: True, we do not have full coverage. This is rooted in the beginnings of our site, which was initially developed by an external consulting shop. Not agile, no tests. We’re playing catch up and do have around 900 tests currently. And, I setup hudson in the mean time. How we can refactor? We’re very careful, and we’re adding tests as we go. That’s all we can do for now. Hope we won’t grow hair in strange places too soon 😉
LikeLike
> We’re just cranking out feature after feature, the gold owners giving us new fodder daily. As soon as one user story is out the door, we just grab what’s next on the backlog and get started.
sounds a lot like kanban to me.
LikeLike
@Tim – yes, our process currently comes much closer to Kanban than e.g. to SCRUM. We’re not using hard limits for WIP nor do we use a column wise visualization anymore (we used to, when we were using Mingle, but with Pivotal Tracker, that’s not possible). But we try to get the cycle time of each item down (instead of velocity up). I see a lot of value in lean ideas for software development.
LikeLike