Before diving in to advocate Agile software development, let’s review a traditional method of project management unwittingly requested by most of Atlas’ customers – Waterfall.

Waterfall as an approach to project management isn’t unique in the world of software development; the Waterfall methodology was established in the 50′s and is used successfully across a range of industries including the military, space development and health care.  Such industries are tightly controlled, regulated environments where decisions are made by experts and people’s lives depend on decisions being right first time.  There isn’t a great deal of “Whoops, that didn’t work – hide the dead bodies and let’s try this another way”.

This diagram provides an excellent visual of a typical Waterfall project.  Notice that it’s impossible to return to the start once implementation begins, and herein lies the ultimate problem with waterfall.  The majority of the application development projects undertaken in 2012 will be started, and funded, by people who do not understand the complexities involved in writing software and do not know all of their requirements upfront.  No matter how many software gathering techniques we  use to extract software requirements, if the product owner doesn’t know what they don’t know, they cannot provide the correct information.  This is not their fault, it’s just a fact.

So let’s imagine that the software development team ignores the above issues because the customer is waving a big fat cheque book at them.  They gather requirements as best they can and hurl themselves down the waterfall using a functional specification the size of a bible as a floating device.  The customer is stood by the waterfall watching and she’s hyped.  She’s positive that between them they’ve nailed down all the requirements and then BOOM, they hit the bottom of the waterfall and begin to drown.  Turns out the functional specification had holes in it, and no amount of paddling is going to help.  Furthermore the customer has seen a preview of the application and they have a bunch of changes they wish to make.

With the pressure of a fixed deadline, and fixed budget too, the development team now find themselves having to paddle harder to meet the deadline.  They produce a sub-optimal application that exactly meets the customer’s specification but could have been so much better if only a more iterative approach had been taken.

So agile, that’s the way forward right?  Well agile is equally as dangerous if not carried out properly, and certainly isn’t a panacea to all of the problems outlined here. To work properly agile still requires an overall plan, and plans for each iteration must still be laid down before development begins.  An agile development methodology does ensure that software development is a collaboration effort and shares the risk across both parties more evenly.  In other words, the software development team may still hurl themselves down the river but in this instance the customer is in the boat helping to paddle.

We transitioned the majority of our projects from waterfall to agile in 2011 and I intend to ensure that where possible we use agile going forward.  I’ll go in to more detail about how we handle planning for agile in a separate blog post but in the meantime here’s a number of agile tips and tricks we’ve used to ensure that all of our projects regardless of size and risk stand the best chance of being delivered on time and on budget:

1. If we’re approached by a customer who wishes to create an application and this is their first web application or they’re entering a new industry I strongly recommend that they create a minimum viable product first.  Trying to create an application with all manner of bells and whistles is unnecessarily expensive, and usually a disaster in the making.
2. On occasion I recommend the creation of a proof of concept.  This is especially useful if one or more areas of the overall application requirement are high risk due to technical complexity or reliance on a third party system.
3. On from point 2; if we do create a proof of concept we show it to as many people as humanly possible before continuing.  If the application is internal, show it to your staff.  If you’re looking to sell the application, show it to as many of your potential customers as possible before proceeding.  Yes this takes time, yes this feel onerous, but it’s less expensive to discover early on that you’re heading down the wrong path.
4. If a proof of concept is overkill, I always recommend that we create wireframes (Balsamiq is our tool of choice unless a HTML prototype makes more sense).  Even the most simple wireframes will ignite a product owner’s imagination and make them think about detail they might previously have overlooked.  Given that a picture says a 1000 words I make sure that wireframes form the part of our iteration plans as they are difficult to misinterpret and therefore minimise ambiguity.
5. We use our client portal to aid transparency.  In particular I make sure that customers can track what we’re working on as part of the current iteration.  We add any potential  issues to the portal for discussion as soon as we encounter them rather than waiting for the next meeting.
6. Speaking of meetings – we insist that the key product stakeholders attend all end of sprint meetings to provide feedback.  We’re so adamant about this point that we include this requirement in our agile development contract.
7. We won’t ever get bogged down in onerous contractual discussions.  Software development is a collaborative effort with shared risks and our software development agreement reflects this approach.  Rather than discussing contracts in detail I’d much rather focus on getting your application built.

