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.
A good standard systematizes the routine and humanizes the exception. In other words, rules should make common decisions faster and more consistent, while still leaving room for judgment when the situation does not fit the usual pattern. (e.g. I have a funeral and I know you don't usually grant unpaid leave but I'd like to ask for an exception)
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 can walk out of the same meeting, and have different expectations about the goals of the project. This difference often sets up a project to fail, before work has even started.
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.
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.
The best developers are also extremely good at finding a solution to a problem they don't know.
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.
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.
Acceptance Criteria (from the Product Owner) help to answer the question "How will I know when I'm done with this Product Backlog Item (PBI)?". It defines the exact requirements that must be met for the PBI to be completed. It is the Product Owner's responsibility to ensure that all Acceptance Criteria has been added - otherwise they should not expect that work to be done.
Any time you're building or changing something that users interact with, you should get a UI/UX Test Please from a designer. This ensures your work looks clean, feels intuitive, and aligns with the overall user experience.
It’s not uncommon for critical workflows in projects to become flaky and brittle, and on occasion, this will not be caught until the product hits production. An example of a critical workflow is placing an order on a shopping cart, or adding a timesheet in a time tracking site.
These are workflows that, if errors occur, the product becomes rather useless, and thus needs to be strongly tested.
There is a myriad of options to choose from when storing and sharing documents: SharePoint, or OneDrive/Dropbox/Google Drive, or Microsoft Teams. The best choice is Microsoft Teams because it brings together the best of SharePoint, cloud file storage, real time collaboration and more into a single location.
When you regularly create new releases of an application or new versions of a document, files will inevitably become outdated. Rather than deleting them, put a 'zz' at the front of the filename. These old versions should not be deleted straight away - it is just an unnecessary risk! The zz'd files can remain there until you need more space, then you should delete them.
Recurring tasks are tasks that happen on a regular basis, but not necessarily every day (and therefore potentially easy to forget!). They might be personal tasks, such as changing the oil in your prized Datsun 120Y every six months, or booking a holiday for you and your partner a month before your anniversary. They could be work related tasks, such as updating your profile on the Microsoft Gold Partner website (every three months), running financial reports on a monthly basis, or even watering the office plants every week.