Tackling Freelance Projects Like a Software Developer
Have you heard about the trend of standing room only meetings? Instead of having a team sit around a conference table, they’re made to stand up for short meetings instead.
The trend is becoming prevalent in tech companies, and is meant to eliminate long, boring meetings where no one pays attention. Some companies have even instituted a penalty for being late to a meeting—either through sheer humiliation or a small fee.
If someone is rambling on for too long, an employee may hold up a rubber rat indicating it is time to move on. Companies make exceptions to their no-sitting rules if a worker is sick, injured or pregnant—but usually not for workers outside the office telecommuting on Skype. —wsj.com
The trend is fueled by an approach to software development called “Agile”, which calls for compressing development projects into short pieces. It also includes daily stand-up meetings where everyone can update everyone else with what they are currently working on and any obstacles that stand in their way.
I think it’s brilliant! I immediately started wondering how I could incorporate this way of thinking into my freelance life. I took a look at the Agile Manifesto and sought to translate it into something freelancers could use. Here’s my attempt:
Agile: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Freelance: Our highest priority is to satisfy our clients through timely delivery of high quality work.
Agile: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Freelance: Welcome challenging requirements, even on deadline.
Agile: Business people and developers must work together daily throughout the project.
Freelance: Communicate frequently with your client throughout the lifespan of the project.
Agile: Working software is the primary measure of progress.
Freelance: Satisfied clients are the primary measure of progress.
Agile: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Freelance: After each project, deduce what worked and what didn’t, and figure out how you can improve upon it for the next assignment.
What I like about Agile is that these software developers compress their large development projects into short pieces, which is how I like to work on large projects.
Having a gigantic project in front of you can be overwhelming. Where do you start? How do you manage everything you have to do? Depending on your area of expertise, the answers can be very different. For a writer, however, here’s how I break it down.
Assignment: Write a 2,500 word piece on xyz.
- Step 1: Do some research on xyz on my computer. Find out who the major players are and who I should interview.
- Step 2: Make contact with the people I would like to interview and schedule a time to talk, either over the phone or in person.
- Step 3: Develop a list of questions to ask in my interview based on prior research. Depending on who the person is, I will email them some questions ahead of time. If I am looking for specific statistics, I always ask for them ahead of time.
- Step 4: Conduct interviews.
- Step 5: Start constructing the story.
- Step 6: If I am in charge of getting photographs (which I sometimes am) I choose a photographer and send them the first draft of the story to read over. Send them ideas for photos and send them the contact information for who they need to work with to get the photos.
- Step 7: Finalize story and send it to the editor.
- Step 8: Create invoice and send it to the appropriate person.
Throughout the process, I shoot my editor an email or give them a quick phone call to let them know how it’s going. I also let them know if I am having a problem contacting anyone, as sometimes the editor of the publication can open doors for me that I can’t.
I try not to move on to the next step until I have completed the previous step. Sometimes this doesn’t happen, especially if I am working with a photographer. But I try to control my work flow so that it follows a logical order. I never start writing a story until I have all the information I need. When I have done this in the past, it has just created more work for me because, essentially, I wrote the same piece twice. I like to be as efficient as possible.
Of course, if you are a photographer or graphic designer, your work flow will look different. But if you can break it down into stages, tackling a big project won’t be so daunting, and you can mark your progress along the way.
Photo credit: Some rights reserved by tomgowanlock.
Leave a Comment
There is an excellent book on this topic, called Getting Results the Agile Way. (Learn more at gettingresults.com.) The author describes how to use agile techniques to get non-development projects done and make progress on longer term goals.
I’m not affiliated with the book – just a happy purchaser.
Look into an Agile methodology called Scrum. You’ll never want to use another development lifecycle again!
As a software engineer, longtime agile practitioner, freelancer, and writer, I thought I’d make a few comments.
First of all: it’s “daily stand-up” or “stand-up”. Nobody calls them “standing room only meetings”. Some SCRUM shops call it “the daily scrum”.
No discussion of stand-up meetings is complete without mentioning the typical format. Different groups customize it, of course, but the classic template is three questions:
1. What did you do yesterday?
2. What are you doing today?
3. What is standing in your way?
Notably, while anyone is welcome typically only the people in core roles are allowed to talk. This is *not* a time for the “big boss” to remind everyone how tight the schedule is.
Moving on…
You may want to do some more reading before trying to draw lessons from agile methodologies, because it sounds kind of like you’ve missed the core of it. All software methods break jobs down into small tasks. The essential features of an Agile process, and what makes it unique, is that it is *iterative*. The work is broken down, not into a series of steps, but into “time-boxed” intervals: a month, two weeks, a week, a day, depending on the size of the project and the preferences of the people involved. At the beginning of every iteration, the stakeholders (the people to whom the outcome is important, e.g. the client) look at what has been done so far and decide on what is the *most important* thing, or list of things, to do next which can be accomplished in a single iteration. The team only commits to as much work as they feel they can realistically accomplish in the next iteration.
At the end of every iteration, the team delivers a *working* product. It may not be feature-complete. At the beginning, it may just be a skeleton. But it is something the client can see and comment on. In stark contrast to so-called “waterfall” methods, where there is a series of steps starting with requirements, then design, then implementation, then integration, the team strives to deliver a working, integrated product at the end of every iteration. Then the client looks at what they have, as well as at any changes to the requirements on their end, and decides what is the next most important feature. Or, they can look at it and decide that it is now “good enough”. Once the client decides it is good enough, the project is finished. Rather than having nothing to show them until the deadline, they get to see successively more fleshed-out iterations of the product until they are happy with what they see.
The series of steps you outline above is much closer to “waterfall” than to Agile. And an Agile practitioner would not say “Welcome challenging requirements, even on deadline.”. Agile is about delivering something workable from day one and then successively better, not about having something complete by a deadline.
An agile group will typically do a “retrospective” at the end of a project, but a group that only iterates at the “whole project” scope would never be considered agile. Agile is about evaluating and adjusting weekly, daily—sometimes hourly.
Speaking with my writer hat on, I’m not sure how amenable agile project management is to writing projects. But if I were to try to come up with an agile process for writing, it might look something like this:
* Decide on the iteration length. For a small project, it might just be one day.
* At the end of the first day, have a bullet point outline. Show it to the client.
* On successive days, flesh out *all* the points in the outline little by litle. Each day, make the current product available for feedback. Address feedback from the client, editor, etc. in the next iteration.
* When the client feels the article is “good enough”, it’s done.
Again, I’m not sure how applicable this is to writing. Then again, it’s not that far different from how I write books. Once I have a rough draft I open them up for beta buyers, and send out successively more refined drafts to the beta buyers until I and they feel like it’s “good enough”.
I hope this feedback is helpful to you
It is essential to use the agile approach for freelance projects to move them on a quality track and meet the needs of the customers. I like the way you have presented your ideas on the agile method for software development and for freelancing.
Many freelance know about Agile because many worked before in a company … but applying scrum for 1 man team is not really sustainable …
To Avdi, Jameos and to a smaller extent Kreativ:
Your providing specific operational details of Agile is very misplaced in this thread.
The author simply quoted the “Agile Manifesto” and spoke to one, just ONE specific detail of Agile, the “daily stand-up” to support her position.
Agile is being used here as a metaphor and model for freelancing. Not as a software methodology.
Agile has a reputation for being a bit of a cult. Blindness to context is one key note of a cult.
Bored: It sounds like you didn’t read the whole article, because the author went on to draw a number of lessons from the Agile Manifesto. She only mentioned stand-ups in the introduction.
It seems relevant to the article to point out that essence of Agile is iteration and constant adjustment, not breaking things into sequential steps.
My partner is a computer programmer and I am a technical writer. I had never thought to adapt his profession’s style to my work. Let me see if I can do this. Bear with me that this comment is long.
Most of my paid work is grant writing. And that means I have a client and an “investor”. The investor or funder and the ultimate arbiter of whether a proposal wins or loses. My client is an organization who, at the get-go, usually has poor chances of success. But that is totally normal and expected, although many clients do not perceive the competition. They see themselves as the best.
What I have to do is engage the client in doing work that they may not expect. They have to think big, gather internal data, and sometimes correct problems in their structure. To get that work done, I often have to serve as an extra brain and consult with them. I think daily stand-ups would be great during this part of the process. But I can’t imagine ever convincing non-profit people to stand. They are used to pizza, dessert, and long chit chat at meetings.
Working with the funder or investor is easy. They sets the rules, which are often overcomplicated. But the funder writes an RFP which pretty much gives the “answers to the test.” While I get paid by the client, the funder pays the client. I answer first and foremost to the funder because that is exactly what the client wants.
The “sprint” concept (or short-term projects) is exactly how I do my work now. A grant proposal has 4 or 5 sub-projects. And I am racing against the clock to make the most excellent product on deadline.
At the end of the project, which usually lasts 2-6 weeks, I am exhausted. I definitely need to do evaluation and assessment, but I have no discipline to do it. But this what I think I should measure:
-Communication with client (was it efficient?)
-Client satisfaction and sense that learned something
-If the client wins the funding, do they understand the proposal?
-Use of technology (were some of my processes wasteful?)
-Did they win funding? (what was the score on their proposal)
-Did I feel supported and properly compensated?
Thank you for a thought provoking article, which motivated me to do self-assessment. I’m not an Agile shop, but hopefully not one averse to learning.
While the post is great, your outline at a project misses the main point of agile development, which is to have a working version as early as possible, and iterate it into a…
Wait a minute, I just read what Avdi Grimm wrote and mine, while more succinct, wouldn’t be as good.
So I second what Avdi said. Your project, done ‘agile style’ would involve early versions with lots of placeholders (for things like photos), to be filled in as a process.