Rules to Successful Projects - 67 Rules

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. There are 4 main benefits you will get:

Say we are creating a web application. We can expect to:

• Improved Productivity - With set standards, decision-making is streamlined. For instance, in .NET Web applications, we bypass lengthy debates on choosing between authentication frameworks for a project; the standard approach is already defined in the rule. This allows developers to focus on building upon existing foundations rather than reinventing the wheel
• Enhanced quality - Following best practices ensures that the applications are built to a higher standard. For example, deciding on the most suitable ORM, like Entity Framework, is made simpler by adhering to pre-established guidelines
• Improve communications - For example, when we complete a task we are clear and educate the customer by including a screenshot, the code and the time taken. We are consistent with whether we call it a bug or a feature because we define what's a bug
• Direct Focus on Client Issues - With standards in place, developers don't waste time deliberating over architectural choices like whether to use RESTful services or gRPC. They can dive straight into solving the core issues that the client faces

You should create and follow standards for all manner of processes, from coding practices to project proposals, and how to lock the office up at night. The best example: SSW Rules.

From the developer's perspective, consistency means that they understand each other's code, and if they don't know something, a standard will often save them asking someone and spending hours investigating. No more Chinese whispers and less time wasted.

From the customer's perspective, consistency leads to a reliable and repeatable experience.

The following story illustrates these values:

Figure: 'The Barber' describes an inconsistent experience

Standards don't need to come at the expense of creativity. Following standards means less time doing the administrative stuff and more time for the creative. Of course, standards are works in progress, and so we are always on the lookout for improvements. That's why standards should be shared with everyone.

Video: "You do not rise to the level of your goals. You fall to the level of your systems" Atomic Habits by James Clear

What is an SSW Rule that is memorable to you?

Or, in general what makes a rule memorable?

Or, ever had a time that a rule saved you time (or from making a mistake)?

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.

There are pros and cons to having standards:

✅ The pros:

• They help speed up the decision making process – getting you to the best decision faster
• They help maintain consistency

❌ The cons:

• They take time to write in a generic fashion
• Technological rules rust easily. Technologies and techniques change often, so you must be on the lookout for the new and better approaches and continually update these
• They have errors as they are written by imperfect people
• People will sometimes follow an inappropriate rule. A set of rules can never predict every path, so cases can and will appear that the standards fail to cater for

Enhancing standards through continuous and collaborative improvement

Never ignore a potential improvement or expect someone else to work on it.

If you believe something can be improved or a standard is outdated, it's important to take action. The best approach is through a team effort, where everyone contributes small improvements regularly.

Whenever you come across a standard which needs updating or improving you have 3 options:

1. Fix it yourself straight away and edit the rule (preferred)
2. Fix it yourself later if it's too big. In this case, send yourself an email
3. Ask someone else to fix it following the change "x" to "y"

• Aligned Autonomy — Software developers have a desire to be self-directed and find that micro-management is restrictive and stifles their creativity. However its important that teams stay focused on working towards their team goals.
• Mastery — Software developers love sharpening their skills.
• Purpose — Software developers want to work on important projects that have meaning and make an impact.

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.

"Software development can be painful and costly."

Hang on, that should say:

"Software development is painful and costly."

There's no doubt custom software development is a challenging industry. According to Critical Success Factors In Software Projects by John S. Reel:

Nearly 75% of all development projects missed their target release date or never ship at all.

But what is so interesting is that at least 7 of the 10 most common signs of product development failure are present before the design is created or a single line of code is written.

Tip #1: Don't give ranges

Let's say a prospect asks me "How much to do this Release?" I could say "Somewhere between $15k - $20k..." then I hear "20k", the prospect hears "15k". I'm pleased we got it done for "25k" with a whole bunch of changes, the client is annoyed we didn't get it done for "12k". So, never give a range to a client. Tell them something like "The first Release, along with its spec, is likely to take $35k. That's two guys working full time for two weeks".

Tip #2: Be upfront about bugs

There is no such thing as bugless software. It's important to admit that bugs will happen. Bugs will get through testing, and bugs will cause a headache in production. In a fixed price agreement we cover bugs, because the goal posts are stuck in the ground, but in hourly-rate work, bugs are covered by the client. See what is covered in fixed price contracts for more information in relation to what is and what is not a bug.

Tip #3: Don't give fixed prices

A big fixed-price contract can also be dangerous in managing expectations because it removes flexibility. If you deliver exactly what the spec says, the client can quite easily be unhappy, because the hundred and one things they thought of during development weren't included.

If you need to go with fixed prices, we recommend to do it in Releases of no more than 2 weeks (1 - 2 releases), which helps alleviate this problem.

It will often occur that in the middle of a fixed price contract a client will ask you to add extra functionality. You should not do any such items straight away, but turn this request into a task for future development. You should generate another release plan for all the extra items once the fixed price contract has been signed off. It is important that the customer is always clear on what is part of a fixed price contract and what is not, that is why you should always finish a fixed price contract and have it signed off before starting extra work.

Tip #4: Talk dollars ASAP

Talking dollars with the client is often something consultants don't like doing after the initial meeting. I've heard of consultants refraining from sending invoices when a project is suffering a few delays, or the client is unhappy with the application state.

If the client is unhappy to receive an invoice now, they will not be happy to receive it in 2 months!

Send invoices for time and material projects every week. This way the client is informed of costs every week, and if a hassle arises, it's trapped straight away.

Tip #5: Be transparent about rates and resourcing

Defining the hourly rates and resources that will be available to clients ensures they are not surprised later. Additionally, explaining the differences between resources makes it clear why specific resources are grouped together and what kind of services they provide. You should have clear definitions for all of your roles so that clients understand the part their resources play.

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.

Software must help a business become more efficient and build better relationships with their clients. Business need software to be produced cost-effectively and quickly. Simple steps upfront stop software being slow to build and difficult to change.

• Adam Cogan, SSW Chief Architect

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.

So you’ve done 10 good Sprints and the software has been delivered (ready) and the team is winding down. It will need maintenance.

Different clients need different levels of support. Offer your clients a few different support offerings.

1. Ongoing Maintenance: 1 day per week (or whatever quantity suits), a developer will work on enhancements and bug fixing. This is useful because the client always knows when work will next be done.
2. Support Plan: For a small monthly cost, plus a multiple of the hourly rate, you can guarantee specific response and resolution times. This way your client will be guaranteed that they can get out of a fix quickly when needed.
3. Time and Materials or Prepaid: A client can simply call for bug fixing or support as and when needed. However, unless it's a show stopper, this model can involve waiting for developer availability.
4. Fixed Price Warranty: For a fixed price project, a warranty commences after the Sprint Review. The warranty length is half the length of the Sprint and, during this period, any bugs reported will be fixed for free.

Warranty on a Fixed Price Contract

Once the Sprint Review is complete, the Product Owner has half the Sprint period again to report any bugs. The conditions are:

1. The warranty period pauses when the client reports a bug that stops them testing further. The warranty period resumes when a new version is sent. For example, the client may report a bug on a Wednesday morning on "Day 4" of the warranty. The bug is fixed on Friday and a new version is sent late in the afternoon. The warranty period resumes on Monday morning, at "Day 4". Therefore Wednesday through Friday was not included in the warranty.
2. During the warranty period, all feedback from clients should be moved to backlog unless they fall into the bug definition.
3. There is no warranty on a time & materials contract.

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.

After a long phase of planning and speccing, hand-offs between stages of a project would traditionally involve weighty documents and getting a project from start to finish could take months or years. By embracing "Emergent Architecture" and using an agile approach to project management you spec just enough, at the last responsible moment. Just-in-time speccing ensures:

• New or evolving requirements can be met.
• The ability to provide more frequent releases for frequent feedback.
• Awesome Documentation.
• Limited Technical Debt.

The most popular and most successful way to deliver projects is using a framework called Scrum. In Scrum, you fix the timeframe and the cost so the only variance is in the features that are delivered in that time. You should keep your time to between 2 and 4 weeks and all your team members should be full time, thus fixing the costs.

See Rules to better Scrum.

At SSW we spec in two phases: first to get an overview of the project, and then ongoing as needed to flesh out each PBI once it is about to be added to a Sprint:

• Spec Review
• Just-In-Time Speccing - this phase is repeated through the project

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.

Crafting a UX storyboard does not require artistic skill, it only needs to be a rough sketch that shows the sequence of events. They help developers and stakeholders understand what the UX and user scenarios will be, and are usually included in Spec Reviews.

Storyboarding first became popular as a tool in motion picture production.

Why isn't UML sufficient?

Many people use UML (Unified Modeling Language) to specify, construct, and document the various aspects of software systems. UML serves a purpose for helping developers understand what to do technically. However, for clients a UML diagram is hard to digest. If a developer understands something during a requirement stage, but a client does not, they are not much value as the client wont give feedback.

On the other hand, Storyboarding is an effective way to capture, convey, and explore different user experiences.

What are the best tools?

• Hand-drawing (Recommended)
• Virtual Whiteboards. e.g. FigJam or Excalidraw
• Diagrams.net
• Balsamiq

Video: How to create a UX storyboard (3 min)

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.

A great way to get feedback on upcoming projects is by putting specs of upcoming projects on the web and inviting user comments - not forgetting to acknowledge their contribution.

Why write code when you may not need to write any at all?

Often users will tell you what is needed to make the product great instead of just good, or you may be told that there is already a program out there that does the job. You should also spend a good amount of time looking for similar products and speaking to users about the features. Since the specs are full of screen captures, this allows you to think of the end-user and increases the likelihood of creating a great product which your users love.

Who comes first, the technology or the user?

Do tailors measure their clients after the suit has been sewn together?

The following example illustrates these values:

When building anything, remember to balance your engineering, business values and usability.

The main points:

1. Put your specs on the web
2. Ask for feedback
3. Keep the followers updated with changes
4. And most importantly, listen to your 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 main choices for CRM solutions are:

• Salesforce
• Microsoft CRM

At SSW we implemented a lot of CRM services based on Microsoft CRM. The experience with this solution showed us high trust in using Microsoft CRM as a base for future business needs.

Read the rules to better Microsoft CRM to get an idea what CRM can do for you.

The best developers are also extremely good at finding a solution to a problem they don't know.

I am pretty good at Googling but when I can't find something, I ask my friend Scott on IM. Scott Hanselman is the best Googler I know. He can find anything in 2 minutes...Tips:

