18

I want to improve the way that I develop software. I want to develop faster and a great code! Today I use the waterfall method as freelancer, writing web stuffs (sites, systems, etc). Is there a way to use agile development (XP, SCRUM, etc) working in this way? I don't know nothing about agile development, where should I start? Thank you very much.

Improve this question
5
  • Among other things we are doing "single developer scrum" in one of the teams of our company, it works nicely because the developer is self organizing and priorities on the open stories (backlog items) are assigned by the Product owner. I think scrum it's anyway worth and could simplify and speed up things compared to waterfall. You can have some reading about Scrum methodology.
    – Davide Piras
    Commented Jan 19, 2011 at 13:58
  • I'm voting to migrate this to programmers.stackexchange.com, but I recommend reading SO regular S.Lott's blog entries labelled 'agile.'
    – Jeff Sternal
    Commented Jan 19, 2011 at 13:58
  • 7
    The daily standup meetings might be kind of lonely.
    – JohnFx
    Commented Jan 19, 2011 at 15:48
  • 2
    Scrum estimation is based on the "Wisdom of Crowds" without the Crowd it is hard to get their wisdom.
    – Loki Astari
    Commented Jan 19, 2011 at 16:52
  • we don't estimate during scrum we do it during sprint planning which a freelancer could/would still do with the client
    – Michael Durrant
    Commented Mar 31, 2012 at 3:04

6 Answers 6

Reset to default
17

... Other than pair programming, sure. ;-)

Seriously, I'm a freelancer too and I use agile techniques as much as I can. It works for me very well. I make huge use of TDD,

Nobody anywhere uses 100% of XP or Scrum, but everybody uses parts of it, trying to adopt as much as works for them. In my opinion, the more of that you adopt, the better off you are.

The thing I miss out on the most is pair programming. The way you overcome that is

  1. Go to lots of user group meetings.
  2. Find a couple of folks whom you respect as developers.
  3. Ask them to meet you over coffee or something to write code. Give them part of your hourly wage occasionally if you feel that is necessary or just respond in kind to working on their code.
  4. Attend or create a Hack Club like this one: http://www.DallasHackClub.org.

Here are some resources I use:

Extreme Programming Pocket Guide

Improve this answer
4
  • +1 for the fact that the best best approach is never 100% of just one methodology
    – Filip Dupanović
    Commented Jan 19, 2011 at 15:18
  • @kRON - Not that I don't agree, but just make sure you initially follow the entire process as much as possible. Then you'll know that it needs tweaking instead of discovering you didn't execute it properly.
    – JeffO
    Commented Jan 19, 2011 at 17:58
  • 2
    +1 As Bruce Lee so famously said, “absorb what is useful, discard what is not, add what is uniquely your own.” This applies especially to big-A "Agile".
    – Rein Henrichs
    Commented May 3, 2011 at 0:07
  • An agile team, and person, should be able to adapt, and and the end, there is neither xp nor scrum, but a process that fits well to the team or person.
    – OnesimusUnbound
    Commented May 3, 2011 at 3:33
8

