Busy with: review of development infrastructure and processes, code review, and development strategy for speed

General, Business, Technology, Code, Team | Comments | Trackback

June 25th, 2009

I recently Tweeted: “Not doing #agile is like walking thru molasses with your hands behind your back, with blindfolds on, covered in treacle “. The context of this was an engagement where I’m essentially evaluating the software development processes within a business where the underlying need is to be robust, fast and agile.

Note they’re not all the same thing:
Robust is code that doesn’t break, is easily tested, scales well, and where collaboration is easy.
Fast is what it says on the tin, literally releasing new code fast and often.
Agile means being able to change direction, or make changes, quickly.

In my experience, Agile software development is the best way to enable the above - it’s a compromise between speed, collaboration and real results.

So with this engagement, the brief was to review everything (tools, processes, infrastructure, code) and to come up with a document that includes analysis and recommendations. My observation from this experience is that there is a fine line between agile development and chaos, but that this line gets thicker the more you invest in the right systems, processes, tools and infrastructure, which all enable and support doing *stuff* fast.

For example, in no particular order:

1. Testing is harder than it needs to be if there are no testing environments, unit tests, documentation of code, testing scripts, user outcomes (there are many examples, these are just a few)
2. It’s difficult to estimate and prioritise for business priority, when your list of items to work on is not prioritised or you don’t know what dependancies are
3. If you ask people to step outside of their comfort zones, more often than not you’ll be met with resistance. Use tools that make people comfortable
4. If it takes a long time or is difficult, to release a version of your software, then you’ll release less often and make more mistakes
5. If everyone understands the processes involved, you’re more likely to become more efficient. If those processes are changing or non-existent, efficiency is hard to gain.
6. If you’re going in the wrong direction, you don’t want to get there faster. If your code doesn’t support quick changes, you’re not going to be able to change direction quickly

The above are just some examples that were pertininent, so you should get the general idea.

My hope is that with the right motivation, we’ll fix the issues holding things back by setting up the right infrastructure and processes to support the business goals, and end up creating an environment that does indeed foster robust, fast, agile development.