With or without agile the above techniques have saved us 1000′s hours of wasted development.  Please feel free to comment below with any other approaches you’ve used to keep your project afloat.

Sounds simple doesn’t it?  And for the most part it really is, so long as you get your approach to gathering software requirements right from the outset.  For example, attempting to gather requirements for a £1m project to create a CRM for a multinational company probably shouldn’t be undertaken using Skype, a notepad and a couple of calls to three of the most shouty end users.

So today we’re going to talk about the options available for gathering software requirements, when you might decide to use one (or more of them) and any advantages/disadvantages you should be aware of.

Current system documentation

It’s entirely possible that the stakeholder’s current application has been beautifully documented that lovingly describes in detail how the application works.  This may include architecture diagrams, user guides, and if you’re really lucky a functional specification.

These documents can provide an invaluable, impartial view of the current system that you can quickly and easily copy and paste in to a new specification if you see fit. However, all that glitters is definitely not gold and you should sanity check any functionality you decide to include in your specification to make sure that the current software actually does what the manuals say it should.

Workshops

Workshops are great fun.  They involve asking the primary stakeholders in to a boardroom scenario where you’ll arm them with flipcharts and magic markers in an attempt to extract the most information out of the stakeholders in the shortest timescale possible.

The upside of workshops is that with a lot of pre-planning before the workshop and  6 – 10 knowledgeable people (the sweet spot, any more than 10 people is chaotic) it’s possible to create detailed and immediately useful specifications in a matter of hours or days.  The key to a successful workshop is a realistic plan for each and every hour dedicated to the workshop.  Be sure to build in a buffer so that in the event of an overrun, which will inevitably happen, you don’t run out of time.  You’ll want to have at least one techie there, ideally your best problem solver who can very quickly take a problem and present a handful of possible technical solutions for the stakeholders to choose from.

The downside to the workshop approach is that it is very time consuming and should you make the mistake of inviting even one bad cookie to the event you could find yourself chasing your tail or worse still refereeing two or more arguing stake holders. Definitely not what you want.

Interviews/Meetings

This is a more traditional approach to gathering requirements.  In groups or one-to-one with individual stakeholders an interview gives the developer or business analyst the opportunity to understand requirements using a free form approach.  They then go away and use their interview notes in order to flesh out a functional specification.

This approach is similar to workshops in that it does require planning. In an ideal world you would use a template for every single interview to ensure that the same questions are asked consistently. Furthermore it’s useful to have a schedule for the interviews, and whatever you do don’t miss out a key member of staff.

Scheduling and managing interviews for numerous individuals and groups is time consuming.  You’ll find that stakeholders when questioned on their own may give a different answer when questioned as part of a group so look out for this gotcha.

Questionnaires

Need to engage with a large number of disparate people but you don’t require detailed input from each of them?  You might benefit from a questionnaire approach to gathering requirements. You’re best off using one of the many free survey applications as opposed to sending out dead tree questionnaires if you can help it.  If you’re clever you can create lots of cool graphs from the feedback you receive which your stakeholders will prefer over reams of text.

Questionnaires are definitely not a shortcut, and should not be treated like one. You’ll need to take a hard line with the people you send questionnaires to and set a deadline for the return of information.  Harsh punishments should be dolled out to anybody who fails to return their questionnaire on time. Turning this on its head, we have actually offered rewards for the best questionnaire response in the past. Oh, and be sure to tell your questionnaire recipients how much you value their input – the last thing you want is for them to feel like an extra in your splendid play.

Prototyping

While it is rather lovely to write thousands of words describing in minute detail exactly how every element of your login screen will work, a picture – or a prototype in this case, really does say a thousand words.  There is nothing as powerful a prototype to bring a stakeholder’s ideas to life and the results really are quite astounding.