So I would say there are three main "awesome points" to using Agile as a freelancer:

  1. For larger clients, Work/bill in iterations. At the end of the iteration the customer can continue work on the project, or end the project (ie: it accomplished its goal). I know (from experience) I can't estimate well more than a few weeks out, and pay-per-iteration also keeps the cash-flow coming in. It's no fun to be at month 6 of a 3 month project, and waiting to finish the project so you can bil...

  2. Agile means change happens. I've done a ton of fixed bid projects (which you think you can do with waterfall) that have lost me money, because of a customer request in the middle of the cycle. Change happens: the customer can deprioritize a ticket to get some other work done faster, or maybe you forcasted wrong and didn't get as much done as you had hoped.

  3. Good customer collaboration tools. My standard estimate (for something smaller than an iteration's worth of work) is actually a series of Behavior Driven Development steps derived from the client's expectations. I send this to the client and say "Is this correct?". It makes sure everyone is on the same page.

  4. Simplest thing that could possibly work. It's something to keep in mind as you're working: don't be afraid to go back to the client and say, "This would be a lot simpler (or more powerful, or whatever) if we did it this way..."

  5. Scrum is important. I like sending my clients an email every day I work on their project. This is like my scrum to them: "what I worked on today", "what/when I'm going to work on their project next?", "Is there anything in my way?", and "Overall, how goes progress?"

  6. Test driven development is really useful too, even as a single programmer. My "estimates with BDD stories in them" help me feed this process.

Improve this answer
6

A great way to begin your Agile journey is to set up your workflow using a KANBAN system.

We simply have 3 swimlanes:

  1. Our TO-DO's or Backlog
  2. What we are working on or IN PROGRESS
  3. Things that we complete or DONE.

This simple Agile workflow is a great way to start.

In terms of coding, I would recommend using test-driven development (TDD). We included a lot of great links describing TDD in our article but will re-copy them here:

For more information check out the following resources:

Improve this answer
1

Since your an individual, it's best you approach agile methodologies as something that's there to help you grok-out what works best for you. They're there to help you reach that "there is no spoon" plateau, but how exactly is that going to happen is entirely up to you and what you come up with in the end will greatly overlap with some methodologies on various levels, yet it'll be something completely yours.

Since your trying to find a your own way doing things to improve your overall effectiveness, here are some pointers that can help you at least not make the same mistakes I did:

Forgo all software solutions exclusively targeting agile methodologies, for as long as you can.

The fact that they are more suited for facilitating team collaboration is beside the point. Resist the temptation. You don't box yourself in a way of doing things and then hope adopting it will work out for the best. It doesn't, it just frustrates you. You first find your way of doing things and then seek out a suitable software solution. I've ended up with using whiteboards (started with one, but now I have two in my room) for tracking/developing stories and the Pomodoro Technique | To Do Today list to track my development tasks and it's friggin 2011. Stick to the basics until we get some interfaces such as those out of Iron Man 2 or flying cars begin to appear.

Reflection, reflection, reflection

This was what I came to understand to be the single most important part of any methodology for an individual. It's about developing this workflow that gives you a holistic view of your project so you can keep track of what needs to be done and when in a manner that is easily manageable and where bad decisions are rarely made and stand out so they can be quickly amended before they cause any damage... but you can't just pick it off the shelf. Start from somewhere, anywhere. You stick with it for as long as it works. Invest into tracking the good, the bad and the so-so. Improve your assumptions, then adjust the way you do things accordingly. That's the only way your going to improve.

Furget about deadlines, focus on how fast you get things done

I was probably like the next guy when I began, chasing dates. Burnout charts? I used to think of them as a way to visualize my development track against deadlines. It's a performance, not an estimate model. Time is there to measure your effectiveness by reflecting upon the work you've done within a certain time frame, not just some dumb value to represent the distance before impeding deadlines. The reality is that stuff gets done when it's done and your methodology should account for that.

Deviate accordingly

In the end, who says you have to use user stories, or anything we know of for that matter? Don't think like that. If your more comfortable with thinking in features, then by all means defy the global development community and do it your way, because getting stuff done is all that matters at the end of the day. If you end up feeling like your doing something wrong, congratulations--you've just concluded that it's time to leap to something else. It's about the whats, not the hows.

Improve this answer
0

I'd answer "how do you want to improve the way you develop software?". For your business model, what are the biggest issues you've encountered using the waterfall methodology?

Is your goal faster development, more robust code, greater reuse, meeting / adapting to changing requirements etc? Different methodologies exist to overcome different problems.

Improve this answer
0

Of course adopting a design methodology other than Waterfall can be very useful in effectively managing a projects lifecycle depending on your business requirements. For agile development there are vast number of resources online. I would look into AUP (Agile Unified Process) which incorporates TDD (Test Driven Development). This can be extremely useful when building/managing large scalable systems.

There is no 'one size fits all' methodology and this is the main reason for the vast number of different approaches. I would start thinking about where you feel the bottlenecks are in your development process currently and then try to adopt a new methodology to overcome this.

For example do you often fail to meet deadlines? Do new features introduce a large number of bugs? Do new requirements cause major redevelopment? Does the business require regular working systems to be presented? Check out: Agile, Iterative and Agile Intro.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.