If you are a small solo operator or you have a small team working on software development, efficient project management is just as important as it is for larger teams in enterprises. However, does it make sense to implement something as heavy as agile methodology, designed for the big teams, if you are small?

Jason Mundok, co-founder of Elusive Moose, has taken the principles of agile project management and rescaled it for his one-person software development consultancy. He shares how using an agile-like approach keeps his projects on track, saves time and money, and creates happy clients.

Listen now:

Listen on iTunes Listen on Stitcher

Podcast RSS Feed | Download MP3

Jason shares with us:

Like many freelancers, Jason Mundok gained his expertise in software development while working in a large consultant firm, then decided to set off on his own after 15 years of experience. For him, starting his own consultancy was about his desire to try something new, carve out his own niche and work with the people he wanted to work with, and also to have a bit more freedom so he would no longer have to commute an hour and a half one-way.

Jason also enjoys working with small businesses, allowing him to develop personal, one-on-one relationships with his clients.This helped him make the decision to hire temporary subcontractors when he has more work than he can manage alone, but not to hire anyone full time. He consciously asked himself: Do I want to be the one who does the job or do I want to become a business manager? Once you start hiring, you become more of a business manager.

In addition to working on software development projects, Jason also coaches and trains other developers how to adapt agile project management to their small business, which is what we focus on for the rest of the podcast.

The Project Management Problem

The really typical approach to project management, if there is an approach at all, is the waterfall approach. In the waterfall approach, you get all the requirements up front during an intensive 2-week meeting with your clients, hatching out all the details, then going off and working on the project for several weeks or months, then delivering the software.

The problem with this approach is the idea of scope creep. Often what you discuss with the client at the beginning isn't what the client wants at the end. You discover that the client forgot to tell you about a feature they wanted even though they thought they had, or there was misinterpretations about the feature, maybe the feature ends up being more complicated than originally though. Or, maybe something happened on the client end and now they no longer need the project, but actually need something completely different. Or maybe they ran out of money and can't pay you to complete the project so you have to finish prematurely and turn in an incomplete system.

Shift your thinking

The agile methodology is a framework that lets you adapt to changing scope. No matter how detailed you are, you will not be able to get all the requirements up front because you don't know how the future will change things, or because you missed a small thing that adds up to a big thing later.

The basis of agile methodology is the idea of iterations. Instead of disappearing for months, you make the development cycle smaller such as a week or two weeks. This means that you work on 2-3 features in a development cycle that you have discussed in minute detail with the client to know exactly what the client wants. At the end of the two weeks, you have a complete software feature that can run on its own.

Don't think horizontally, think vertically!

Working feature by feature and completing the feature so it is fully functional is vertical thinking. The opposite of vertical thinking is horizontal thinking. In horizontal thinking, the developer makes a rough draft of everything, then does a pass to make it better, then releases as beta, and then does another pass to make it better, then another pass, then another pass, until it is finally done. The software doesn't work until everything is done.

Measure Twice, Cut Once

Iterations and development cycles set up a rigidity in the development process. The golden rule is that you do not work ahead and you never assume anything beyond what has already been communicated by the client.

So you know that one part of the software will use a cool new technology that you have been dying to try out, but it isn't scheduled for a development cycle for another month. So you start working on it now, right? NO! Never assume anything beyond the current development cycle.

But that same rigidity is also setting you up for flexibility to future changes in scope. What if funding for the project dries up? What if the client becomes ill, or the person at the company you are talking to quits? Anything can happen! If you work ahead, you have wasted your time and wasted the client's money. If you stuck to just the features discussed for that development cycle, then you can deliver value to the client because those features will work if you stop now.

Apply Agile

Below is a guide to applying agile concepts to one-person operations or very small teams. A lot of material out there on agile talks about large companies and a lot of it is overkill for a small operation. Here Jason explains how he has adapted agile specifically for his one-person consultancy.

Discovery

The first step in a project is discovery. You need to articulate the needs of the client in a language that the client can understand. You are not talking about the technology you will use to solve problems, you aren't creating a technical document. Instead, you are planing a high level perspective and listing features that will make up the software. You aren't making the final decision about colours or fields, you are figuring out the big picture.

A feature is something that the user expects the software to do automatically or what the user can do with the software (such as compile data and export a pdf). Jason's rule of thumb is that a feature should take about a half day's work to complete. If it takes longer, then break it down. If it takes 15 minutes, then add it in with another feature to make a bigger feature.

Development cycle

Once you have your list of features, it is time to set up a meeting with the client to discuss the details of the first 2-3 features. This can be a long meeting depending on the particular feature. Jason has found 3 features to be the perfect amount to do in a development cycle of 2 weeks. He typically sets aside 10 hours a week for a particular client project so he can spend 20 hours working on and completing the three features.

So you go off for 2 weeks and develop the features fully and completely. This includes quality assurance for the features. If you are a solo operator, it is hard to test your own work, so get someone else to do it. You can hire someone, or work with another developer and swap projects, you check their work and they check yours. You can work with someone in the client's organization to be the QA tester, as long as you emphasize that the purpose of QA is to find errors and it is not the final product. Otherwise the client might freak out. Or, tip of the day, ask your spouse, who may have no development experience, allowing them to fumble around and find all sorts of issues you may not have thought of.

User testing

After about two development cycles, Jason places the features up on a server that only the client can access and lets the client test and review the features. If the client finds anything, then Jason puts the feature back in the cue to be redeveloped. The iteration continues until the client accepts the feature.

All feedback from the reviews get cycled back into the iterations. You go back into the development cycle until all the features are made.

Jason also leaves a few weeks at the end of the project for full user beta testing before the final deployment.

Ready to up your game in project management? Check out the resources section to find Jason's break down of 10 elements of a project management process.

Resources mentioned:

• Breakdown of 10 elements of a project management process: elusivemoose.com/stopthemadness

Find Jason online:

• elusivemoose.com
• Contact Jason directly at: jason@elusivemoose.com

Other Announcements and Notes:

Matt is speaking at Up Conference on October 13 in Vancouver. Check it out!

Want to get the closest thing to a freelancing MBA? Check out Brennan Dunn's Double Your Freelancing Academy and listen to Episode 75 on Freelance Transformation for details and a special offer for FT listeners!