1. Think of a piece of the code that will be in the answer
2. Include the company name if possible
3. Use the advanced searching functionality
4. Use quotation marks when you're searching for an exact string
5. Include the technology used if appropriate

If someone asks you for help searching, always tell them the keywords - that will help them learn to search better.

For example, take www.smh.com.au, a leading Australian news website. If you search on the keywords 'Australia' and 'news' you won't find it on the first page, but if you add 'Sydney' (a word from the company name) then you're number 1...

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.

If you are using Windows, desktop search is integrated within the operating system. This can either be done from the Start Menu, Cortana or File Explorer. Additionally, third-party tools such as Everything can be installed and used for fast searching of files on your drives.

If you are using a Mac, Spotlight Search 🔎 is located on the top-right corner or Finder.

If you are using Office 365 (Teams, Delve, OneDrive, Dynamics) you can use SharePoint Search to easily find your documents, profiles, and web pages.

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.

Sometimes, due to the nature of the work, the time taken to investigate is completely out of proportion to the time taken to complete the work. As an example, if you are working on a legacy ASP application with loads of spaghetti code, and the client wants a particular bug fixed, it can take 2 hours to locate the bug, and then only 15 minutes to fix it. When you report to the client the estimate for 'how long' - ensure you include the 2 hours investigation, not just the time to fix it. Thus, you need to put 'this took me 2 hours 15'.

Scrum may seem complex at first, but it’s simpler than you think. Follow these 8 easy steps to master it.

Video: 8 Steps To Scrum - Scrum Explained (4 min)

Print out the SSW 8 Steps to Scrum PDF and put it on your "War Room" wall.

1. Initial Meeting

In the Initial Meeting, the Product Owner explains the product vision. The Developers think about the Architecture needed and how long they will need to come up with an estimate.

2. Backlog Construction

The next step is Backlog Construction, also known as a Specification Review. The Developers propose a high-level software architecture and a to-do list called the Product Backlog. The required features are broken down into Product Backlog Items (PBIs for short).

These PBIs are estimated and, before a dollar figure is presented, a buffer is added for generic tasks such as DevOps, Testing, Bug Fixes, Project Management, etc.

This is also when the Product Owner 1st defines the Product Goal (aka the "why" of the project), although this can and should be refined throughout the project.

A quick note, there are only 3 roles in a Scrum Team, The Product Owner (the boss), the Scrum Master (a kind of project manager), and the Developers (who do the work).

3. Sprint Planning

The Sprint Planning session is for the Developers to focus on the subset of the Product Backlog that they think they can complete in the next Sprint, (which is most commonly a 2-week timebox).

The Product Owner puts the PBIs into priority order and makes sure the top ones have enough detail to be worked on. The Developers then pulls PBIs from the top of the Backlog and commits to delivering as much as they forecast they can, in the coming Sprint.

The Developers and Product Owner together then define the Sprint goal, (aka the "why" of the Sprint).

4. Sprint

The Developers work on features in priority order, having done a Daily Scrum and sending 'Done' emails once the 'Definition of Done' is met. A task board is often used. During this process, the team also refines items in the Product Backlog to ensure they conform to the 'Definition of Ready'.

5. Product Increment

Each Sprint is a potentially shippable Product Increment, and with good DevOps, including automation of deployment and testing, this can be done on a "PBI by PBI" basis. This means each feature worked on can be in production as soon as it is finished.

6. Product Feedback

Product Feedback will then come in. Some will be bugs, and some will be small changes that can be added to the current Sprint. Other suggestions should be approved by the Product Owner and then added to the Product Backlog.

7. Sprint Review

At the end of the Sprint, there is a Sprint Review, where the Developers demo or play done videos of the completed PBIs. The goal is for the Product Owner to understand the increment and to discuss the feedback to make the product better. This is the real measure of success of the Sprint.

8. Sprint Retrospective

Lastly, there is the Sprint Retrospective, and this is the best part! The Scrum Team discusses what went well, what didn't, and what to improve, always inspecting and adapting.

From here, another Sprint Planning session commences, and the wheel keeps turning, getting better and better with every revolution.

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.

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 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.

Video: Watch a Daily Scrum at Microsoft (short - 4 min)

Video: Watch a Daily Scrum at Microsoft (long - 12 min)

"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 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 to check on the progress of the team.

Tip #3: Keep a schedule of the Daily Scrum times on a wall (+ have a recurring appointment in Outlook)

Tip #4: Keep to the schedule - Same place, same time (even if people are missing)

Get started on time. Especially in the beginning, people will be late, but the meeting should be held with the remaining people. 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.

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?

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", 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.

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 him in the few days, then do so. A disconnected or absent Product Owner is a sign of dysfunction.

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 so they can locate the Daily Scrum for any project via the Teams team.

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.

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. 😊

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.

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 or Skype 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

When using email or IM try to be brief and as specific as possible:

Tip #15: Auto-generate your Daily Scrum with AutoScrum

AutoScrum will scan your Azure DevOps repositories and find all the PBIs that you worked on yesterday and that are In Progress today.

More details: github.com/AwesomeBlazor/AutoScrum.

---

More information

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 and understand what mode of communication is best for your task.

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.

---

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:

1. A visual identifier such as a tick or a cross on the main menu
2. A "Check for Updates" option in our Help menu.

Remember:

• This is mainly for Windows Forms, but you can do the same for new versions of Web Applications - e.g. a knowledge base package or Reporting Services Application.
• You can do a complete check of your PC at the click of a button using SSW Diagnostics.
• Since this check occurs over the web, you should use threading to avoid slowing down the forms responsiveness. This is a generic component that is available in the SSW .NET Toolkit.
• If the UI is a Windows Service, be aware that they don't open up the UI very often. Therefore you can't rely on this method. In a coming release Diagnostics will ask for your email and let you know when updates are available for you PC.

To keep the consistent look and consistent code, we have implemented our version checker as a user control.

As it is a user control, we can easily implement this in all our applications. We just need to place the user control on the winform, and have the ProductDownloadID and ProductLatestVersionURL entered with the correct values.

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.

Not to say though that there is any ideal error message - a great error is one that has been eliminated! In packaged products, every unhandled error is our problem.

In the old days, unhandled errors would be stored in a local Access db, but now all unhandled errors should be automatically emailed to the product team. This is a proactive and polite approach to dealing with unhandled errors. If it's serious we will contact the client to resolve the situation - they get a bit of a surprise and think we have ESP!

Remember what it is like to have good service in a restaurant. A good waiter knows when to interrupt you, when to leave you alone and how to do it all in a courteous and respectful way.

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".

There are 3 levels of 'Done' in communication

Level 1

• Documenting/updating the standard (for processes, when necessary)
• Sending a "Done" email

Level 2

• Documenting/updating the standard (for processes, when necessary)
• Sending a "Done" email
• Screenshots
• Code

Level 3

• Documenting/updating the standard (for processes, when necessary)
• Sending a "Done" email
• Recording a quick and dirty "Done Video"
• Code (showing a full scenario, e.g. a user story)

There are 8 levels of 'Done' in software quality

Start with these examples showing typical "Definitions of Done" from beginner teams to more mature teams:

Team - Level 1

• The code compiles
• All tasks are updated and closed
• No high priority defects/bugs are outstanding for that user story

Team - Level 2

• All of the above, plus
• All unit tests passed
• Tests achieve greater than 1% code coverage (not earth shattering, but you need to start somewhere)

Team - Level 3

• All of the above, plus
• Successful build on the Build Server
• Git Branch Policies OR

• Azure DevOps Check-in Policy

  • Change set Comments - all check-ins must have a comment
  • Work Items - all check-ins must be associated with a work item
• Code reviewed by one other team member (e.g. Checked by Bill)
• Sending a Done email with screenshots

Team - Level 4

• All of the above, plus
• All acceptance criteria have been met
• All acceptance criteria have an associated passing test (e.g. an Azure Test Plans test case or automated end-to-end test in Playwright)
  Tip: Use Microsoft | Azure Test Plans
• Sending a Done email (with video recording using SnagIt)

Team - Level 5

• All of the above, plus
• Deployed to UAT (ideally using Continuous Deployment)
• Complex code is documented (helping to avoid technical debt)
• Product Owner acceptance

Team - Level 6

• All of the above, plus
• Application automatically tested in multiple environments, using services such as Azure DevTest Labs and BrowserStack

Team - Level 7

• All of the above, plus
• Automated Load Testing (see the best load testing tools for web applications)
• Continuous Deployment

Team - Level 8 (Gold)

• All of the above, plus
• Deployed to Production

Congratulations! You are frequently deploying to production. This is called “Continuous Delivery” and allows you to gather quick feedback from your end users.

You might have everything deployed to production, but it might not yet be visible to the end user. This can be achieved by having “Feature toggles” in place. The actual release of the functionality is a decision that the Product Owner and business takes.

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.

Acceptance Criteria are useful to every person who deals with a PBI. Developers know what they are required to implement and how their work will be tested. Testers have a basis for knowing what tests to create.

What do good Acceptance Criteria look like?

Product Owners should make an effort to specify all of their requirements for a PBI in the Acceptance Criteria. For example, Product Owners should not assume things like:

• They will get a message that says ‘no records found’ or
• The grid will support features such as pagination or sorting

They must be specified in the Acceptance Criteria if required for the PBI to be considered complete.

Negotiating "gold plating"

Any requirements that the Product Owner considers "nice to have" - as opposed to being mandatory for the PBI to be considered complete - should be negotiated with development as early as possible. Developers can spend significant time working to meet acceptance criteria that the Product Owner is actually willing to sacrifice in the interests of quicker delivery.

Technical Acceptance Criteria

Sometimes, the team may discuss including technical requirements in Acceptance Criteria. Typically, technical Acceptance Criteria should be avoided. However, there are some situations where it makes sense, such as when:

• The team is trying out something new
• The team has been misaligned in the past, and the future direction needs to be clear
• The approach to take is complex or confusing
• An abnormal approach is being taken to avoid a specific issue (e.g. reducing readability to improve performance for a particularly critical query)
• When the PBI is an Enabler (backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream)

If technical requirements are added, it should be a discussion between all of the developers in the team. If the Product Owner is technical, they are welcome to join the conversation, but they should not be the primary decision maker in this case.

Additionally, when adding technical requirements try to prefix with "Technical - " so their purpose is clear to everyone (e.g. "Technical - New CQRS Query made to get all employees")

Acceptance Tests