A prototype can be as simple as some HTML mock ups that allow a stakeholder to click through their screens. Plenty of applications exist for the purpose of creating HTML mockups. Alternatively, if the stakeholders don’t mind spending some of their budget it’s always a good idea to create a proof of concept that you can iterate to the full solution from. Technically this shouldn’t cost the stakeholders more than building the entire application if you box clever about it.

The only downside that we can think of is the cost associated with the creation of a proof of concept. However the potential lost investment in not having a proof of concept if something is technically challenging or needs to be seen to be believed against the small investment in the proof of concept is a no-brainer most of the time.

So in summary…

You will often find yourself having to use one or more of the above approaches in order to completely nail down a solution for a customer. The approach used really does depend on the stakeholders involved and the size and type of project being undertaken.  There are dozens of applications both SaaS and old school (Microsoft Windows) based that will help you to manage the process of gathering requirements, and these are certainly worth reviewing if you feel this would assist you or you need to collaborate with people who are in remote locations.

However you gather requirements, make sure you get it right and don’t commit to writing a single line of code until all stakeholders agree that the requirements are documented in full.

Good luck!  And if you’re stuck for any reason you can always give us a call.

The concept is simple: at the beginning of November, guys (henceforth known as Mo Bros) register with Movember, shave clean and then spend the rest of the month growing a moustache of any shape or size.  Then they cajole their friends, families and colleagues into sponsoring them for spending the entire month looking like an east London try-hard.

We’re proud to be part of the Movember cause this coming month, and we hope that you’ll support us for our efforts.  Our team will consist of Mo Bros and Mo Sisters, our Mo sisters will not wax for all of November – nice.  While it’s true that the majority of our Mo Bros lack the facial hair to pull off anything resembling a moustache, this is one of those few occasions where effort and not the end result is rewarded.  So please head over to our page and make a donation.  Atlas has already donated £100 towards this amazing cause and we hope to raise at least £500.

http://uk.movember.com/mospace/1493462/

Those of you who know us will already be aware that we do lots of work with the apprenticeship scheme.  Simon sits on the Apprenticeship Ambassadors Network and Atlas has won two awards for its proactive involvement in apprenticeships.

We’ve also been sent a nice plaque to add to our collection, and this logo:

What we’re most proud of is the software developer apprenticeship framework we worked with Microsoft and e-Skills in order to design.  We were then one of the first handful of companies in the UK to take on an apprentice focused solely on the development of software. For us this was a huge win. We had identified a missing apprenticeship as an opportunity and rather than just moaning about it to our peers – we had the opportunity to fix it and we did!

We feel there is a lack of computer programmer talent here in the UK, and we’ve taken real steps to fix this. This will of course benefit not just us but 100′s of other companies across the UK and therefore the software industry as a whole. Put simply, we’re quite proud of the work we’re doing.

Anyway, that’s enough high fiving for now.  We have work to be getting on with and I won’t rest until apprenticeships are regarded as equal in authority to that of “traditional” education paths promoted by most colleges and universities.  We’ve lots of work left to do.

First up is a new WordPress website for our friend Rich Simmons over at Art is the Cure.  Rich needed the ability to pull content from the wide range of platforms he uses to spread the word about the AITC movement.  We decided to take advantage of WordPress for this, applying a really cool custom skin to the site to compliment the vast amount of information we pull in using a range of off the shelf and custom plugins. Check it out at http://www.artisthecure.com.

Next up is Educating Together.  Educating Together is a brand new start up offering the highest quality resources and advice to parents to ensure that their children flourish at school.  The site was a custom designed bespoke build using the latest Microsoft technologies including ASP.Net 4.0 MVC with a SQL 2008 database.  We’ve also used jQuery and Flash to provide a neat and easy to navigate user experience.  If you have children in school we highly recommend that you check it out at https://www.educatingtogether.co.uk/.

Check back soon for more updates on the amazing new projects we’re currently working on…

