I'm in a team of two developers and currently we have no formal processes for software development and testing - I'd like to adopt one solo initially.

Where I need some opinions is really on the matter of where to begin? Having read various books it isn't terribly clear what the best starting point would be.

Recently I put in place a simple sharepoint/access database for recording issues and resolutions, and a changelog. Beyond that, testing is a manual process.

In my control is the process by which I design and develop any of my own tools or content and would very much like to adopt a lightweight agile methology that works well for a single developer but is intended to be a "follow my example" for the company to pull all the software development into it.

I do like picking out items from various projects I have on the go and refactoring them or adding functionality; one of the notions I was considering was the notion of user stories whereby I could cherry pick out various stories when I was in the general project to which it applies.

Anyone else in a similar single developer position who has adopted agile/other 'ology?

closed as not constructive by Robert Harvey, Eric King, user40980, user7007, Martijn Pieters Feb 22 '13 at 17:08

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • This isn't a suitable question for Programmers. See blog.stackoverflow.com/2010/09/good-subjective-bad-subjective, especially the Guidelines for Great Subjective Questions, about a third of the way down the page. – Robert Harvey Feb 22 '13 at 16:30
  • @RobertHarvey tbh honest Robert, I've no idea where on Stack this could have gone and figured this is probably the nearest match. I'm at work now, looking for advice during a break and have a couple of good starting points. Can you suggest how better I should word it for better community benefit? – Richard Feb 22 '13 at 17:02
  • 1
    It's not the subject matter; it's a discussion and a solicitation for opinions, not a specific question. – Robert Harvey Feb 22 '13 at 17:05
  • @robert then tbh I'm a bit stuck as to where else I'd ask this actually! Do you have a suggestion? I wished to post on the stack network as the advice is relevant to me and the wealth of info out there makes it hard to know where a lone dev would begin. Hence my feeling it wasn't an unreasonable question to ask the group, I couldn't think of a better way to elicit what I was looking for. – Richard Feb 23 '13 at 7:21
  • Well, looks like you got a pretty decent answer. – Robert Harvey Feb 23 '13 at 7:36

I did this in my current position not in case we hire another developer, but to manage the current situation. I do: support, training & materials, documentation, requirements gathering, and make a presentation to C-level execs each quarter

A Sprint lasts a week. I built a small database to track any project that has multiple pieces. Most projects are just a one page document that is probably a consolidation of a few email messages. There's no way I could plan my schedule any further into the future.

Project Owners I work with different people in different departments on many small apps, reports, changes, etc. The goal is to work as closely as possible with these people to work out the details. If I feel a higher-up manager won't have the time to do this, I'll suggest working with someone else who is a little closer to using the project. Very few people can conceptualize what the "really" want until they see something (prototype) and they come up with a better idea of what they want. No detailed specs or contracts here.

Adding one more developer could change this depending on the reason for the new hire. If it was the result of a large project, we would lengthen sprints, try to review each other's code, share more information, and coordinate the project together. If it was because there is a backlog of these little projects, most of this wouldn't change. The goal would be to get the new person up to speed and each one would work independently on the small projects. Of course, we'd like to have more exchange of knowledge and prepare for the "hit by a bus" scenario, but the reality is, management isn't going to be happy if we add another developer and not get a lot more done.

  • I like the idea of the one week sprint. If I can get out of mandatory interruptions like support calls, I could do these in a reasonably reliable fashion :). – Richard Feb 22 '13 at 17:04

If you only added one thing, I'd suggest regular retrospectives. From there you'll be able to find out where your current (non) process makes you hurt, and you can start there.

My uninformed guess is that you pretty soon will realize that you need a good interface between you and whoever is responsible for the requirements of the systems you're developing. Delivering in short fixed-time iterations is generally considered a good idea in order to reduce amount of work in progress, managing expectations and establish a short feed back loop.

This is a rather defensive way of introducing some agile methodology. If you prefer a more agressive way, just read up on, for instance, scrum and try using that methodology although your team is smaller than a typical scrum team.

  • thank you. I do a lot of client feedback, partly due to support calls and partly to do with the role I had when I started. I ended up on the road a lot talking to clients. Often I can work out a thorough understanding from a telephone conversation-as long as I've walked through their use case by letting them lead me sufficiently; I can refine and suggest from there. – Richard Feb 22 '13 at 17:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.