Since Acceptance Criteria will be used to determine whether the work for the PBI is done or not, each of them needs to verified using an Acceptance Test.

It is good practice to make sure that each of the Acceptance Criteria is testable (e.g. Tests can be written to definitively determine whether the criteria has been met or not). This can help to reduce vagueness in the way Acceptance Criteria are defined.

What's the difference between "Acceptance Criteria" and "Definition of Done"?

Acceptance Criteria help to answer the question "How will I know when I'm done with this PBI?". The Acceptance Criteria are different for each PBI, provided by the Product Owner and used as a way to communicate to all involved that the requirements for a particular PBI have been met.

The Definition of Done is a structured list of items, each one used to validate a PBI, 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 check each PBI for completeness. The definition of "Done" is intended to be applicable to all items in the Product Backlog, not just a single PBI.

Examples of items in a Definition of Done that would not be part of Acceptance Criteria include:

• Code review completed
• Unit tests passed
• Code deployed to production

Capture changes to the PBI from discussions

The Acceptance Criteria are the source of truth for what functionality needs to be implemented for the PBI to be considered complete, so it's important to capture any changes to the PBI and the Acceptance Criteria (e.g. adding or removing "nice to have" aspects of the PBI).

Any discussion that changes the PBI and/or the Acceptance Criteria should be noted in the Discussion section of the PBI for reference.

This rule has been important for a long time: Fix bugs before adding functionality.

• Bugs get more expensive as they get older
• Bugs become more complex the longer you wait to fix them
• You have better access to the developer who created it who will be able to fix it faster

Source: What is a Software Bug? Cost of bug fix!

---

Failing to follow this rule encourages developers and creators to focus on new 'interesting' functionality which is exactly what you don't want...You must be strong in the face of pressures from project plan scheduling!

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.

The best way to test this workflow is by performing the workflow against a real environment, using a real browser – of course, in a repeatable, consistent way.

A nice option is to use Seleno with an appropriate web driver for the desired browser – see the Seleno documentation. This library lets you write code to drive a user’s action in a browser, including for example logging in, searching for a product, adding it to the cart, proceeding to checkout, entering test credit card information and ensuring the success message.

This isn’t free though. The nature of these tests mean that without proper care and maintenance, tests will fail intermittently. There are difficult-to-predict timings, DOM changes and browser compatibility issues and ongoing maintainability - so it is beneficial to limit these kinds of tests to critical happy-paths.

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.

Warwick Leahy tells us why it's so important to save our files in the right place:

Want to learn more? Watch Jean Thirion's longer video on this topic:

Don't start searching from your start menu either for a program whether that be Notepad, Notepad++, OneNote or even Word. This will open the new file locally on your laptop which requires manual copying/sharing later - and it's easy to forget to do that.

Instead create your file in the Team for a start. It is immediately backed up and shared to the entire Team.

The great thing about having conversations next to the file is that it is always in context. Also, future users can view the conversation when they open the file in teams.

Behind the scenes, storage is provided by a SharePoint site; so that is there if you want to use it. As an added bonus thanks to this; you can take the files offline by syncing with OneDrive for Business and by default each channel gets its own folder.

What does not get stored in Microsoft Teams?

For developers

• Code obviously belongs in GitHub, Azure DevOps, etc
• The 8 important documents should be stored in Azure DevOps (was TFS/VSTS), or instead use Markdown with the Wiki

For designers

• For large files, OneDrive is a better choice. See the best Source Control for Designers

What about usernames and passwords?

Documents with usernames and passwords should not be stored in Microsoft Teams. Security is very important for everyone and every company. Use a password manager to store usernames and passwords.

Note: API keys, whether generic or for the individual should also be stored in a password manager.

Note: You can add other cloud storage providers for file storage e.g. Google Drive, Dropbox, etc. This is not recommended, as they aren't first-class citizens (i.e. if you want to share files from them, you need to go to the provider's sharing settings outside of Teams).

::: infoWarning: By using Teams instead of SharePoint, you are losing a number of key features:

• No full fidelity support for Metadata in Document Libraries. E.g. Can’t add extra columns into the “Files” tab
• No support for private channels. E.g. You will need a team per subset of users with different permissions
• No direct access to version history from Teams UI (still exists on SharePoint UI)
• No access to the cross-office365 Search feature. E.g. SharePoint search is better
• No access to external content in the search feature. E.g. Can’t search ssw.com.au/rules
• No access to SharePoint designer workflows (although the new way to do it is Microsoft Flow) :::

Each client project should have a nice place to keep files. In the old days, things were simple but limited, we simply used Windows Explorer and file shares. Today there are so many places that teams can store documents. E.g Dropbox, OneDrive, SharePoint, Microsoft Teams and Azure DevOps (was TFS).

Which is the best corporate solution?

The solution that allows the best collaboration with Developers, Project Managers, and other stakeholders is SharePoint and Microsoft Teams. It is super easy to create, upload, and share documents with others.

More at Files - Do you store project documents in Teams?

What emails do you need to store?

More at Sales - Do you track all sales related activities in CRM?

What stuff do you need to store?

For most projects, you need to quickly store and locate important details and documents such as:

• Server details (Dev, Test, Production)
• Change-log documents
• Upcoming features (most often in Word or OneNote)
• General documents e.g. Requirements/Specifications (Note: it is possible to share documents from Microsoft Teams externally, but not from Teams directly... just open it in Office Online or a specific Office app first)

What does not get stored in Microsoft Teams?

1. For developers
2. Code - it belongs in GitHub, Azure DevOps, etc.
3. The 7 important documents - should be stored in Azure DevOps... or instead use Markdown with the Wiki
4. For designers
5. Large files - OneDrive is a better choice. See: Do you know the best Source Control for Designers?

What about usernames and passwords?

Documents with usernames and passwords should not be stored in Microsoft Teams. Security is very important for everyone and every company. Use a password manager to store usernames and passwords.

When you are regularly creating new releases of a cool .NET application or simply producing new proposals in Microsoft Word, 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.

Video versions and using 'zz' on YouTube

When uploading to some video hosting sites, like Vimeo, you can update a video by replacing the original video while keeping the same URL and view count.

In YouTube an uploaded video can't be replaced, so to create a new version of a video it will be uploaded as a new video with a new URL.

So that there are no broken or missing links, the video status is set to "unlisted", and we use the 'zz' process:

• Add 'zz' to the beginning of the title.
• Add a link to the latest version at the top of the description

Using 'zz' in practise

When you see ‘zz’ in the title of the video description, it’s important to know how to access the latest version of the video so you’re not watching old content.

On YouTube click the ‘New Version’ link in the description.

Not ready to 'zz'? Use 'yy'

Other systems are used that are less aggressive than this 'zz' rule.

• In .NET, the keyword "obsolete" is used to mark types and members of types that should no longer be used - these then turn up as a compiler warning
• In HTML content, the keyword deprecated is often used

Both allow for some backward compatibility. In these cases, use 'yy' instead.

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.

Now managing those tasks can be difficult. "Just stick an appointment in Outlook" - yes I've heard and tried that method. Outlook is perfect when you are the one performing the task. But it's nowhere near perfect if you're managing people who are allocated to perform the task. In fact it's a disaster, because when that person leaves, (or just changes job role) that scheduled task/reminder disappears with them.

The other problem with Outlook is if you are an organization that relies upon email as a to do/task list, Outlook doesn't send an automated email.

The best solution for recurring tasks is to create a Microsoft Power Automate flow that has a provision to run as per the scheduled day and time every week or month or year.

The recurrence task can work perfectly by Power automate, which can send an email or create a calendar invite as per user requirement.

In the course of work everyone encounters bugs or problems. They can be dealt with by either:

1. Pretend you didn't see the problem
2. Fixing it straight away
3. Add the issue to the backlog so someone else can fix it

The best solution is to use a combination of 2 and 3.

• If it will take less than 15 minutes to fix, do it straight away.
• If it will take more time, add the problem to the Product Backlog and email a link to the appropriate person (even if it’s a third party product).

This approach raises the question of priorities. If you hit too many hurdles you continually get diverted from the main task. For example when fixing the Client form you encounter a problem with the Client Contact form which breaks the Products form etc. (This can be described as the "Tree Approach" as opposed to the "Straight through to the Goal approach".)

You need to try to balance short term productivity with long term improvements. The idea is that it is better to get 2 things done at 100% than get 4 things done at 75%! At a minimum, always add the issue to the backlog.

Imagine this scenario... A designer notices a small typo on an intranet page. As a good employee, they open up the backlog and create a PBI to fix the spelling error. Then send a "to myself" to action.

Meanwhile they are thinking... "That took more time to report the error than it would have taken me to fix it".

Small errors should be fixed by the person who found them straight away. Text changes can be easily done in SharePoint, WordPress, or GitHub. The best way to make changes easy is by using TinaCMS.

Bear in mind that communication is indispensable. Therefore, it's crucial to ensure that other individuals connected to that content are informed about the fixes/changes through either an @mention or a brief instant message (IM).

Do you know what the most useful thing on Microsoft website is? It is their knowledge base at support.microsoft.com.

When a problem arises it should be your first port of call - it allows you to help yourself.

So, if you answer questions on your products to customers, you are wasting time if you don't have a knowledge base. Just think, you might not be answering Harry's question if he could have looked it up himself.

Now of course there are many customers who don't look for a KB, but instead, you fire off the same old email that you already know is an MDAC related error, and your current solution is to tell them to run SSW Diagnostics and get all the green ticks.

The basic rule is: don't send back the answer in your email - instead send back the link. More specifically:

1. If you can answer a support email then reply to the support email

   • To: the client
   • Cc: the developer and your manager with the KB link

2. If you can’t answer the question then reply to the support email:

   • To: the client and the developer
   • Cc: your manager
   • Ask the customer if they can get diagnostics to all green ticks.
   • Ask the developer to “Please action?"

Note: In this email, you can offer them an interim build.

Notice how by just giving them the URL, this email does the job of encouraging them to use your knowledge base in the future. You need to make sure the support staff knows that there are really only 4 types of emails customers should be receiving (see the 4 grey boxes).

Things are running well when you have support staff adding new KB for:

• Known issues
• Hot tips
• Performance tips KBs also play a very important role in getting a product released. You will never get every feature done or bug fixed - we all know it.