But why?  Nobody seems to question this.  This legal overhead is largely a western approach to doing business.  Businessmen in the Far East for example are much less likely to turn to their solicitor in times of legal conflict.  Rather in the event that you don’t do what you promised, your customer will simply never do business with you or anybody associated with you. The punishment being that the shame you will feel will far outweigh the punishment a legal battle would bring.

This results in an excessive focus on fulfilling the contract to the last word than on what it is that you set out to achieve. Anything that goes beyond what’s in the contract, however useful it may be to achieving the ultimate goal, is almost always never done.  This is especially true in the world of software development where three little words – “change of scope” – will strike fear in to even the most hardened project manager.

It also hinders creativity, as people are narrowly focused on what’s defined in the contract. Companies try to limit their scope to things they are confident of achieving. Contracts give little room to set ambitious targets or look at unconventional approaches to solving a problem.

Even lawyers see the risks of complete contracts.  If you read the Dean of Duke’s Law School’s honour code you would expect a detailed contract written by solicitors for solicitors.  Not so – instead you will find a simple statement of fact: “If a student does anything the faculty doesn’t approve of, the student won’t be allowed to take the bar exam.”  This is in essence a handshake agreement!

I look forward to the day when contracts are resigned to a thing of the past.  It’s clear that complete contracts are inevitably imperfect but I understand a handshake agreement is still too bold a step for most.  Therefore rather than attempting to create complete contracts that mutates goodwill into legal trickery how about we work to incomplete contracts that rest on the understanding we share of appropriate and inappropriate behaviour?

P.S. If you want to watch a really funny and insightful video about doing business while we’re still in this crazy agreement driven world – check out “F*ck you, pay me”, a http://vimeo.com/22053820 from Mike Monteiro of http://www.muledesign.com/ fame.

Twitter launched in 2006 and on the 21st March 2011 turned five years old.  In a relatively short span of four years has taken the world by storm. You would be hard pressed to find any celebrity or famous brand name that is not taking advantage of this service. While other social networking sites have been busy trying to get everything from chatting to online stores under their roof, Twitter has done the complete opposite.

At first glance the usefulness of Twitter might escape some people. Twitter allows you to broadcast 140 character messages to all the people that want to get your “tweets”. However if used properly those 140 characters can become one of the most powerful marketing tools in your arsenal.

But the big question remains, “How can I use Twitter for maximum effect?” Follow a few basic rules and over time you will find that by simply “tweeting” you can drum up demand or buzz in the market for your company or product.

• Keep a simple name: This is just plain common sense the simpler the name the more likely people are to remember it and in turn follow. Instead of being creative and replacing numbers with digits and using too many underscores differentiate words by using capital letters. So instead of Bobs_Gr3at_and_tasty_seaf00d_palace use BobsSeafoodPalace
• Keep a personal touch instead of developing a corporate identity. People feel more comfortable when they feel a message is coming from a real person and not some entity
• Use the direct message service on Twitter for your customers making them feel special and valued. Direct messages can only be seen by the recipient and can help promote special offers
• Use Twitter as a way to not only generate revenue but as a way to impart knowledge to your client base. “Tweet” about topics that you feel your customers will find interesting. This will help them look at you as a trusted advisor and not just a company. By providing valuable content you increase the chances of your customers “retweeting” what you said to their followers which exposes you to many more potential clients
• Start following your clients or people you know on Twitter. Many people will reciprocate and start to follow you which increases your potential client base.

There are a number of other applications which you can use to increase your effectiveness on Twitter. TweetDeck is an application which can speed up the Tweeting process. It’s a desktop application which allows you to easily manage your followers and tweet right from your desktop. TweetBeep allows you to setup keywords and be alerted when someone tweets about them.

Be warned, get too carried away and Twitter can start to hurt more than help.

• Don’t tweet a hundred times an hour, no one likes to be spammed
• Don’t only talk about your own company or products, show people value or they will feel like your tweets are more like ads and less like valuable pieces of information
• Don’t get stuck in a rut and keep tweeting the same thing.

Keep your content fresh and your followers engaged and you’re sure to find value in this pint-sized service!

