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.