Focus on getting a version out. It is usually more important to have a version available than having no version at all. When you are looking down the Project Plan, decide on what the must-haves are. The other features and known bugs will have to remain outstanding. All the longer-term bugs should go into the KB. We also put in the feature requests that we plan on doing. This way our customers know of our exciting features coming in future versions of our software.

However don't write a KB article if fixing the bug and making a new version solves the problem. You'll have to fix the problem anyway, so don't waste time writing a KB, just email the new version.

You don't need to be Microsoft to build a KB. A Knowledge Base does not need to be complicated. We use a simple knowledge base which is located at pdi-ssw.zendesk.com/hc/en-us.

An important tip for creating a knowledge base document is to make sure it is easily searchable and accessible.

You can easily create a page for a KB in GitHub's Wiki section. E.g. SSW CodeAuditor KB.

There are a few methods to control a client's machine remotely, all of them have the same functionality, but different usage, and different pros and cons.

Desktop support

For supporting end users' workstation machines remotely, here is the order you should try with the end users:

• Microsoft Teams - (recommended)

• TeamViewer
• Skype - via screen share
• Skype for Business (previously Lync)
• Aeroadmin
• Mikogo (Free)
• JoinMe (Free)
• UltraVNC (Free)

Servers

For server machines, we recommend using either Windows' built-in Remote Desktop (also knows as "Terminal Services") or a VNC-based tool. Remote Desktop provides each authenticated user a Windows login session that is not shared. If your client lives in a place where the time zone is different, Remote Desktop should be your first choice as it doesn't need the client's interaction once Remote Desktop is enabled (typically it should have been enabled for a server for the ease for remote maintenance and monitoring). For servers, Remote Desktop is usually enabled via a group policy (AD GPO), although it can also be enabled through Windows System Properties.

Remote Desktop works for workstations, but it's not recommended due to a security risk if Remote Support isn't disabled. Also, because of the End User License Agreement (EULA), only allows 1 user at a time, if you log in to client's Windows machine, the client will be logged off.

If you can't use TeamViewer, Skype, or Remote Desktop, you can try VNC. There are a number of VNC servers and clients available. VNC-based sessions typically behave as if you're physically using the computer. This means that it shares the same login session with the user who is currently logged on the machine. VNC software allows you to configure a specific username and password for remote access, which means that you don't have to share Windows usernames and passwords or create a temporary Windows user account. Some clients may also prefer this as they can sit in and watch what is happening.

The VNC tools we prefer: TightVNC and Ultra VNC.

Read SSW Remote Support Standard.

Why don't most developers plan ahead? Take an average Desktop application that you sell to a few customers. When the customer wants a new version, there is no problem giving the customer the new exe. But what if you made a back-end structural changes to your database? Big hassle! You need to compare the database to remind you what was changed. Sure there are utilities for this - for Access back ends you can use SSW Data Renovator or for SQL Server back ends there is Red-gate SQL Compare - but why go to this trouble?

Version control for your Schema and where required your Data should be an important part of planning your projects.

For more information read Rules to Better SQL Server Schema Deployment.

It is important to maintain three separate environments for development, testing and production. Some companies skip the testing server because it can be a hassle to copy new files, register DLLs and deploy backend changes. This will usually result in higher support costs and unhappy users due to simple bugs that could have being found in testing.

You should also place the resources for each environment into its own Resource Group, and the resource group should have a tag to easily identify which environment the Resource Group relates to.

For more information, see our rule: Do you apply tags to your Azure Resource Groups?.

Now make each environment clear.

Whenever an application has a database, have a visual indicator. I recommend a different background color for each environment

• Red for the Development database
• Yellow for the Test database
• Grey (no colour) for the Production database

Note: The Yellow could have been Orange (kind of like traffic lights) but the color palette in Word doesn't give Orange.

Figure: Colors in Word color palette

For more information, see our rule: Do you identify Development, Test and Production Web Servers by colors?

Note: Relying on color alone is not accessible for people who are visually impaired. It's important to use other identifiers to distinguish between environments.

For webapps and websites, make the environment clear by using a URL prefix too.

For more information, see our rule: Do you always rename staging URL on Azure?.

This prevents testers from accidentally entering test data into the production version.

Static Site Tip: Add a "THIS IS THE X ENVIRONMENT" banner header to your non-production websites.
Windows Forms Tip: Implement in the base form in the header
ASP.NET (at least version 2.0) Tip: Implement in the master form in the header

Figure: Spice up your environments with different colors

"An ounce of prevention is worth a pound of cure" goes the saying. Having a strict coding standard is prevention. To create good code you must have good standards, such as commenting standards, naming standards, versioning standards and knowing the value of consistency.

But this can really only happen if you’re going to go the extra mile and stick your neck out and correct someone.

Every member of a team plays an important role in maintaining standards. Whether it's your work or someone else's, always keep an eye out for things that can be improved.

This rule applies to all company standards. Standards are important because they ensure your experience at work is consistent and enjoyable. For example, if there was no standard to stack the dishes in the dishwasher when you were finished using them, dishes would build up and create a big mess in the kitchen!

Be nice, not harsh

Read Do you know the nice way to correct someone?

Small things = Tiny Tip

When the 'mistake' the person made is not an actual mistake, but something that the company has decided to do in one way for consistency, without a strong argument.

Important things = Tip

When there is a proven better way to do something different from what the person has done. You should try to include the reasons.

Crucial things = Critical

When the error the person committed can lead to a misunderstanding or a security breach. You should include a task with action when necessary.

Coding - For Developers

When you come across a code error, it's always better if you just fix it straight away. Then write an email to the person explaining what has been done wrong and how you fixed it.

In cases where you aren't able to fix yourself, send an email to report the error/bug, which should be become a PBI and then fixed.

What about checking PBIs?

You will be surprised at how many developers write bad PBIs. You need to be a standards watchdog and correct them until they understand the importance. Be patient, it takes many times, they do eventually write good quality PBIs.

Tips

• If you don't know who made the mistake, use the annotate tool to find out
• Cc relevant parties to help others to improve, to collect brownie points, or to set a good example

What if it's recurring?

When you notice someone doing the wrong thing:

• First time just send an email with a pointer to the rule
• The second time, have a very quick chat with them
• Third time call them in and give them a formal talk about it

Focus on the meat first

When you receive a great 'done' email or document, make sure you mention how great it is before correcting any potential error.

Timing is everything - Don't bottle it up

It can be tempting to offer your feedback as soon as you think of it, but it's better to hold off until the recipient is in a place where they can hear it. If a person is busy, distracted, or in a poor emotional state, chances are your feedback won’t hit the mark. Wait until the person is calm and relaxed before asking them if now is a good time to offer your feedback.

For more, check out Do you know to create a safe space instead of jumping into feedback?

Going Anonymous

If a critique is personal, it can be hard to correct someone – especially if you don’t have a close relationship with that person. In a case like this, you should discretely ask your manager how to proceed.

Taking Feedback

Summary

It's important to ensure others are doing their best to maintain and follow the standards. Remember, it can be just as important for someone's professional development to give feedback as it is to receive it. Being able to communicate feedback in an effective and professional manner can benefit you in any career.

Using ChatGPT to correct someone nicely

Using ChatGPT can be an effective way to correct someone nicely. It allows you to provide feedback in a friendly and creative manner, reducing the risk of making the recipient feel defensive or upset. Use ChatGPT to create a personalized and entertaining message that communicates your feedback.

Providing feedback in a light-hearted and friendly manner can encourage colleagues to be more receptive to suggestions. Click “Regenerate response” if you don't like the output!

Do you rely entirely on the claims of Recruitment Agencies when selecting new employees? If you do, it may be a very costly mistake. We have been giving interview challenges to new employees for 10 years. A candidate has to prove they can walk the walk before they can join our team.

We give a Project Management test to coders as well. Developers should be able to contribute to the working of a project from end to end. They need to communicate with not only sales and marketing staff, but also clients and people that walk off the street! Clients typically think developers (aka computer nerds) come from another planet. Getting Project Managers at the go between is good, but on many jobs it just adds a layer and an unnecessary cost to a job. Recruiting developers that understand the ins and outs of project management means that that developers have less reliance on a Project Manager, they get to speak to customers more (a very good thing) and the customer gets a cheaper solution.

Another thing is that when interviewing you have to go on your instinct a bit. This won't always work, but as Joel says: "a bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs." It's best to let a good candidate slip occasionally than let a bad one spoil your coding and client relationships. Joel again: "If you have any doubts whatsoever, No Hire."

Automate Interview Process

We use a Microsoft Teams application that provides a seamless coding challenge experience to candidates that apply to SSW. This system ensures a consistent and efficient process for evaluating candidates' skills. It has the following features:

• Step-by-Step Guide: Provides a detailed walkthrough of the interview process, ensuring candidates understand what is expected at each stage.
• Built-in Timer: Helps candidates manage their time effectively during the challenge.
• Automated Tasks: Automates tasks such as provisioning a GitHub repository for candidates to use during their coding challenge.

Track Communication/Technical Challenges

At SSW, we use a dedicated website to manage our candidate challenges. This platform offers several features:

• Create Challenges: Allows you to create Communication/Technical challenges and automatically send out Outlook appointments to candidates.
• Customizable Challenge Types: Supports various types of challenges tailored to different roles, such as Admin, Designer, Developer, SysAdmin, and TV for Communication Challenges. Data Engineer, Full Stack for Technical Challenges.
• Track Progress: Enables you to monitor the progress of challenges, including the information about interviewers and candidates, upcoming challenges, ensuring you have a clear view of your hiring pipeline.

By automating and tracking the candidate testing process, you can ensure a thorough evaluation of each candidate's capabilities and streamline your hiring workflow.

Analyze Tracking Data

Using the tracking data from your candidate assessments can provide valuable insights into your hiring process. By analyzing this data, you can:

• Popular Challenges: Understand which types of challenges are more popular or frequently used, helping you refine your assessment strategy.
• Identify Challenge Managers: Determine who is managing challenges effectively and recognize their contributions.
• Resource Allocation: Optimize resource allocation by knowing which challenges require more attention and which are running smoothly.

By leveraging these insights, you can continuously improve your hiring process, ensuring that you select the best candidates and maintain an efficient and organized system.

Developers are notoriously unhealthy people. They don't exercise enough, don't sleep enough and eat the wrong food. An unhealthy developer is not going to be able to concentrate or put in the hard-yards when required, nor are they going to be very happy. In the office I try to look after them as best I can by:

