I subscribe to the “No Silver Bullet” opinion on software development.
“At the heart of the argument is the distinction between accidental complexity and essential complexity. Accidental complexity relates to problems that we create on our own and which can be fixed; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things.”
Everyone wants to find a silver bullet (not just in programming, but, for example important today, in things like banking) that makes everything a breeze. It's human nature to believe in these things. Assuming that some magic elixir will be found to make simple solutions for those complex problems is often to ignore the many small improvements that do help. In essence what I propose is a simple and pragmatic Agile approach.
In simple terms Agile software development is the "just makes sense" way to go about programming, doing small bits of work in small teams then running the code quickly to detect problems, then repeating the process again.
The Agile manifest itself can be viewed here -http://agilemanifesto.org/
Up until maybe four years ago, I had a one-dimensional view of "Agile" programming, namely that it was an idiotic marketing scam, a sort of technological virus implanting itself in naive programmers, the kinds of programmers who buy extended warranties and self-help books and who believe doodling on cardboard index cards will suddenly make software development easier.
Since then I've worked on a few projects that used a remote Agile development strategy, with varying results.
The most successful Agile projects I've worked on remotely involved the following.
· Daily VOIP morning scrum style meetings.
· Clear iteration plans
· Automation tools such as continuous integration / build servers.
· Diligent use of project tracking tools
Working in a virtual workplace.
A “virtual workforce" can turn out to be beneficial as everyone is on the same level. These individuals are either lonely and isolated, or pretty happy with their arrangement. We can influence the outcome towards the latter by setting up frequent communication and transparency.
In Agile working, the need for frequent communication is a key ingredient. Routine is also important - regular scrums (meetings) at the same time of day really can help the communication flow.
I know what I personally get out of “working virtually”. I have the quietest, best equipped office of my career. I've got all the tools and reference resources in one place. I control the environment. I have flexibility to work when I'm most productive - and do things that improve my quality of life. I feel this helps me deliver higher quality work than if I were in a cube farm.
In my experience the problems of remote work are often due to lack of communication, both 'face-to-face' and lack of or poor use of project tracking tools. In general it can be harder to communicate with remote workers. If the remote people have strong "remote" communication skills this is probably a non-non-issue. On the upside if we get the process running correctly we can hire the best of the best when we don't have a geographical location restriction.
How do we become Agile?
There are many ways to become Agile. Purists say that you are not really Agile until you do everything in a truly Agile fashion. That might be true but trying to start everything at the same time could be a recipe for disaster.
To make the transition to Agile go smoothly, I believe we should focus on a five principles:
1) Perform daily stand-up-meetings.
2) Use of correct Agile and online collaboration tools
3) Encourage open communication and discussions throughout the entire day.
4) Break stuff down into small manageable chunks and use continuous integration.
5) Develop and strive for clean, well-shaped source code
1. Daily stand-up-meetings or Scrums
Daily stand-up-meetings are as simple as they sound. You gather the team on Skype and everyone takes turns in answering three simple questions:
- What did I work on yesterday?
- What will I work on today?
- Is there is anything that is blocking me?
Each person gets one minute on average (sometimes more, sometimes less), and overall it shouldn’t take more than 10 minutes. That’s it
How does it help?
It helps the team avoid duplication: If Doreen plans to work on a problem that was already solved two months ago by Amir, then you can bet that Amir (or someone else) will tell Doreen before she even starts wasting time.
Clear roadblocks: If someone is blocked by something particular, this is the perfect time to check who could help: “I have been working on bug X, with little progress. Has anyone seen X happening? Let’s chat after the stand-up meeting”.
Detect roadblocks: If John tells the same story for the fifth time in a row, everyone else will realise that he is severely stuck and needs a hand. Catch him right after the meeting and get him some help.
Boost team coherence and commitment: Team coherence and commitment is increased when everyone speaks to everyone else on a regular basis. Especially when you don’t all work in the same room, or when different members of the team work on different aspects of the same project.
Increase project manager accountability: Daily stand-up-meetings even make the project manager more accountable. When your manager comes to ask your status, would you dare ask him his? Probably not. But in a daily stand-up-meeting the manager is reporting his status to everyone else.
Increase team member accountability: Daily stand-up-meetings make each team member more accountable as well. A manager might not notice that David is over-engineering his solution just for the fun of it – but the rest of the team will.
Spread transparency: To the project manager, the project is probably transparent already. But there is immense value in team-wide transparency too. People are not machines, and love knowing what’s happening.
What are the costs and risks?
Admittedly, the daily stand-up-meeting does take time. And some people don’t like speaking in front of others. And at times the meeting can distract people from doing important work. These are all valid points. But we need to compare them to the costs that arise by not having this meeting.
How much work would be lost by double work, or by people not realising they are stuck? How important is staff retention to us – and what better ways of open communication can you get at a price tag this small?
As long as we apply common sense and accept that some people occasionally may miss a meeting, and that others may not be great at speaking (but do attend and listen), there is little to worry about.
A bigger risk is people who like to hear themselves talking. The stand-up meeting is not for story-telling. We need to be strict about the time-limit. Someone needs to have the guts and speak up – in a friendly way, and depending on the individual it may make sense to do this after the meeting, to come across less confronting.
The same applies to discussions. Stand-up meetings are not for discussions. They should encourage discussions, but after the stand-up-meeting, and with just the people who really care. If someone frequently starts discussing what someone else said we take them aside and explain that the discussion is great, but it needs to happen after the meeting.
It will help to nominate one person to become the ‘Stand-up-Champion’ who will make sure that the meeting remains focused and finishes quickly and on-time. This person also makes sure the meeting happens in the first place, so the person should not be too shy to shout and get the meeting started. This role should probably be shared on a round robin basis.
2. Agile and online collaboration tools
One of the central values in Agile is "Individuals and Interactions over Processes and Tools". A great team is without doubt the fundamental key to success on remote (and frankly any) projects. However in at a close second are the tools used to facilitate the project management and development.
Good tools I'd recommend are
3. Encourage open communication
Besides the daily scrum, we should encourage open communication and discussions throughout the entire day. This can often generate new ideas or find a solution to a bug. After all, open communication is the cornerstone of a successful project-speaking on the tasks they did yesterday, the tasks for today, and the problems they have encountered.
I would advocate a Skype room (easy to chat and hop in out of voice) that the whole team is in all day. This could serve also as a “coffee talk" mechanism to replace the sort of chat that is often found around a water cooler or in a smoking room.
4. Break stuff down
Working in remote teams does come with an increased chance of misunderstandings. But by breaking the project down into smaller iterations, misunderstandings and problems can be detected much earlier. With clarification of requirements and immediate code fixing, the project can move forward in a timely manner.
“Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily — leading to multiple integrations per day. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”
Using this practise lets people take a look at what’s been built, and if it functions correctly give it to the testing or management team
5. Clean and Crisp Code
Clean, well-shaped source code can prevent headaches down the project road. Part of the Agile framework includes constant updating and revising of existing code. Ensuring the code is clean, crisp, and commented can minimise the response time tremendously for requirement changes.
At the end of all Agile software development projects, the code has to be handed off to the support team in some manner. Well prepared documentation will make this knowledge transfer easy and cost effective as at some point, the end user will be calling for help and reporting bugs or feature changes.
Other non-trivial matters that I feel need to be addressed in considering an approach is:
1) How do we test, do we have a testing team?
2) Who is the project manager?
3) Who has responsibility for the IT budget?
4) Who has responsibility for the overall technical strategy?
5) Who is the technical team leader?
6) How much access have the developers or development manager to the business and business requirement analysts?
7) How and who reviews code and does technical quality assessment... Is it one individual or is it peer to peer type reviews?
8) Do we have a roadmap for future releases post go live?
9) How secure is our current source code?
10) Is our software logging enough data to help support staff post go live and fulfil any future data reporting requirements we might have?
11) Have we got an adequate back office system or plans to build one that will allow the support team to assist the customer’s queries when the software goes live?
12) Architecture of the servers and server hardware that the software sits on: Have we selected a server vendor? Do we have a backup/ redundancy and disaster recovery plan?
13) Performance and security considerations... Do we get outside help and independent auditing and certification that our software is robust and secure?
14) Daily builds of the software to the staging area how best to do this and who is responsible?
15) Do we use In-house SMS and email services or do we outsource... How do we test the reliability of these services?
16) How often to get everyone together face to face?
17) Have we got the right people in the team?
18) Where are we NOW and how soon can we go live?
What I have outlined is a fairly high level view, but it does illustrate what I feel are the five key practical cornerstones of any approach I would advocate.
How these are implemented in practise is dependent on the health of the project, the state of the current code and the deadlines enforced by the business.
People are often hesitant about change, especially if they have been subjected to frequent random change before that didn’t help. As with every change, I think we should first make the proposal, discuss it with the team and take on their feedback before we actually get started. I feel it’s important that everyone buys into the concepts. In addition the actual practical implementation of these should and must be driven by the people that will actually have to use the process.
I've always thought the biggest silver bullets in any project are the qualities of the people working on the team (not just programmers, everyone involved is important). Smart, experienced people who work by consensus or at least in a trusting hierarchy, able to pick the right tools and technologies for the job, and given the right level of support by management, QA, product and everyone else who contributes to the end result.
When I've worked in places or on teams which were mismatched, poorly lead, used tools incompatible with the team members, had overly complex methodologies, the result was uniformly bad.
There is “No Silver Bullet”. A great motivated team communicating effectively and efficiently is without doubt the fundamental key to success.