Tradeoff between clear objectives and change

The agile development approach is based on the observation that requirements generally change during a project. But this does not mean you have to give up on clear objectives, it simply means your objectives should not be based primarily on your initial requirements scope. This still leaves many objectives such as meeting important time lines and not going over budget that have to be clearly set and vigoroulsy monitored.

If you include requirements, then use high level features that have to be in the final delivery as objectives. This allows to shift scope between features based on their priority as new requirements are guaranteed to surface.

Choose your supplier wisely

There are three blog posts about finding a supplier for developing our own software. Our decision process included in order of importance (high to low): Talk to the whole supplier team, do you get along?, talk to references, use behavioural interviewing (act as if you’re hiring for your company), certifications, supplier website, past work, profiles on freelance market places, reviews posted on the freelance market places.

Other important considerations: Does your project management process match?, Don’t be dazzled by software development language.

From the blog
Choosing a supplier: looking at the available information (Part I)
Choosing a supplier: Talk to them (Part II)
Choosing a supplier: Other considerations (Part III)

Say no to low bidders and fixed prices

There are companies that are low-balling, meaning they try to lure you in with a low price and then charge you for every bit extra. These are the companies that give outsourcing a bad name.

Fixed price engagement on the other hand will most likely disappoint you if you don’t have at least some money to spend on change requests. Because new requirements are guaranteed to rear their ugly head, fixed prices never stay fixed unless you settle for less than what you really want based on the information available to you at a later stage of the project. Going through a test iteration (see tip 5) will give you a better understanding what the project will ultimately cost as you now have a handle on how much functionality you get over a set time with a limited amount of resources.

From the blog
The project bids are in: A word about low-balling

Match your technical ability on the supplier side and/or get a techie on board

Our man on the other side was an excellent and highly technical and capable lead developer. Our own technical lead was able to talk on the same level with him and with that they could quickly and easily exchange ideas and concerns.

If you are less technical, then you have to make sure that your counterpart can tell you his ideas/concerns at your level and has the ability to understand yours and translate them to the involved developers.

If in doubt or you really are non-technical then we would highly recommend to hire or contract somebody who can manage such a project for you, otherwise there will be another bad outsourcing story.

Risk Mitigation: Start with just one iteration/sprint

Everybody will tell you that they are agile. So if you are otherwise happy with the supplier then make awarding the project dependent on a successful iteration/sprint at which end working software has to be delivered to you. Success criteria should include passing all previously defined acceptance tests and delivery within agreed timeline among other criteria that are important to you and your company.

Put in a good amount of complicated and high priority requirements to test their abilities. If you can afford it, do this with more than one supplier. After analysing the team’s performance and the delivered code you should be able to understand whether you will can meet your objectives with this team. Abandon if in doubt and try again with another crowd, you might even be able to reuse the code.

Include acceptance tests at the start, automate them and use them as the delivery benchmark

When you are gathering your requirements always ask yourself how you can test its functionality and make abolutely sure that it works as it should. Note them down as testcases and share them with the developers as they include vital information for them. A good set of testcases complements the requirements definition of what a specific aspect of software should do with how it should react when things are not going right.

Testcases for iteration 1 should also pass in iteration X, therefore request the supplier to include test automation in their proposal. Make acceptance of any delivery, be it an iteration or the endproduct, dependent on all testcases passing which has to be verified either by you or a third party.

From the blog
Acceptance Test Driven Development and the cost of (not) testing

End User <=> Developer communication is crucial

Another highly important aspect of agile development is direct communication between the end user and the developer to create a shared understanding of the requirements. If this is impossible, then use role modeling yourself to create your requirements and share this information with the developers.

From the blog
Gathering agile requirements for our service

Engage the suppliers creativity: Make your projects theirs

This might sound a bit esoteric, but makes sense from a motivational stand point. There are two apparent motivational goals for a developer: 1. Be fast (so your boss loves you), 2. Be really good at what you do (so your peers admire you). Many developers strive for peer validation as this is more appealing and lasting (the bosses love is often transient in nature). This is also a key driver of the open source community.

If you are working with an experienced agile supplier, then you will most likely be faced with an interested and creative bunch of developers. By listening to and including their ideas and recommendations where appropriate you can align your goal with theirs, but you have to aknowldege individual contribution in front of the team.

Never forget that they have worked on similar projects before and gathered very valuable experience that might create recommendations not alway obvious to you at the start. If you have in-house developers and external developers working together in a team then spread interesting requirements somehow evenly among all developers if the experience profile allows that.

Keep iterations/sprints short

There are two main reasons for that:

First of all this is again about risk mitigation. After every iteration/sprint you have the opportunity to verify that the delivered software is according to your requirements/specifications. This gives you the opportunity to make adjustments and steer the project in the right direction if necessary.

Secondly it means that you will never lose sight of the project as there will be constant work from iteration/sprint planning, communication during the iterartion/sprint and finally testing of the delivery. Never allow it to become just another project!

Choose your communication wisely and create a protocol to follow.

The lines of communication should always stay open but be used wisely. It worked best for us to use a specific window for direct talks and calls, at all other times we used chat or email. Because software development is a cerebral activity, interruptions can throw a developer off quite easily.

Chat was used if immediate questions regarding requirements came up or when someone got stuck. This proved beneficial as you can keep the conversation and add it to your requirements as a comment. Also exchanging code snippets is easy. Email was more used for larger not immediate inquiries.

Unless you are talking about a collaborative workshop, stay away from all team meetings especially if they are not face to face (everybody will be surfing the web except you and the person talking).

There is always the question whether you need to meet the other party: we have not yet met them in person, but we can certainly see that this can be very beneficial to the relationship and are planning to do so in the future.

Say NO to spreadsheet management and duplication

It goes up to eleven? We did not want to pollute the top 10 list with what can be conceived as pretty obvious marketing for our products. Therefore we disclose that we offer a solution quite similar to what we are advocating here.

Managing by spreadsheet does work, but it is certainly not efficient for teams larger than 2 (some would even say one). So we advocate the use of a online collaborative software development platform to manage requirements and issues from one central point accessible by the whole team. The team members can then individually manage and update their assigned work items.

We also advocate that you reuse the suppliers proposal information, because more often than not it is only dug out in a dispute. We reused the requirements estimates and priorities assigned by the supplier using the proposal wizard to plan the next iterations. This laborious information was entered only once and was then used throughout the workflow, no messing around with spreadsheet versions and sending emails to everyone after every change and mistake.