People who work with software development on a daily basis know that the smallest error at the design stage or oversight during testing can lead to major problems. By employing a few simple checks and balances you can easily ensure your projects are delivered on time.

Management Leads, Developers Follow

Many times when a project fails or is not on schedule the blame automatically falls on the software development team. While the development team might be the reason for failure sometimes, more often than not the project fails due to poor management. After all the development team has its head down and coding, it is up to management to figure out if the project is heading towards any icebergs. Make sure you have people who know how to manage software development projects, look out for potential problems and can accurately gauge the time required for deliverables.

Good Team = Good Code

It’s a fairly simple concept, but easy enough to ignore. There might be the odd success story of a mediocre team making great code however the rule of thumb suggests that the better your team the better your end product. Work with your team to figure out the strengths and weaknesses of the players, see what they are capable of and how much they can push their limits. Once you know what your team is capable of you are able to plan your projects more effectively.

Look to the Future

With today’s fast paced lifestyles most people cannot look beyond the task they have to complete today, let alone plan and build a system for the next 10 years. Many development teams are also the same way, laboring away at their computers for days on end to meet the next milestone or finish the next deliverable. Whilst this method helps to keep you on track for the short run, it makes you oblivious to the needs of the long run. Hindsight is 20/20 and this applies to software as well. Ask any developer, and they will tell you that looking back they would have built the system a little differently, left in provisions for automatic testing or even used a completely different architecture. The next time you are writing line after line of code, take a step back and look at the bigger picture. Don’t think about what has to be compiled before 9AM, think about how the system will be used 9 years from now.

Problem Solving is not Reviewing

Many people will use the terms problem solving or bug fixing interchangeably with reviewing, yet they are not the same thing. Many times the development team will have a review meeting where potential problems or bugs are discussed. In most meetings while reviewing the bugs in-depth conversations can occur as to how to deal with the bug or problem. While the conversations are a crucial part of the development process, review meetings are not the place for them. They take up most of the meeting time and leave a number of issues un-discussed. Ensure that your review meetings stay on track and all issues are discussed or some might come back to haunt you. Schedule separate time with only the people concerned as to how to fix the bugs or problems.

Reviews Take Time

Many project plans will just state reviews as milestones, which essentially means they require no time. This is not the case in the real world. Make sure you plan enough time to review, and solve all the problems that come up in the review. If you fail to do this chances are that your project is going to get behind schedule.

Growing a company organically, as is the case with Atlas, left little room for mod-cons and nice-to-haves.  We started in a shed with Argos furniture (classy).  Our PCs and servers were hacked together from the remains of salvaged hardware, and an old 100MBit hub formed the backbone of our network.  From here we grew and moved into a real office but working on a shoestring budget we never had the cash to provide our team with a developer friendly working environment a la Joel on Software’s immortal words.

In others words we made do, this was a terrible idea and definitely stunted our growth and here’s why:

1) Developers frequently perform processor intensive tasks usually when building their projects.  While they’re waiting for their project to build they’re literally unable to do anything else and their minds will wander.  By the time the build is complete they have lost their train of thought.  Let’s say at a modest estimate they build 10 times a day and each build takes 3 minutes on crap hardware – that’s 130 hours lost each year.  Four weeks =  one month’s salary!  You don’t need to be an expert to work out that’s expensive on a developer’s average salary.

The fix: Pretty obvious really – buy new top of the range computers.  Currently this involves computers with 8Gb of Memory, core i7 processors, SSD hard drives (not just any old solid state drives I’ll have you know), dual widescreen monitors and gigabit ethernet throughout the building.

2)  Computer downtime is equally expensive.  Computers hacked together out of milk cartons and various left overs are not only slow but they often break.  When they do break you’re screwed.  Finding spare parts can take a day or two, then you’ve got to stop what you’re doing to fix the employee’s machine if they can’t do it.  All the time they’ve stopped writing code.

The fix: All of our computers are purchased with an extended warranty from our supplier.  The warranty covers accidental damage in addition to the usual wear and tear.  Crucially the warranty is next working day so the maximum amount of developer time we’ll lose is just one working day.  The warranty covers each new machine for two years, which ties in with the lifespan of each computer as we upgrade every two years.

