A successful project for a developer might mean something different compared to a project-manager and again quite different for the client.
Since our focus is on the client, a successful project for SSW means every client receives what they are expecting, on time, and for the estimated amount of money.
Project managers define this as On Time, On Scope, and On Budget.
"A successful project is where everyone involved is happy with the final outcome."
What is it that makes a good software development consultancy? What sets one company completely above the other? What makes a project completely successful?
The promise of a successful project is something we all work harder to achieve, but working harder is not the answer. Software companies need to work smarter before, during, and after development, to ensure that the client gets not only what they want, but what they need.
There are real gurus in this field like Joel Spolsky, Kent Beck, Tom DeMarco, and Timothy Lister.
We like what they say, but we also reckon they miss a few things as well - everyone has their own ideas. These are the rules we run by every day. We believe they can help every software developer and team manager to deliver better code and a better end product.
If you need to do something more than once, then there should be a standard for it. At the heart of our philosophy on creating rules and standards is the idea of consistency.
Whenever you're doing something more than once there should be a clear procedure. We call them “standards” or “rules”. That means that there should be lots of standards.
Standards should not be followed blindly. They should always help the critical thinking process, but never replace it. Aim for continual improvement.
There are pros and cons to having standards:
We all want work that feels meaningful. When you focus on Autonomy, Mastery, and Purpose, you create an environment where people love what they do, grow their skills, and feel proud of their contribution. These three pillars not only motivate individuals but also build stronger, happier teams.
Projects often fail because clients think suppliers under-deliver and over-charge. The client and the supplier have different expectations about the goals of the project. This difference of opinion often leads to a project's absolute failure.
If you still need help, visit our Scrum consulting page and book in a consultant.
SSW's Rules to Better Scrum using Azure DevOps allows businesses to address their most important challenges first and respond quickly to change. Our rules advocate software consultants working on-site, or on the phone, so long as there is close consultation with business users, with the goal to become integrated members of the client's team.
The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define a bug.
Just like a car, applications need servicing and tuning every now and then to stay in top condition. They might need alterations to deal with new business problems, or just tuning to increase efficiency.
The first problem with specs is that nobody writes them. Joel Spolsky says:
"Writing specs is like flossing: everyone agrees that it's a good thing, but nobody does it".
Joel Spolsky, The Joel Test: 12 Steps to Better Code
The second problem is that when people do write them, they try and spec the whole project, spending months detailing every Use Case, Business Rule, and Process Flow Diagram. The client spends lots of money and sees no real progress, and the requirements change and the process begins again.
Developers often arrive at client meetings armed with a bunch of impressive software design and architecture documents. When they present these materials to the client, there is often confusion or difficulty in grasping the content. Even worse, walls of text may not be read.
Storyboarding solves this pain by giving the client a visual representation of requirements. This representation helps the client 'feel' the value and prevents miscommunications as the product is developed.
In every industry, Market Research is conducted before a product is developed. Why is IT any different?
Doing Market Research focuses the product on the right set of people so you can satisfy their needs. If you can't connect the dots between the work you do and how it helps the customer, consider investing your time elsewhere. Market Research bridges the gap between the techies and the users.
There are a lot of different CRM solutions on the market. We would never suggest to develop a CRM solution from scratch. Instead pick an existing solution and customize it for your needs.
The best developers are also extremely good at finding a solution to a problem they don't know.
Often you will want to quickly find a file on your computer or local network. With the advancement in built-in search functionality on the latest operating systems this is easy to do and can help you quickly and easily find your local files or network file locations.
For one off-pieces of work, put actual time taken into your done email. It's all about education and accountability - a customer that understands how long things take is better than one who doesn't.
During the course of a Time and Materials projects, a client will often ask for an estimate on a particular piece of work. Of course we duly go about investigating the work to deliver to the client the required estimate.
Scrum may seem complex at first, but it’s simpler than you think. Follow these 8 easy steps to master it.
Tight project teams have a Daily 'Scrum' every day at the same time.
It was once called a 'stand-up meeting' but that discriminates people in wheelchairs.
It is best to have it standing up, so it's short and to the point. No-one wants to stand around waffling.
It is important to give users the ability to check for a new version of the application they are using. And once located it should be easily downloaded and installed. You need:
When you walk into a clothes store to exchange a pair of jeans, you expect to be treated with respect. The sales person should talk to you at your level, deal with your issues, and in a polite and fair way handle your problem. Developers should not expect software users to be treated any differently.
Every error message you put into your products is an opportunity for good service. Users don't want to see "Run-time error. Can't save record with zero length string", instead the User should receive a message that helps them through the situation.
Having a clear "Definition of Done" for your team is critical to your success and quality management in Scrum.
The "Definition of Done" is a structured list of items, which exists to ensure that the team agrees about the quality of work they’re producing. It is defined by the team and serves as a checklist that is used to determine completeness.
Every team is different, but all need to agree on which items are in their "Definition of Done".
In order to ensure the quality of the code you deploy, make sure you don't deploy until you have got your code fully tested and received a "test passed".
There is more than one potential successful path to get work from "In Progress" to "Done" - what's important is that this process is consistent for a project and the whole team follows this process.
The Scrum Definition of Done is a great tool to document and promote this consistency, and the Sprint Retrospective meeting is the perfect opportunity to review and refine this document.