• Not having chocolate biscuits and instead keeping a bowl of fruit
• Not having coke machines and instead having a purified cold water bottle in the middle of the office
• Encouraging them to do as much exercise as possible - even doing push-ups every day.
• And instead of dinners for birthdays where you eat and drink all night, every few months we always do something fun for someone's birthday, like indoor climbing, ten-pin bowling or even a bush walk in the Blue Mountains.

I also conduct a monthly weigh-in, with incentives to look after yourself. I don't encourage my developers to stay up all night investigating new stuff, and I take them away for a two weeks every year to work by the beach and get some fresh air into their system, as well some early morning swims.

I find that encouraging a healthy life-style really helps my team be more productive and have more fun.

We often talk about the 'bus test' to assess our project's resilience: What happens if your project lead gets hit by a bus? But let's consider a less gloomy, yet equally unexpected scenario: What if they're recruited for a top-secret government mission? In either case, the question remains: Is your project structured well enough to survive such unforeseen events?

Document Everything

Ensure all project-related knowledge is well documented. This includes not only technical documentation but also process workflows, login credentials, and decision-making rationales. Use tools like Confluence to keep documentation centralized and accessible.

Share Knowledge Regularly

Encourage knowledge sharing through regular team meetings and internal presentations. Use pair programming or code reviews to ensure more than one person is familiar with each part of the codebase.

Define Clear Processes

Have clear, documented processes for common and critical tasks. This includes processes for deployment, handling emergencies, and onboarding new team members.

Implement a Buddy System

Assign a ‘buddy’ for every critical role. This buddy should be capable of taking over the role in case of an emergency. Regularly rotate these assignments to spread knowledge.

Use Accessible Tools

Ensure all tools and resources used in the project are accessible to more than one team member. Avoid situations where only one person has access to a crucial tool or piece of information. A great place to store these is Microsoft Teams. See our rule: (Does your project pass the bus test?)

Plan for Absences

Regularly conduct ‘absence drills’ where a key team member is simulated to be unavailable. This helps identify weaknesses in the current resilience plan.

Foster a Culture of Continuity

Encourage a mindset where every team member understands the importance of continuity. This includes being proactive about sharing information and training others.

Conclusion

Remember, the goal is not to prepare for the unlikely event of a team member being hit by a bus or whisked away on a secret mission. It’s about ensuring your project is resilient, no matter what life throws your way. A project that passes the 'bus test' is robust, less stressful for the team, and ultimately more successful.

Keeping your mind on the job is very important, especially when you're trying to fix a bug/issue or finalize a task to meet this afternoon's deadline. Here is how you keep "in the zone":

1. Refer people to standards and you will be helping them learn + reducing the number of interruptions they get. This is why we invest in the SSW Rules.
2. Avoid multi-tasking as much as possible. Don't open an email, respond to half the questions, and then open another. Complete the first task and then delete the email. When you multi-task, there’s a higher chance your work quality will be dropped, as well as your attention to detail.
3. Set your Browser's default to "About: Blank" so you don't get distracted by news or social media, for example. Tip: There is an extension for Google Chrome to replace your homepage called Momentum, where you will be shown a photograph as the background, time, greetings, and your own focus for the day.
4. Minimize Phone distractions. If you are in a meeting, it’s a good idea to put your mobile phone to “do not disturb”.
5. Minimize Microsoft Teams distractions.
6. Minimize Outlook distractions.
7. Minimize Skype distractions.
8. People should avoid distracting you - using IM unnecessarily can be evil. See Do you know important chats should be in an email?
9. People will interrupt you less if you let them know what you are working on. Tip: Use the Teams status to let people know what you are doing (saves them having to ask you). See Do you use the status message in Teams?
10. Whenever you can, programming/working in pairs is great as it means you will be forced to focus, you won't cruise the web, or play Solitaire.
11. Use a concentration technique, such as Pomodoro.

Employees need easy access to standards that are used everyday. You should maintain standards for any activity that can be standardized including coding practices, naming conventions, standard form layouts and documents. There are also internal standards like expense and leave procedures.

The first step is to use HTML rather than Microsoft Word documents.

The second step is to think about location. Should it go on a website or Intranet? We believe in dividing it up into 2 groups:

• Public - e.g. /Standards
• Private - e.g. /Standardsinternal

The benefit with standards on the web is to get feedback from other developers.

The third step is to decide on a web page theme so every page is consistent. I am continually surprised at how much time is wasted by managers explaining to web designers the corporate template - so get smart and do one up that they can follow.

It is common during the course of a project to assemble a pile of papers of notes and other information related to the client you are working with. Some of these will be tasks that relate to the project, some will be general information that does not require any action, and some will have no use. In any case, it's important that you don't lose anything that may be needed later.At SSW we use the following system for managing papers around the office:

All SSW staff are allocated a physical inbox. You must check it daily to ensure that it is kept empty - this is where papers relating to your projects will end up.

1. Paper is related to a task:

   • Send an email to yourself with 'Note to self' in the subject line, and the task in the body.
   • Throw the paper away.

2. Paper has no use:

   • Throw the paper away! Examples of this would include your own notes that are no longer relevant.

3. Paper is not a task but needs to be kept anyway:

   • The SSW filing system is split into 3 categories: current clients, past clients and SSW internal. It is your responsibility to make a new folder if one doesn't exist for your client (filing supplies and the label maker are in the machine room). Write the ClientID and your initials and date in the top right hand corner of the paper. e.g. HOED - CA - 11/11/2000.
   • Hopefully any papers you may have will be related to current clients. Paper in this category include Non Disclosure Agreements, and Terms and Conditions. File the paper in the clients folder.

If a client says:

We don't jump in and look at the code and clean it up and reply with something like:

A better way is:

• Ask the client to tell us how slow it is (in seconds) and how fast they ideally would like it (in seconds)
• Add some code to record the time the function takes to run
• Reproduce the steps and record the time
• Change the code
• Reproduce the steps and record the time again
• Reply to the customer: "It was 22 seconds, you asked for around 10 seconds. It is now 8 seconds."

Also, never forget to do incremental changes in your tests!

For example, if you are trying to measure the optimal number of processors for a server, do not go from 1 processor to 4 processors at once:

Do it incrementally, adding 1 processor each time, measuring the results, and then adding more:

This gives you the most complete set of data to work from.

This is because performance is an emotional thing, sometimes it just *feels* slower. Without numbers, a person cannot really know for sure whether something has become quicker. By making the changes incrementally, you can be assured that there aren’t bad changes canceling out the effect of good changes.

Samples

For sample code on how to measure performance, please refer to rule Do you have tests for Performance? on Rules To Better Unit Tests.

Related Rule

• Do you keep your website loading time acceptable?
• Do you know the steps required to implement a performance improvement?

A great way of motivating your staff is to have some form of recognition in place; happy employees are good employees! One of the simplest ways to achieve this is by having a bell located within the office for employees to ring when they have made a large sale, secured a big deal or some important news to announce. By showing appreciation to your employees you encourage all your staff to perform.

At SSW whenever a big new project is signed up, we sell an enterprise license for one of our products, or we release a project into production we send an email to all staff and then ring the bell, which is located in the middle of the office.

You should always use a source control system!

It is not for a backup, it is because changing code can introduce new bugs. Often these bugs are non-obvious and appear in a part of the system, far removed from your changes. They are especially useful when another developer made the breaking change.

So source code tracking allows you to see what changed recently to introduce a new bug. This dramatically reduces the time it takes to find and fix a newly introduced error.

Integrate your source control with your bug tracking tool

Source control works best when integrated with a task tracking system. SSW uses and recommends Microsoft Team Foundation Server which allows you to check in changes and link to the work item (Bug or Task)... all from within Visual Studio.

Tip: If your systems are not integrated automatically, you can still integrate manually by convention. Just quoting the work item or bug ID in comments, whenever a source code change is committed.

Whatever you use, your toolchain/process/IDE should fulfil the following user stories:

There are a few things to look out for when signing legal documents:

1. Make sure there are no specific damages mentioned in any legal document. They should always be left to the relevant courts to decide.
2. Make sure the courts that would be adjudicating any conflict are local. (i.e. in your state or at least your country).
3. Lastly, for time and materials style software projects, make sure that there is a common understanding of how bugs are handled. i.e. there is no warranty on work done, as bugs are just a natural part of software development

Requesting a signature (or simply an initial) on non-contractual documents, such as screenshots, mockups, or data schemas, is valuable for several reasons.

It provides tangible evidence of receipt and agreement, especially beneficial for visual materials. It establishes a clear record of communication and collaboration, preventing potential misunderstandings or disputes. This practice also promotes a culture of accountability and ownership among teams or stakeholders.

Video: ''Michael Jackson rule"' Ask Clients for Approval | Adam Cogan (5 min)

A person's signature is extremely valuable. Getting a signature is hard work. Salespeople use all sorts of euphemisms to avoid that confronting request: "...if you could just sign here..."

The Signature Dance

Getting paper signed is the “Dinosaur Method”. These days there are 2 main scenarios:

• The "Checked by {{ NAME }}" system for when you are with the person or sharing screens with the person as per the 'Checked by' rule
• The "Test Please" system for when it's a big job or it needs to be done asynchronously as per the "Test Please" rule

When you ask a client to review a mockup for example, they will generally take a cursory glance, perhaps make a comment or two and then move on to something else.

Asking them to initial/sign the document/file always makes them take a second or third look, ask someone else, or at least spend a few more minutes working out whether it's correct or not.

Make sure you have a documented “Test Pass”. A verbal "Test Pass" is not sufficient and an implied "Test Pass" because you actioned their feedback is also not sufficient.

Training clients to review the work carefully leads to better quality projects.

There are many good reasons why it's better to work in pairs - enhance productivity, creativity, and problem-solving capabilities.

Whether it's brainstorming, coding, or tackling complex tasks, working in pairs often leads to more efficient and high-quality results.

For everyone

• Less time stuck on a problem - Having someone familiar with the project will help you work through the problem
• Mutual motivation and knowledge sharing - Keep each other motivated and absorb knowledge from each other
• Increased productivity - Experience shows that two people working on a problem together are often more productive than one person working alone for twice as long

For developers

• Code will have less workarounds - If something doesn't add up to a developer, they've got someone to ask
• Cleaner code - You know someone else is going to be looking at your code
• Support - When you need changes down the track, you have two people to call on

"I have found developers work better in pairs. I am not a fan of the classical pair programming - which is 2 developers working on the 1 PC. There are times for that especially during brainstorming activities, however on a day-to-day basis, I advise that developers work in pairs, but they each have their own PC."