In addition to all of the above we have also purchased a backup development machine which also stands in as a test machine when not in use.

3) In the last office the servers were in the development room.  Servers are noisy and hot and a constant distraction.  Furthermore to get to the toilets it was necessary to walk through both the developer and meeting room.  Meetings are often noisy and sometimes lengthy affairs as the guys and gals here are passionate about their ideas.  We couldn’t have customers attend our offices without interrupting the team for as long as the customers were there, it wasn’t ideal.

The fix: We built a custom board room completely separate from the rest of the office.  A meeting can take place in the new board room all day without impacting any other rooms.

4) Heat produced by computer equipment is a fact of life in IT.  However we hadn’t taken this into consideration when cramming the developers and equipment into one room.  The developer room was quite warm in the winter but come summer it was unbearable.

5) The overall quality of the environment in the previous office, both indoors and out, was poor to say the least.  I once described it to a friend as like working in your Nan’s front room.  The walls were clad in 1970′s woodchip wallpaper which had been painted over numerous times. The carpet was naff, the fixtures and fittings were dull and overall the place had what someone more spiritual than me would call a bad energy.  Being there sucked the energy out of me and the team. 

The fix: Decor makes all the difference and our new offices are light and spacious. We took the opportunity to specify absolutely everything about the environment we spend the majority of our waking time in and the results have been fantastic.  It also doesn’t hurt that the offices are located with parkland opposite and quiet neighbours  Our customised offices are a joy to work in and while it’s difficult to measure overall productivity and make a bold claim that it has increased, the vibe here at Atlas is much happier.  Happy developers = productive developers.

And now, for the photos…

In recent years inboxes have ballooned out of control, and as more and more collaboration and conversations go online, we have information flying in from all directions at a near non-stop pace. So how do we filter the important stuff and let the irrelevant slide by? How do we prioritize our inbox?

Here are some simple strategies for minimizing email clutter, ensuring the important messages get read and acted upon.

1. Stop living in your inbox

The first thing to realize is that for many people email is just a medium of communication and not the place of application where they need to take action. Set a time for yourself – 10 minutes, half an hour, an hour or whatever best fits your needs. Only check your email during this time, and don’t just check email but process it. That means give yourself a defined set of actions that must immediately be applied to the email.

By checking email at longer intervals you will be more likely to “process” it rather than just skim it; thereby completing the tasks required of that message. So go ahead, shut down your email application while you work on more important things, there’s no need for a distraction every few minutes!

2. Create your own ‘set of actions’ for email

These actions will depend on your job or in what context you are using email, but for most people all email actions can be narrowed down to a handful of choices. This makes it much easier to reduce information overload.

Your actions should be simple like: delete, respond, delegate or do. This will allow you to not only check but process your email much faster. Nothing will just linger on, everything will have a place and an action associated with it, and if it does not sit well then you can delete it. Take some time to make your own system or process. It might sound like a time consuming task at first but once you get used to it you will find yourself whizzing through email in a fraction of the time.

3. Use software to compartmentalise email

At first this may sound like a paradox. However, automating your email will save you time in the long run. There are many software packages that you can use to make your email management much simpler. Xobni is an excellent plug-in for Microsoft Outlook. It allows you to automatically build your address book and see recent conversations and files that you have shared with your contacts. This allows you to quickly and easily find the context sensitive information you are looking for without having to dig through a mountain of emails.

Another common habit is to use your inbox as a to-do list. Do yourself a big favor and find some other software or application for this, such as My Life Organized.  Personally I use a combination of Google Tasks on iGoogle and a plain text editor.

Another great tool to use is the flag option on popular email clients such as Lotus Notes or Microsoft Outlook. Emails can be flagged with different priorities and action items can be added to the flag. Each flag can also trigger alarms which ensure that you do not forget about the email.

Checking email is not actual work; but often a necessary part of work. So you may as well simplify, automate or delete it and set yourself free from the biggest technological distraction of today.