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.
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.
<endIntro />
Everybody knows the 3 essential questions:
1. **What did you do yesterday?**
* Including having Azure DevOps (or other task tracking system) up-to-date
2. **What are you going to do today?**
* Make sure the [task board](/task-board) has your current task "In progress"
3. **Do you have any roadblocks?**
* Explaing issues/impediments
Asking these questions of every team member means no-one can hide and everyone remains connected. Further, you can notice what was promised and what was performed. This enables the team to discover issues quickly and keep abreast of the progress.
The team's successes and failures are shared, and anyone who knows the answer to someone else's problem can help with a solution, **after** the meeting.
<youtubeEmbed url="https://www.youtube.com/embed/YR84qH6d7QE" description="Video: Watch a Daily Scrum at Microsoft (short - 4 min)" />
**Video: [Watch a Daily Scrum at Microsoft (long - 12 min)](https://youtube.com/watch?v=-UUrLxNBK_g)**
> "Great video guys. Remember, it is ok to change Scrum, actually, it is necessary for success. Just adhere to the values of Scrum."
> Stephen Forte (Board member ScrumAlliance.com)
***
Follow these essential tips to improve your Daily Scrum meetings:
## Tip 1: Be prepared for the meeting
Before you join the Daily Scrum, [check the group](/how-to-see-what-is-going-on-in-your-project) to see what your colleagues have been discussing and working on, and check the portal to confirm the meeting time. If you’re joining a new project or re-joining a previous one after some time away, these steps are important to keep yourself up-to-date and abreast of progress.
Then you’ll be able to say to your Scrum Master: “I've had a look at the Teams group. I am ready to join the daily Scrum”.
## Tip 2: Have your Scrum Master to review the Sprint progress at the end
At the end of the Scrum, the Scrum Master should [review the current burn down](/burndown-and-stories-overview-reports-updates) to check on the progress of the team.
<imageEmbed alt="Image" size="large" showBorder={true} figurePrefix="none" figure="A burndown chart in visualstudio.com" src="/uploads/rules/methodology-daily-scrums/burndowntfspreview_1710232021943.png" />
## Tip #3: Keep a schedule of the Daily Scrum times on a wall (+ have a recurring appointment in Outlook)
<emailEmbed
from=""
to="{{ TEAM }}"
cc=""
bcc=""
subject="Daily Scrum – {{ PROJECT NAME }}"
shouldDisplayBody={true}
body={<>
## Hi {{ TEAM NAME }}
As per our conversation, the Daily Scrum will be held each day.
* Project: XXX
* Scrum Master: XXX
* Task board: XXX
<This email was sent as per [Do you do Daily Scrums?](/methodology-daily-scrums)>
</>}
figurePrefix="good"
figure="Schedule a recurring Daily Scrum meeting in Outlook using this template"
/>
<imageEmbed alt="Image" size="large" showBorder={true} figurePrefix="none" figure="Or you can use Microsoft Teams" src="/uploads/rules/methodology-daily-scrums/teams-meeting-daily-scrum.jpg" />
## Tip 4: Keep to the schedule - Same place, same time
If a team member is missing at the beginning of the Daily Scrum, and they are not absent for any other reason, you should [attempt to call them in](https://www.ssw.com.au/rules/admin/#/collections/rule/entries/methodology-daily-scrums/rule) via Microsoft Teams or your preferred communication platform. This should be done at the beginning of the meeting. If they do not respond simply continue the meeting without them. Don't worry. People learn.
If the Scrum Master is not a full-time member of the team (often they are), they should attend every now and then to check the Scrum process is being followed and the Daily Scrums are being used synchronize the team and not a general meeting.
<boxEmbed
style="info"
body={<>
**Notes:**
* The Product Owner (often the client) is **not** required at the stand-up meeting. If they wish to turn up, remind them that they have tape stuck over their mouth, so they don't talk
* If you are not doing an approved Sprint and doing ad-hoc work, then best if the Product Owner (aka client) attends ([see Ad Hoc work](/do-you-know-the-difference-between-ad-hoc-work-and-managed-work))
</>}
figurePrefix="none"
figure=""
/>
## Tip 5: Update tasks before the Daily Scrum
Daily Scrums are more effective when team members arrive when their tasks are already updated.
See [Do you update your tasks before the daily stand-up meeting?](/meeting-do-you-update-your-tasks-before-the-daily-scrum)
## Tip 6: Don't go into detail
Keep your answers short and concise. Do not stray from the 3 main questions. Don't let your Daily Scrum become a general meeting.
Remember to use the ["Parking Lot"](/keep-track-of-a-parking-lot-for-topics), the place for any discussions that stop the Team from answering the 3 main questions. Only interested people stay for the "Parking Lot" to discuss issues after the Daily Scrum.
## Tip 7: Avoid distractions - No phones / no checking email
Technology in the Daily Scrum causes people to lose focus on the goal. The goal is for the team to synchronize by sharing what they are doing. Avoid giving people the opportunity to be distracted easily by forbidding email, SMS and mobile phones from the Daily Scrum.
## Tip 8: Use a task board (even better use an electronic one)
A task board allows people to visualize what the team is talking about.
<imageEmbed alt="Image" size="large" showBorder={true} figurePrefix="none" figure="A Task Board from Azure DevOps" src="/uploads/rules/methodology-daily-scrums/tfspreviewtaskboard_1710232021943.png" />
## Tip 9: Carry a pen and paper
Use a pen and paper to jot things down. A whiteboard is also great for "Parking Lot" topics that arise, to be discussed after the meeting.
## Tip 10: If you have raised impediments, consider contacting the Product Owner
Often the Product Owner won’t be at the Scrum. However, call the Product Owner if you have an impediment (aka roadblock). Communication with the Product Owner is essential and if you haven't touched base with them in the past few days, then do so. A disconnected or absent Product Owner is a sign of dysfunction.
<imageEmbed alt="Image" size="large" showBorder={true} figurePrefix="none" figure="Call the Product Owner if you have an impediment" src="/uploads/rules/methodology-daily-scrums/ProductOwnerTelephone_1710232021942.jpg" />
## Tip 11: Store Daily Scrums in the Teams team so the PO can easily access it
Sometimes, the Product Owner will want to see the Daily Scrum for many teams. Adding them to every meeting would create lots of noise in their calendar. Instead, make the [Teams meetings easy to find](/do-you-make-your-team-meetings-easy-to-find) so they can locate the Daily Scrum for any project via the Teams team.
<imageEmbed alt="Image" size="large" showBorder={true} figurePrefix="bad" figure="Too many Daily Scrum appointments" src="/uploads/rules/methodology-daily-scrums/daily-scrum-bad.png" />
<imageEmbed alt="Image" size="large" showBorder={true} figurePrefix="good" figure="Make Daily Scrums easy to find via the Teams Channel Calendar" src="/uploads/rules/methodology-daily-scrums/daily-scrum-good.png" />
### What to do when you're working for a PO directly
If you don't have a team, and you're doing ad hoc work for a PO directly, it's best to contact him for the Daily Scrum every day if possible, and follow up with an email. This will keep the two of you synchronized.
## Tip 12: Enter Scrum meetings into your timesheets
Once you have completed your stand up, add “S” to your timesheet as per [Rules to Better Timesheets](/rules-to-better-timesheets).
## Tip 13: Send a Daily Scrum email
To prevent misunderstandings or potential disagreements, send your Daily Scrum update via email. This ensures that everyone on your team is aware of your current tasks, even if they were unable to attend the meeting. 😊
<boxEmbed
style="info"
body={<>
**Note:** Always CC the [Bench Masters](/bench-master) in your Daily Scrum email.
</>}
figurePrefix="none"
figure=""
/>
<boxEmbed
style="info"
body={<>
**Note:** Be sure to include the project name in both the subject line and the email content, as people often read the message without referencing the subject.
</>}
figurePrefix="none"
figure=""
/>
<emailEmbed
from=""
to="Bob Northwind"
cc="{{ ANYONE YOU'RE WORKING WITH }}"
bcc=""
subject="{{ YOUR NAME / PROJECT NAME }} - Daily Scrum"
shouldDisplayBody={true}
body={<>
## Hi Bob
Yesterday I worked on {{ PROJECT NAME }}:
* ✅ Done - XXX
* ⏳ In Progress - XXX
* ⬜ PBI - XXX
* ❌ Blocked - XXX
Today I'm working on {{ PROJECT NAME }}:
* ⏳ In Progress - XXX
* ⬜ PBI - XXX
* ⬜ Email - XXX
* ❌ Blocked - XXX
</>}
figurePrefix="good"
figure="Always include what you previously worked on and what you plan on doing today"
/>
## Tip 14: Use IM
After you have sent your email, you can also make it front and center by sending them a ping on IM.
*“Check your email for my Daily Scrum”* or paste in the below (a lightweight version with only what to do).
Use Teams to bridge gaps in geography.
### Focus on the Flow
> "Extend this rule to focus on 'flow of value', not just people. In a continuous flow mindset, the daily standup is less about the people... it's about flow. The team faces the Scrum board and goes ticket by ticket for all the items in the 'work in progress', finding out what is needed to get it to the next stage... respecting work in progress constraints."
> [Joel Semeniuk](http://joelfromcanada.com)
When using email or IM try to be brief and as specific as possible:
<boxEmbed
style="greybox"
body={<>
#### Hi Bob
I have XX days until my next client booking.
I have XX emails in my inbox.
Yesterday I was on sick leave.
Today I am working on:
* Timepro PBIs
* Tidy inbox
</>}
figurePrefix="bad"
figure="Lack of details... For example, saying "Yesterday" - if it's Monday, you wouldn't say “Yesterday was Sunday"... so if you were sick, it's more useful to go back to the prior day you were working"
/>
<boxEmbed
style="greybox"
body={<>
#### Hi Bob
I have XX days until my next client booking.
I have XX emails in my inbox.
<mark style={{ backgroundColor: "#FEF08A" }}>Last Friday</mark> I was on sick leave.
Today I am working on:
* TimePro - <mark style={{ backgroundColor: "#FEF08A" }}>Adding new button to the next day</mark>
* <mark style={{ backgroundColor: "#FEF08A" }}>Getting my emails on "SSW\.com" to zero</mark>
</>}
figurePrefix="good"
figure="Clear details"
/>
## Tip 15: Auto-generate Daily Scrums with AutoScrum
[AutoScrum](https://github.com/AwesomeBlazor/AutoScrum) will scan your Azure DevOps repositories and find all the PBIs that you worked on yesterday and that are In Progress today.
***
## FAQ
### What should I do when blocked?
When you are blocked, you should ideally take steps to unblock yourself. However, you should know [when to ask for help](/ask-for-help/) and understand [what mode of communication is best for your task](/when-to-email-chat-call-or-meet).
The ideal people to ask for assistance are:
* A fellow Developer that is Senior or knows the tech
* Your Scrum Master who can reach out to the Product Owner when issues reach beyond developing your project
### What happens when you run out of tasks?
The goal is to be productive for 8 hours of the day, so communicate with the rest of the developers and work with them on any other outstanding tasks. If there are no more tasks then take the next task from the top of the Sprint Backlog.
### What happens if there is a major incident?
It is important that any major incidents are dealt with first. Start with any major incidents that occurred in the last 24 hours.
<imageEmbed alt="Image" size="small" showBorder={true} figurePrefix="none" figure="Daily Scrums will alert everyone if there is a major problem and get all brains aligned in the right direction. There is no sense in putting a Band-Aid on a patient's scraped knee if there is a big knife in his eye!" src="/uploads/rules/methodology-daily-scrums/NewStandUpImage_1710232021942.jpg" />
***
<boxEmbed
style="greybox"
body={<>
Learn more about the meetings in Scrum:
* [Sprint Planning Meeting](/what-happens-at-a-sprint-planning-meeting "Sprint Planning Meeting")
* [Sprint Review Meeting](/what-happens-at-a-sprint-review-meeting "Sprint Review Meeting")
* [Sprint Retrospective Meeting](/what-happens-at-retro-meetings "Sprint Retrospective Meeting")
* Daily Scrum (Stand-up) Meeting (this rule)
</>}
figurePrefix="none"
figure=""
/>
<boxEmbed
style="tips"
body={<>
**Tip:** It can be helpful to finish the **Sprint Planning meeting** with the first **Daily Scrum** of that Sprint.
</>}
figurePrefix="none"
figure=""
/>
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.