- Adam Cogan SSW Chief Architect + Microsoft Regional Director

If you are not sitting next to a person working on the same project, then fix it. If you cannot then at least mention it to your manager.

Working alone and getting stuck

If you find yourself working alone, which we don't recommend, you should speak up as soon as possible. You should make it clear that working alone is not best practice and that developers working together are worth more than the sum of their parts.

1 dev plus 1 dev doesn't equal 2 devs worth of work. It equals 3! 🎉

Is there an overhead?

Some projects are done quicker with two people - especially when they are complex. But on most projects there is an overhead, because of the extra communication between the developers - you now have to please someone else - not just yourself.

Estimates vary for the overhead, but say it is 20% extra, this is more than offset by the cleaner code and better solutions that come from two brains working together.

What if you are working remotely from each other?

If you are working with someone remote, you will be using an application like Teams, TeamViewer, or another support tool to view one another's desktops so you can help each other out when necessary. You should have a 2nd monitor.

What is the best code collaboration tool?

Visual Studio Live Share - See Video (3 minutes):

• VS Code - Install extension
• Visual Studio 2022! It's built in!

Code With me - A great tool for JetBrains IDE users who want to pair program. Though it isn't supported in Rider right now.

Alternative approach when there’s not enough budget or work: weekly senior involvement

In situations where there isn't enough work for two people, or budget constraints limit resources, an alternative can be adopted. This approach involves a single developer handling the majority of development tasks, with a more senior developer contributing primarily on Sprint Review day. See below for an example:

The primary developer progresses the project mostly autonomously, while the senior developer's weekly involvement primarily ensures strategic oversight and quality control, particularly during Sprint Reviews. While the primary developer has greater autonomy, the availability of the senior developer for occasional guidance is crucial. This ensures the project remains on track and the primary developer does not feel isolated.

In a situation where we can’t even do the above, get cross-approval from another Account Manager to make sure the exception makes sense.

It is important to refer to your standards when trying to explain a concept. This process ensures you always give the most up to date information and that the documentation gets updated when needed. They will then know where the standard is so they can refer to it later.

When a new programmer on your team needs to get up and running on the SharePoint image you know the right and wrong way to say it.

Transitioning a project smoothly is crucial, whether due to changing project assignments or planned absences. A thorough handover process ensures continuity and minimizes disruption.

The handover is the responsibility of the person transitioning away from the project.

It's essential to initiate the handover planning as soon as a transition is known. Review the project with the selected team member who will take over, then schedule a handover meeting with high priority.

Tip: If you are leaving a company, ideally your handover should be done as soon as possible so that the developer taking over can start working on them while you’re still available to answer any questions.

Handover Checklist

Send this checklist in an email before the handover meeting to guide the discussion:

Ensure you reply done to this email after the handover meeting, with a checked by from the recipient.

For individual task handovers, see how to hand over email tasks to others.

There's nothing more exciting than having a holiday planned, but while you are away, the show must go on.
It's essential your responsibilities are handed over for a few reasons so your absence doesn't cause issues and your leave is undisturbed.

There are a number of things to remember to handover

1. Scrum Master/Product Owner roles - these roles are required in some meetings, so ensure they are covered or the meetings are rescheduled
2. GitHub CODEOWNERS - check you are never the only code owner on a area of the codebase
3. Induction approvals - ensure someone else is able to approve new staff inductions
4. Other employee responsibilities e.g. Organizing events, managing the office, etc.

All these handovers should be documented in an email, checked by the person taking over.

Instructions are very important when maintaining a project. When someone new joins the project, you want to make sure that they can easily find the documentation to do tasks like setting up the project and deploying it.

See the rule "Do you make instructions at the beginning and improve it gradually for web projects?"

That being said, the deployment plan is an important part of the Instructions.docx. It should clearly layout all the steps required to:

1. Deploy from scratch to a new server
2. Update versions
3. Rollback to a previous version
4. Update Schema or data

It should also include checks to verify the deployment was successful. E.g.:

1. Check zsValidate.aspx
2. Check runtime settings (e.g. Payment Gateways, Google Analytics, Connection strings)
3. Manual testing procedure (e.g. Place an order)

This document should also be signed off by the project lead and verified by the client.

Deploying on a Friday has traditionally been risky due to limited post-deployment support over the weekend, potentially leaving issues unaddressed. Thanks to DevOps best practices, these concerns are largely mitigated by automated deployments, continuous integration, and real-time monitoring, making the deployment process smoother and more reliable.

Nonetheless, caution is recommended in certain situations.

While it is best to avoid deployments on days with limited support availability, sometimes urgent updates like security patches cannot wait.

How to be prepared?

Pre-Deployment communication

• Inform the team about the deployment and ensure that support staff or relevant team members are available if needed
• Notify all relevant stakeholders, acknowledging that you and the team are prepared to fix issues over the weekend if they occur

Deployment checklist and best practices

Every project should have a document to cover each step of the deployment:

• Pre-Deployment: Ensure that all project components are up-to-date and tested before deploymen
• Staging Deployment: Test the application and check for any errors before moving to production
• Production Deployment: Proceed to production only after confirming no issues in staging
• Post-Deployment: Monitor for any new issues
• Troubleshooting: Outline key contacts for support and provide step-by-step actions to address issues

How to mitigate the risk of a deployment?

• Use Feature Flags: Implement feature flags to control the rollout of new features. This allows for quick disabling of problematic features without a full rollback
• Ensure Comprehensive Monitoring: Make sure all necessary monitoring tools are in place to quickly identify any issues. For instance, you can use Application Insights

Sometimes a client may ask for a small amount of time to be written off and may not have a good reason (from SSW’s point of view). Normally this would mean that the time would not be written off. However, sometimes, in the interest of continuing relationships with valued clients, some time may need to be written off simply to keep the clients happy.

This may seem counterintuitive since there is no logical reason to write off the time but in situations where it is necessary:

• Make sure you are not setting a precedent (“This is a one off” or “We don’t normally do this, but...”)
• Make sure you are not allowing yourself to be bullied (If the client seems entirely unreasonable or just expects a discount, they may need to be trained to our way of working)
• Make sure that the potential for more work substantially outweighs the amount of time written off
• Make sure that you are actually solving the problem, and not just giving a token gesture which may not fix the issue (e.g. just giving a discount as a way of placating a client who is unhappy about our project management methodology etc.)

Any time you come to some verbal arrangement with an employee, client or contractor, which creates or varies a contract (for example changes to rates, deliverables etc.), it's crucial you draft the agreement yourself.

Figure: Can you really trust the other side to draft the agreement correctly? Sometimes, especially if you are an efficient manager and enjoy delegating, it's tempting to ask the other party to write up the change. This is a major risk:

1. The other party may not even get around to drafting the agreement leaving you without a paper trail
2. If they do draft the agreement it may not accurately reflect the conversation

Take responsibility for any agreements you make. Draft them yourself and then send an email "as per our conversation".

Test, test, test! Testing is the most critical part of any project. You should get another set of eyes to check the work (aka conduct a "Test Please") before delivering the feature. This ensures the client has a great experience when receiving a quality application with confidence that it performs as expected.

Video: Test Test Test! | William Liebenberg | SSW Rules (2 min)

If you are writing code, your Pull Request (PR) is your "Test Please".
Tip #1: You should do an over the shoulder PR review
Tip #2: Embrace Proactive Testing – If you anticipate potential feedback on the User eXperience (UX) after your code is merged and deployed, ensure it is tested by a team member in the development environment. This will save tears when it reaches production.

If you are writing an email, a Checked By is your "Test Please".

If you are doing anything else (e.g. updating a Word doc or preparing a PowerPoint presentation), you should still get a 2nd set of eyes to check the work and document it somewhere.

Note: If the test to be performed is quick and the tester is available on the spot, consider using a "checked by" style instead to save some time.

Having a documented process for managing engagements provides clients with a consistent experience. It also helps to get new employees up to speed quickly, and provides a reference to existing employees to ensure no steps are accidentally missed.

An engagement lifecycle overlaps with a sales pipeline, and maps to the 8 Steps to Scrum.

1. Initial Phone Call

   • The client has made contact but no initial meeting has yet been made

2. Initial Meeting - Booked

   • Sales team has arranged an initial meeting and it's booked in.
   • The Initial Meeting is a non-billed meeting that maps to the Initial Meeting described in the 8 Steps to Scrum. It is attended by a Sales person and ideally a Solution Architect.

3. Follow Up Meeting - Booked

   • In some cases, more than one initial meeting may be required before work or speccing commences.

4. Specification Review Proposal - Waiting for Approval

   • After the Initial Meeting, if the work requires it, a Specification Review is proposed.

5. Specification Review - Booked

   • The Specification Review meeting has been approved and booked in.
   • The Specification Review is a billed meeting with the customer to review existing specifications, understand specific goals, risks and relevant technologies appropriate for the solution, and create the initial backlog.
   • During the Specification Review, the Solution Architect prepares a document, presentation, or video outlining the results of the Specification Review, as per Spec - Do you effectively present the outcomes at the "Specification Review presentation"?.

6. Project Proposal - Waiting for Approval

   • After the Specification Review, the client is given a proposal for a chunk of work. Once this is approved, the Sales Team closes the opportunity as 'won'.
   • Proposal is sent to the client including financials and the result of the Specification Review.

7. Project Execution

   • The Scrum process runs, starting with the first Sprint forecast email, as per Do you create a Sprint Forecast? (aka The functionality that will be developed during the Sprint)

8. Project Closure

   • Project is completed, any handover or other transition that has been defined is completed with the client.
   • Just like a Sprint Retrospective is held at the end of each Sprint, a Project Retrospective is held to learn from the project that has just completed.

Testing is a fundamental aspect of software development, serving as the quality assurance checkpoint that ensures a product functions as intended, meets user expectations, and operates reliably in various environments. This crucial phase helps identify and rectify issues, enhances user satisfaction, and ultimately safeguards a software's reputation and success.

These are the steps you should take when requesting a "Test Please":

1. Find 2 free testers to send the email below
2. Stop working on the project until you receive either a "pass" or "fail" email
3. Create your "Test Please" following this template:

Don't send a 'Test Please' content via IM

You may use IM (e.g. Microsoft Teams) to point the tester to the 'Test Please' email.

What if you are doing an email test?

In most cases, you can get your email 'Checked by xxx'.

For really important stuff you may need to actually send a 'Test Please' email to test your email. In these cases:

• Add 'Test Please' highlighted in yellow to the top of the email body
• Do not add 'Test Please' to the subject (it is too easy to forget removing it later!)

What if you need to get input from a few people?

If you have received a task that requires input from a few people that were not originally cc'd on the email or on the 'To Myself', like getting feedback on a design, it's nice to give everyone the entire task context.

You have 2 options:

1. Keep the "test" in the same thread (recommended)
   In this case, just add the people you need to the thread, asking them specifically for a 'Test Please' on what you need
2. Create a new thread for the 'Test Please' This is for when you have a good reason not to (e.g. avoiding too long email threads; too many people cc'ed, etc). In this case, make sure you include the original thread subject in your email, so people know the main task is happening there

This way everyone will have the entire history of the task and its progress.

What if you're doing a Windows Forms test?

For Windows Forms test you should include this info to the email:

• The latest version of {{Product Name}} has been uploaded to \frog\SSW\Download[ApplicationverX-XXbeta.exe
• Test on a fresh VPC image of Windows
• Install into a non-default directory
• Check the installation folder for misplaced items
• Test Unit Tests via "Help - Run Unit Tests"
• (If Applicable)Test the "Create" and "Reconcile" buttons. Read Rules to Better .NET Projects
• Test open and closing forms and saving values
• Test most buttons and menus and links
• Disable your network connection and test again (check for unhandled errors)
• If your test fails, please rename the executable to ApplicationverX-XXfailed.exe

Don't let your client find bugs in production that they would have found if you had asked them to do a 'Test Please' 1stBetter still... Don't let your client find bugs that your internal tester would have found.Better still... Don't let your tester find bugs that a tool could have found?

So, prior to a version being submitted to the client, these are the 4 steps you should follow:

1. Perform automated testing with tools:

   • SSW Link Auditor (for Web Apps)
   • SSW Code Auditor (for all Apps)
   • SSW SQL Auditor (for all Apps with databases)
   • SSW SQL Deploy's Reconcile (for all Apps with databases)
   • Visual Studio Team System Code Analysis (optional)

2. Perform automated testing via Unit Tests

   • xUnit, or
   • nUnit
3. Perform an internal "Test Please" (aka "Alpha Testing" e.g. only testing that pages or forms load, not checking the business rules)
4. Then send a "Test Please" to the client (aka "Acceptance Testing" to check the business rules)

OK, once a project gets going, you can end up dealing with many people on the client side. From the Boss to the Business Decision Maker (we call them the "Product Owner") through to Mary the receptionist (aka "users"), everyone has something to say about the software as it is being developed. However, when you are working on a Time & Materials basis in a rapid development environment with continually changing specs, you have to be certain that the work you are doing is authorised by the person who signs the cheques.

Figure: Sample Change Request Confirmation email

So, say Alan from Accounts would like the Username and Password authentication to have a "remember me" checkbox for the Accounts module. This sounds reasonable, but it doesn't mean that you should charge right in and start coding.The following is the recommended approach to governing this process:

• At the beginning of the project an employee from the client is assigned as Product Owner. This person has full authority as to what work is "in" or "out". Every new item of work should be visible to the Product Owner. (CC is your friend, @mention is your friend)
• Whenever someone who ISN'T the Product Owner makes a request for work, the Product Owner must be CC'd. For example, if Mary the receptionist has not done this, the developer sends the email again to himself, and CC's the Product Owner (and of course other relevant people).
• Note: The assumption is made that the task is good to go, so it is the Product Owner's responsibility to reply ASAP if they don't want the problem fixed.

Companies have a lot of information and standards – some of it is public (company blog), some of it is private (company intranet). When there are thousands of documents, new employees should be given a guided process so they know what is important.

When someone joins a company, it is a stressful event... they have to remember people's names, references to where things are... there is a lot of assumed knowledge and explanations of "this is how we do things".

New employees often get inconsistently onboarded depending on who they got their initial information from.

An induction system is a way to solve these problems.

---

SugarLearning

SSW uses and recommends SugarLearning.com.

SugarLearning aggregates your learning experience into one space to make it easy for you to complete your induction. The learning process is broken up into reading, quizzes, and email tasks that are presented in a logical order.

SugarLearning is a great continuous learning tool that shows employees where to find relevant information. It is especially useful when a process changes, as a learning item can be invalidated, and all employees informed to complete the revised task.

Completing the sugar learning modules gives each employee a better understanding of what is expected of them when working in the company from the first day.

What's what at SSW?

SugarLearning is an induction program for things you must complete before starting work... E.g. Before you do a Spec Review, you must have done the Module - Spec Review. It’s like getting your license.

The SSW Intranet is the location of all information, standards and "how-tos" that must be private. In some projects we have specific Wikis for those too.

SSW Rules is where we kept all information, standards and "how-tos" that can be public.

- Adam Cogan

As per rule "Do you have separate development, testing, and production environment?", it's better to use different background colors to identify Development, Test and Production servers.

CRM

The way to change the default background color is to edit the CRM CSS files. These changes aren't supported and may be overwritten when CRM Rollups are applied.

CRM 2015 and CRM 2016

Using theme feature to change the environment color.

CRM 2013

Edit {{ CRM WEBSITE ROOT }}\_controls\navbar\navbar.css:

.navigationControl {
  background-color: #006600;
  margin: 0;
  z-index: 999;
  float: left;
  width: 100%;
  position: relative;
}

Figure: Edit the background color to reflect the environment

CRM 2011

Edit {{ CRM WEBSITE ROOT }}\_static\css\1033\cui.css, locate and modify the section ms-cui-tabBody so that it reads:

background-color: #ffffff;

Change color to a suitable color for the environment:

background-color: #bbffaa;

CRM 4

Edit, {{ CRM WEBSITE ROOT }}\_common\styles\global.css.aspx

body.stage
{
    <% if (CrmStyles.IsRightToLeft) { %>
        dir:rtl;
    <%} %>
    border-top:1px solid #6893cf;

    /* background-color: #d6e8ff; */

    background-color: #ffff00;

    padding: 4px;

    /* background-repeat: repeat-x;

    background-image: url(/_imgs/app_back.gif);
    */
}

Figure: In C:\Inetpub\wwwroot\\_common\styles\global.css.aspx comment out and change the reference in yellow so the users know what server they are on

SharePoint Online

In SharePoint Online, we use Theme colours to differentiate between Production and Development environments.

To change the Theme, simply navigate to Site Settings | Change The Look | Theme

Development - Default Microsoft Blue Theme

Production - SSW Custom Theme

More about SharePoint Online custom themes: https://learn.microsoft.com/en-us/sharepoint/dev/general-development/how-to-deploy-a-custom-theme-in-sharepoint

When you've finished a PBI you should record a video to send to your Product Owner and anyone else that is interested. A 'Done' video is much better than a screenshot because you are proving the PBI workflow actually works. Even better, this video can double as documentation or release notes for your users.

When deciding whether a PBI might be a good contender to record a Done Video for, consider these factors:

1. Is it a key piece of functionality that has high business value?
2. Would it be difficult to quickly demo in the Sprint Review without a video?
3. Is it UI heavy? i.e. Would the video be compelling?

For a quick and dirty 'Done Video'

Your done videos should follow the following format

1. Intro

   • Prepare and practise your talking points and visual elements
   • Start with a medium close up shot of yourself
   • Start with a smile the camera for 2 seconds before speaking
   • Briefly introduce yourself e.g. first name, role, "from SSW"

2. Post-intro

   • Transition into a screen share with the solution you've created on screen, moving your portrait shot to the bottom right corner of the screen
   • Provide an overview of the PBI you are going to discuss, remembering to zoom out before showing code samples or demos (see rule - Do you zoom out then in)
   • You should start with the tabs you are planning to use open

3. Show the Pain

   • Explain the problem you or the stakeholder was having before you finished your work
   • Show a example of where this issue occurred

4. Demo the solution

   • Provide a working example of your code
   • Demo the code with a realistic use case
   • Direct attention and give people an idea of where to look
   • Harken back to the pain showing the value of your solution

5. Outro

   • Transition back into a medium close up shot of yourself
   • Provide a brief summary of what you discussed in the video
   • Use a signature to bid farewell to the audience (e.g. you could say "This is Bob Northwind signing off")
   • Hold eye contact and a smile to the camera for 2 seconds before the video ends

Here's a video describing how to record and edit a quick Done video using Clipchamp:

Tip: Jump to 04:31 for how to record screen and webcam.

Video: BEST Clipchamp Video Editing Tips and Tricks (14 min)

Here's a video describing how to record a quick Done video using OBS:

Video: How to Record your Computer Screen & Webcam in OBS Studio (8 min)

Note: The Picture in Picture will be permanently embedded in the exported video and cannot be altered later.

For a more professional video that requires some editing

Here's a quick video describing how to record your webcam and screen separately in high-resolution using OBS for post-processing and editing:

Video: How to Record Webcam and Game Separately in OBS Studio | Tutorial (10 min)

Note: You will be able to alter the PIP, remove it, go full screen on your face.

Switching Scenes in OBS - it is quite easy to do with these simple steps using OBS Hotkeys!

Video: How To Switch Scenes In OBS Easily! (OBS Hotkeys) | Tutorial (4 min)

Presentation

1. Apparel - If your company has branded clothing, make sure it's ironed, tidy and visible. Wear it proudly! Alternatively, wear clean, neutral color clothing. E.g. White, grey, or black shirt
2. Framing - Have your webcam height at eye level for engagement. Make sure there is sufficient headroom: not too little (don't cut off the top of your head in the frame) and no too much (the subject needs to fill the frame). Ensure your branded clothing is visible and the background is clean and tidy, also consider tilting the camera for a more dynamic background with depth instead of a flat background.

3. Lighting - Ensure there is optimal room lighting and facial brightness. Consider a ceiling-pointing lamp for additional light. Avoid intense backlights to prevent silhouetting.
4. One-Take - Record it in one take, but start again if it's super bad. If something out-of-your control happens, try to be natural! If you mistype a word or click the wrong button, don't freak out and start again, incorporate it. E.g. "Whoops, clicked build accidently. Let me just refresh and go again."

6. Clean UI - When using a browser, IDE, or any relevant application, ensure a clean interface:

   • For your browser, hide the bookmarks bar and set the zoom to 125%. (You can easily get a clean browser by using a guest or incognito profile)
   • If presenting in Microsoft Office, hide the ribbon.
   • When using Outlook for presentations, clear any irrelevant reminders.
7. Resolution - Set your screen to 1080p (1920x1080).
8. Recording - Record both your screen and webcam.
9. Audio - Check your audio devices for the best quality and make sure your audio is clear and not distracting. E.g. Position the microphone close to your mouth.
10. Be Friendly - Interact with your webcam like it's a person, and smile at the Intro and Outro.
11. Do a Test Recording - After all this effort to capture a great video this can catch any last-minute changes and cut down on potential re-recordings. E.g. Test your Intro hook and screen transitions.

Remember to watch some "Done" videos to get an idea of what a good "Done Video" looks like!

Learning a new technology is something a developer has to do at least every few years. The industry landscape is constantly changing and to keep up and the developer has to really master the art of learning.

Over the years, SSW has trained thousands of developers and we have found that the best way to learn is through mentorship. Mentorship is when an experienced developer teaches and codes with their mentee. By working closely together on a regular basis they are able to impart their knowledge and experience into the mentee.

Of course, there are other ways of learning and the chart below discusses the effectiveness of each.

Your employees are your greatest asset, yet their valuable knowledge and insights often go unnoticed. Why not harness their creativity and problem-solving abilities by hosting a fun and collaborative Brainstorming day? It's a simple but effective way to unlock innovative ideas, foster team bonding, and empower your workforce. 🧠💪

Video: How we use the "Brains" of our company - SSW Brainstorming (1 min)

Employees on the front line often have valuable insights into opportunities for improvement, what is painful, increased efficiency, and even entirely new business ideas. Empowering these employees with an annual Brainstorming day is a great way to transform their good ideas into valuable solutions, as well as giving them the opportunity to learn and grow from each other. Also, many employees enjoy the opportunity to flex their creative muscles in fun ways that their day-to-day jobs may not always afford them.

Different companies have different approaches to this. For example:

• Atlassian - Give employees 1 day a year to work on a feature they want
• Google - Employees are allowed to dedicate 20% of their time to 'pet projects' (subject to approval)
• Microsoft - Scott Guthrie takes senior leaders offsite for 1 week each year
• SSW - Adam Cogan conducts an annual Brainstorming day in each state office

Video: Empowering Employees Through Brainstorming (3 min)

Sometimes you get the same task from 2 different people. Sometimes even the same person sends over-lapping emails. Sometimes you find duplicated PBIs.

Whether you keep a backlog or are just using your email inbox as a to-do list, you have a choice to make:

A: Get rid of the duplicates and only keep one (you need to spend time informing everyone about the merge)

B: Recommended - Keep them all and when you do it, reply to all the emails with your ‘Done’ OR close each of the PBIs. (Of course it is a good idea to relate those tasks by adding links or the email subjects)

Open-sourcing software has become increasingly popular for companies as it can help them innovate, attract talent, and build a good reputation. It also helps the community by providing free software that can be used by anyone.

Some good examples of companies that open source their code are:

• RedHat
• Microsoft
• Google
• Netflix
• AirBnB

🧱 Collaboration

Open-sourcing opens your project to a broad range of people with unique skillsets can help accelerate your project's innovation. It also allows you to leverage the work of others to help your project grow.Every time someone submits a PR fixing a bug, you are getting free software development.

🔗 Networking

Being a part of the developer community is a great way to discover potential employees. If a developer has been using a company's open source code for years, they are more likely to want to join and keep using that code.

👨‍🏫 Demonstrate

Making your code public shows confidence in your service and can be a great oppurtunity to demonstrate your company's skills and practices.

🤝 Sharing solutions

Open-sourcing your code doesn't have to mean making your whole project public. You can take small chunks of code and make them generic enough so they're useful to others.
Examples of this are:

• jsakamoto/Toolbelt.Blazor.HotKeys - This repo contains a small library that allows you to add hotkeys to your Blazor apps

Before any project can be used by a customer it must first be published to a production environment. However, in order to provide a robust and uninterrupted service to customers, it is important that the production environment is not used for development or testing purposes. To ensure this, we must setup a separate environment for each of these purposes.

Skipping environments in a feeble attempt to save money will result in untested features breaking production.

What is each environment for?

• Production: Real data being used by real customers. This is the baseline/high watermark of all your environments. Lower environments will be lower spec, fewer redundancies, less frequent backups, etc.
• Staging: 'Production-like' environment used for final sign-off. Used for testing and verification before deploying to Production. Should be as close to Production as possible e.g. access (avoid giving - developers admin rights), same specs as production (especially during performance testing). However, this is not always the case due to cost implications. It is important that staging is 'logically equivalent' to production. This means having the same level of redundancy (e.g. Regions + Zones), back-ups, permissions, and service SLAs.
• Development: A place to verify code changes. Typically, simpler or under-specified version of Staging or Production environments aiding in the early identification and troubleshooting of issues (especially integration).
• Ephemeral: Short-lived environment that is spun up on demand for isolated testing of a branch, and then torn down when the branch is merged or deleted. See rule on ephemeral environments.
• Local: Developer environment running on their local machine. May be self-contained or include hosted services depending on the project's needs.

What environments should I create for a new project?

Large or Multi-Team Projects

For large projects it's recommended to run 4 hosted environments + 1 local:

• Production
• Staging
• Development
• Ephemeral (if possible)
• Local

The above is a general recommendation. Depending on your project's needs you may need to add additional environments e.g. support, training, etc.

Internal or Small Projects

For smaller projects we can often get away without having a dedicated development environment. In this scenario we have 2 hosted environments + 1 local:

• Production
• Staging
• Local

In the realm of productivity and task management, there's a common tendency to avoid the most challenging tasks, often due to the discomfort or fear associated with them. However, it's these challenging tasks that are frequently the most valuable. Tackling the hard things first not only ensures that these valuable tasks get the attention they deserve but also sets a precedence for working sequentially and methodically through your to-do list.

The Value in Hard Tasks

Hard tasks often represent the most significant opportunities for growth, learning, and contribution to your project or organization. They are typically the ones that require the most thought, creativity, and problem-solving skills, making them inherently valuable.

Strategies to Tackle Hard Tasks First

1. Identify the Value

Recognize the value and impact of the hard tasks. Understanding their importance can motivate you to tackle them head-on.

2. Reframe Your Mindset

Shift your perspective to view these tasks as opportunities rather than obstacles. This can reduce the mental barrier to getting started.

3. Break Down the Task

Divide the task into smaller, more manageable parts. This can make the task seem less daunting and more approachable.

4. Create a Sequential Plan

Plan to work on tasks in a sequence that prioritizes the hard tasks. This approach ensures that you address the most critical and valuable tasks when you are most fresh and focused.

5. Set Specific Goals

Define clear, achievable goals for your hard tasks. Knowing exactly what success looks like can help you maintain direction and focus.

6. Seek Support When Needed

Don't hesitate to seek help or collaborate with others on difficult tasks. Sometimes, a fresh perspective or additional expertise can make all the difference.

7. Eat the Frog

Eating the frog is a tactic that is especially effective if you struggle with motivating yourself to do hard tasks. Here's what it involves:

1. Identify the frog - Find the hardest task in your backlog (aka the frog)
2. Eat it - Do it as the first task in the morning
3. Repeat - Eat the frog everyday

Conclusion

By focusing on the hard tasks first, especially in a sequential work process, you ensure that the most valuable contributions are not sidelined by easier, less impactful activities. This approach leads to more meaningful progress and a greater sense of achievement.

It is really important to understand the difference between a Proof of Concept (POC) and a Minimum Viable Product (MVP). It is also important that clients understand the difference so they know what to expect.

POC: Proving Feasibility

A POC is developed to demonstrate the feasibility of a concept or idea, often focusing on a single aspect of a project. It's about answering the question, "Can we do this?" rather than "How will we do this in production?" POCs are typically:

• Quick and focused: Developed rapidly to test a specific hypothesis.
• Experimental: Used to validate technical feasibility, explore new technologies, or demonstrate a concept.
• Disposable: Not intended for production use; often discarded after proving the concept.

POCs should be built, tested, and thrown away. They are not intended to be used in a production environment.

MVP: Delivering Value

Conversely, an MVP is a version of the product that includes just enough features to be usable so stakeholders/users can provide feedback for future product development.

• End-to-end functionality: Covers a single feature or user flow in its entirety.
• Production ready: Developed with more attention to detail, as it will be used in a live environment.
• Foundation for iteration: Serves as a base to gather user feedback, validate assumptions, and guide future development.

Examples

Consider a startup exploring the use of AI to personalize online shopping experiences. A POC might involve creating a basic algorithm to recommend products based on a user's browsing history, tested internally to prove the concept's technical viability.

Building on the POC's success, the startup develops an MVP that integrates this personalized recommendation engine into their shopping platform, deploying it to a segment of their user base. This MVP is monitored for user engagement and feedback, shaping the future roadmap of the product.

Best Practices

• For POCs: Clearly define the concept you're testing. Limit the scope to essential elements to prove the hypothesis. Remember, POCs are not mini-products.
• For MVPs: Focus on core functionality that delivers user value. Engage with early users for feedback and be prepared to iterate based on what you learn.

When offering support to customers using your product, think about whether this problem has occurred before or could happen again. If it has, there should be documentation available. This not only helps customers resolve their issues faster but also reduces the repetitive workload for the support team.

You should never have to answer the same question twice.When you get a new question e.g. "Can I do validation in TinaCMS?" these are the steps you should follow

1. Check for existing documentation.
2. If it doesn't exist, create the documentation.
3. Reply with a link to the documentation.

Every support message should include a link to the relevant documentation or, if applicable, to a Product Backlog Item (PBI).

Sometimes, you might get questions about bugs, upcoming features, or other things that are not documented. In this case,

After a while, you will build a great library of documentation that customers will use to self-serve their questions. This practice will also get you to read your documentation and improve it more often.

Exceptions to this rule:

• Do not write a documentation page if fixing the bug and releasing a new version solves the problem. In this case, create a PBI (or find an existing one) and reply with the link to it.
• Do not write a documentation page or PBI if the question/answer is irrelevant to your product, e.g., "Next.js - how do I deploy my app?" (This is not relevant to TinaCMS.)

🤖 AI Tip: Consider training a chatbot on your documentation to help answer common questions automatically. Learn more about implementing a chatbot