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

• Improve productivity - because there are less decisions to make, and you build on existing work.
  For example, we don't need to discuss the pros and cons of MDI versus SDI because there is already a standard.
• Improve quality - because you are following best practices.
  For example, which logging library is better out of Microsoft Application Block or Log4NET.
• Improve communications - because people know what to expect.
  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 on whether we call it a bug or a feature because we define what's a bug.
• Get straight to the meat of the customer's problem.
  For example, our developers don't need to decide whether to implement baseforms or user controls. They already know because it's covered in Rules to Better Windows Forms Applications.

At SSW we create standards for all manner of processes: from coding practices to project proposals and how to lock the office up at night. From the developer's perspective, consistency means that we understand each other's code, and if we don't know something, a standard will often save us asking someone. 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 gave an inconsistent experience. Excerpt from "The E Myth" page 10

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 look out for improvements. That's why standards should be shared with everyone.

Don't give ranges! Let's say a prospect asks me "how much to do this Release?" I could say - "Somewhere between $15k - $20k". I hear 20, the prospect hears 15. 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 in 12. So I never give a range to a client. I tell them that the first Release, along with its spec is likely to take $35k. That's two guys working full time for two weeks.

Be upfront about bugs I don't believe there is such a 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.

Fixed prices don't solve anything: 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. I recommend fixed-prices in Releases of no more than 3 weeks (1 - 2 releases) development 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.

Talk dollars at the first meeting: 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. What makes this consultant think that if the client is unhappy to receive an invoice now, they'll be happy to receive it in two months? We 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.

The first kind of approach is where you try and seal the whole deal in one go:
    "I think we would work well together, would you like to get married and have two children?"

The likely response would be:
    "Get lost you loser."

The second and more appropriate approach would be to ask something like:
    "Would you like to have coffee together?"

You have a greater chance that your prospective partner will say "yes"...

Unless you are a great salesperson, who has constant exposure to new clients, then I suggest you use the 2nd approach. Clients are likely to be frightened off with huge quotations from vendors that they have not got trust in, so avoid this by segmenting the project into smaller projects. It reduces risk for the client.

For example:

Figure: Bad Example - asking a client to get married after the first date. This is likely to be too big a figure for them to risk on for their first taste of your work

Figure: Good Example - a client is more likely to appreciate this approach, they get a choice + they are given an option of proceeding with a small project. There are prospects of continuing the relationship based on how well the previous project goes.

1. Enforce Deadlines - Every week (usually Tuesday) the developer has a meeting with the client to discuss the status of project.
   Note: If you can't have a meeting, a phone call must make do.
   Note #2: A weekly status update report (if the release is not yet complete). 
2. Have a project release plan - ideally a signed copy of the Release Plan in their diary.
   Note: A printed copy of the email with "Approved" is fine.
3. A debrief when the release is done.
4. A mark /10 - from the client.  
    

In respect of the debrief, when thing have gone off the rails, it is easy to speak your mind and say what you believe went wrong. However often when things are going right, the tendency is to skip the debrief thing, with a comment 'all is good'.

A better idea is to figure out 'why are things are going right?', and work out how you can repeat it. For example, if your client calls and says,

    "We think Dan has shown very professional conduct and has delivered a high-quality solution"

you should look at how the project was run. Was the solution high-quality because your developer is a faster coder, or good at following your coding standards? Or was his professional conduct due to lots of customer interaction and polite and clear communication?

Of course, if in your release debriefing, if you find that the client is unhappy due to bad conduct, scope creep, or poor quality code, you need to check that your standards are being followed to ensure a positive experience in the next debriefing.

1. Status of original work items - are they all done?
2. External Test Please - go through the application and get the clients thoughts. Many issues they see, will already be reported by the internal "Test Please". Send emails for the new ones.
3. Triage these additional work items - try to move all to the next release
4. Approval for additional work items/budget overruns - talk $$
   eg. look at the "Actual" and "Estimate" figures on the top of the report
5. Release sign-off - "Yes" or "No"?

If "Yes"

1. Ask the client for a mark /10 for the release
2. Ask the client if you can do a deployment to Production?
3. Ask for Approval for next release  

There are tools to help you do this:

• SSW TFS Add-in - Release Update/Debrief Report

Figure: The actual output of the Release Update Report

Here is a PDF format SSW Release Upd​​ate Report.

If you are at the end of a main section of work, promote your success

• Ask for a testimonial for the work you have done
• Create a case study and get it approved - This should be a win-win for the client. eg.  WorleyParsons
• Add a link to the work you have done from your website or marketing material. eg. at SSW we do this via the Our Clients page

A software issue can be classed as a bug where: 

1. The application crashes to code (excluding bugs resulting from third party products (e.g. "blue screen of death" or crashing in a third party data grid that we cannot control); or
2. The application displays data inconsistent with the specified business rules; or
3. The application is missing functionality specified in the specification; or
4. The page design/layout is substantially inconsistent with the agreed mock-ups

and the developers can reproduce the above on the test server and the application is not yet "live" and the issue has been reported in time (generally 30 days).

1. The application crashes to code because it doesn't check that a connection is valid before running a stored procedure (this is likely covered because it crashes to code)
   
   Figure: Yellow screen of death
2. A sum total is negative instead of positive because the wrong operator (plus instead of minus) has been used to calculate the running balance (this is likely covered because data is inconsistent with the specified business rules)
   
   Figure: An incorrect sum is likely to be a bug
3. The application is missing the Monthly Sales report (this is likely covered because the application is missing functionality specified in the specification)
4. The output HTML in the application is formatted way out of line and does not display in the specified browser (e.g. Internet Explorer 9) (this is likely covered because it substantially inconsistent with the agreed mockup)
   

1. Any problem caused by software or an application not written by the organization supplying the software.
2. The customer requirement was not included in the user interface/mock-ups/specifications.
3. The client decides that they don't like the look of the current form even though it is the substantially the same as shown in the specification and wants the buttons at the bottom of the form instead of at the top.
4. The original specification states that the total price excludes GST, but it really should have included GST. This is a change to the specification, and is not included in the contract.

Work items in TFS

Using TFS allows you to create work items such as user stories, bugs, tasks, test cases etc. Only create bugs in TFS for defects, faults, flaws, or imperfections that fulfill your definition of a bug. For everything else use other work item types.

Figure: Do I create this as a bug, or a task? 

Handling additional work for fixed-price contracts

Any new features or modifications (non-bug items) not in the original release plan are classed as additional work and are outside the scope of the contract. Any tasks which are bugs should be marked as additional items and be completed in the current release if possible. Most importantly, after the release plan has been sent, a task should NOT be entered as an item (additional or otherwise) in ANY sprints if they are not a bug. Instead, move all non-bug items to the product backlog for future review after the warranty period for the fixed price contract has passed.

Handling additional work in a Scrum project

Any new features or modifications (non-bug items) not in the original Product Backlog are classed as additional PBI's and placed on the Product Backlog. Any tasks which are bugs found during the current Sprint should be fixed within the current Sprint. Any tasks which are bugs found outside of the current Sprint should be added to the Product Backlog.

Figure: Adding a bug to the Product Backlog in TFS Preview (TFS 2012)

If you see a bug in any software product, e.g. SSW Code Auditor, it is best to report the issue following the steps outlined the SSW Bug or Enhancement Reporting Standard.

1. Set the expectations early. Let the client know what to expect in terms of communication. For example:

   "Hi Bill,
   We will run your project in an agile manner. Expect emails and phone calls that we need responses to. These are examples:

   • The first step - we will send you a release plan to approve. Once approved we can begin work
   • Every morning - expect a 'Stand up meeting' call or 'Morning Goals' email with a list of tasks the developers will be working on that day
   • Every time a task is done - you will get an email with information about what was done, often with screen shots and code snippets"
   • If you need to change the priority of a task - email us and we will consider it for inclusion either the next release, or a subsequent one, depending on its importance"

   Avoid going more than 3 days without a phone call to your client.

2. New Resources - If you are put onto an existing project, it is good practice to call the client and introduce yourself. For example:

   "Hi, I'm Andrew. I'll be taking over from Mark on your project. Mark has filled me in on the specifics and I'm keen to get involved."

If you use the phone instead of email when it is appropriate, you maintain an open channel of verbal communication with your client. This helps to break down communication barriers, lets the client know that you are friendly and involved, and makes them feel confident in your ability to deliver the project.

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.

As an example, this is how we govern this process:

• At the beginning of the project one of the client staff is assigned as Product Owner. This person has full authority from the Business Decision Maker of the client as to what work is IN or OUT. Every new item of work must be authorized by this Product Owner.
• Whenever someone who ISN'T the Product Owner makes a request for work, the Product Owner must be CC'd. If Mary the receptionist has not done this, the developer sends the email again to himself, and CC's the Product Owner (CC'ing other relevant people - if they may give feedback on the task) to let them know about the request.
• We make the assumption that the task is good to go, so it is the Product Owner's job to make sure that they reply ASAP if they don't want the problem fixed.

The most popular and most successful way to deliver projects is using a specific 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, the first to get an overview of the project, the second, to focus on the detail of first few releases only:

• Spec Review, or Initial Release Plan
• Detailed Release Plan - this phase is repeated through the project

Storyboarding actually is done in movies a lot.

There are five primary types of mock-ups:

1. Hand drawn Mockups
2. Wireframe Mockups
3. Developer HTML Mockups
4. Designer HTML + CSS Mockup
5. Designer Photoshop Mockups. (recommended)

Often it's best to start with some hand-drawn ones to get started. Then if you have access to designers, complete a couple of full 'Designer Photoshop Mockups' for look and feel approval, then complete the balance as wireframes.

1. Hand drawn Mockup

   'Hand drawn Mockups' are recommended to be done with the customer. Since it doesn't deal with any styling/color issues, 'Photoshop Mockups' will be needed after.

   Figure: A 'Hand drawn mockup' example. It should recommended to do with customer, however doesn't deal with any styling/color issues, so Photoshop Mockups are still needed.
2. Wireframe Mockup

   A layout of how the controls will look is usually all that is needed initially, without worrying about images. An example of Wireframe Mockup

   Figure: Wireframe mockup example - not recommended as it completely thrown out.
   Tip: The tools to develop a wireframe depend on your skillset and the front end technology chosen. For example use:

   • Photoshop (primarily for designers who already have the skills)
   • Balsamiq (the most widely used tool)
   • Sketchflow (required if the frontend will be a Silverlight or a WPF application - read Do you use Expression Blend + SketchFlow to create mock-ups? for further information)
3. Developer HTML Mockup

   These are mockups done in the front end technology that will be used. Meaning it could be done as a Web/Windows Forms/Access UI with limited functionality:

   An example of an ugly Developer HTML Mockup
   Figure: Developer HTML Mockup example - not recommended as it is a bad starting point from a HTML view and refactoring later is harder (if even possible) + this reeks of Bodgy Brothers and doesn't do a very good sales job
4. Designer HTML Mockup

   These are also mockups in a Web/Windows Forms with full CSS Styling and graphic designer enhancements:

   An example of a pretty Designer HTML Mockup
   Figure: Designer HTML Mockup - not recommend because it is time consuming to make changes (and change is all you do at the beginning of a project)
5. Designer Photoshop Mockup

   These are concept mockups produced by designers in Photoshop providing a guidance of the final look with full styling.

   Warning: Don't go down the track of giving a customer a few concepts (on some projects we gave 2 or 3 completely different concepts by different designers). There becomes too much mixing and matching when they see them. Once the images are approved, then the designers slice them up and turn them into HTML (slicing is the exporting of each image)
   Figure: Designer Photoshop Mockup example - recommended as quick to change, when changes happen

   More information – Add notes at the bottom

   Wireframes should include numbers and notes at the bottom, explaining features and/or indicating priority.

   Figure: This wireframe indicates priorities of features Mock-ups notes should also include the business rules that apply to the page. If there are a lot of rules then it is acceptable to link off to a Microsoft Word document.
   
   Figure: Good Example - This mockup states the validation and business rules that apply to the page

Don't use UML - it is virtually impossible to get clients to understand these.

Figure: Don't use UML diagram which clients can't fully understand

A great way we get feedback on upcoming projects is by putting our specs of upcoming projects on the web and inviting user comments - not forgetting to acknowledge their contribution. Often Surfers 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 two days looking for similar products and speaking to users about the features. Since the specs are full of screen captures, this allows us to think of our end-users and increases the likelihood of creating a great product which our users love.

Who comes first? The Technology or the User? I even wonder about Microsoft, they've built this great .Net technology which works fine in Notepad but now we're waiting for the Visual Studio interface. They are going to shoehorn a user interface and experience onto the framework so the user experience is likely to be a compromise. What great products are designed this way? Do tailors measure their clients after the suit has been sewn together? I'm sure Microsoft spend heaps of time and money discussing the specs amongst themselves, but I believe they should've put the interface/Images on the web so that experienced users could voice their opinion and offer suggestions early in the product cycle. Instead we wait for the beta versions - if you offer a suggestion now, there is no time for it to be implemented as the shipping deadline is too close. The only contribution we can make at this stage is finding bugs!

So balance engineering, business and usability, put your specs on the web, keep them updated with changes, and listen to your users!

The main choices for CRM solutions are:

• Salesforce
• Microsoft CRM

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

But, we still have a couple of feature and software suggestions for Microsoft CRM

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

In software development it is highly likely that someone else has encountered the same problem you have, and if so, they may have posted the solution on the web or even compiled a very handy 3rd party utility which fixes the problem for you.

Whether you are writing specs, providing support or developing a new solution search the following 3 sites for the answer:

1. Google Groups http://groups.google.com/ 
2. Google Search http://www.google.com/ 
3. Microsoft Knowledge Base http://support.microsoft.com/support

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

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 key words 'Australia' and 'news' you wont find it on the first page, but if you add 'Sydney' (a word from the company name) then you're number 1...

Using either Google Desktop Search or MSN Desktop Search will allow you to instantly search for a name and find all correspondence with that person. Even if there has been no contact for 6 months, you can resume the discussion as if it were yesterday.

Of course if you are using Windows 7 or Windows Vista, desktop search is integrated within the operating system.

Follow our standard on setting up Enterprise Search.

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 'Actual Time Taken: 2:15'.

Figure: You need to check up on your developers every 2 weeks. Then you'll never be fooled!

1. Sprint Contracts/Releases - Never set a deadline more than 3 weeks from the previous deadline. Deliverables become a lot easier to manage and meet when they're small. Read more about Sprint Contracts
2. Unit Tests - Write tests before you write code. Unit Tests become a way of life and although they're expensive at the beginning, they pay off during the course of the project. To find out more about Unit Tests see Rules To Better Unit Tests and for unit tests in the GUI of SSW Code Auditor please go to Rules to Better Code.
3. Metaphors/User Stories - client's description of a task. Aim to take down the main points
4. Validation Tests - To find out more about Validation Tests see Rules To Better Website Development.
5. The 2 key reports
   • Burndown
   • Stories Overview

Here are the rules we don't agree with:

1. Physical Cards - emails are much better
2. Pair Programming:
   • XP says 2 people at one PC - we have two developers on their own PC's sitting next to each other.
   • We fix production code in pairs. 'Too Expensive' some say. Yes it's pricey, but it's better quality.

1. What did you do yesterday? (and did you update TFS/other bug tr​acking system) ?
2. What are you going to do today? (and my current task on the physical taskboard has my picture on it)
3. Do you have any roadblocks? (aka 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 discovers 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.

Figure: Watch a Daily Scrum at Microsoft (short) 

Figure: Watch a Daily Scrum at Microsoft (long)  

Remember

"Its ok to change Scrum, actually it is necessary for success. Just adhere to the values of Scrum." ​

Stephen Forte

Follow these essential tips to improve your Daily Scrum meetings:

Tip 1: Have your Scrum Master 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.

 

Figure: Automatically generated burndown chart from TFS Preview (TFS 2012)

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

 

Hi <Team name>,

As per our conversation, the Daily Scrum for <Project Name> will be held at <Location Name> 11:00AM (Sydney Time) every working day.

It must be held for 15 mins maximum as per standards:

http://rules.ssw.com.au/Management/RulesToSuccessfulProjects/Pages/DailyStandUpScrum.aspx

Regards,

<Scrum Master>​

 

Figure: Schedule a recurring Daily Scrum meeting in Outlook using this template

Tip 3: Keep to the schedule. Same place, same time (and start 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.

 

Note #1: The Product Owner (often the client) is not required at the stand up meeting. If he wants to turn up, remind him that he has tape stuck over his mouth, so he does not talk. 

Note #2: If you are not doing an approved sprint and doing ad-hoc work, then best if the Product Owner (aka client) attends (see Ad Hoc work).

Tip 4: Do you update tasks before the Daily Scrum?

 

Daily Scrums are more effective when team members arrive with their tasks already updated.

 

See SSW rule Do you update your tasks before the daily stand-up meeting?

​

Tip 5: Don't go into detail

 

Keep your answers short and concise. Do not stray from the 3 main questions. Remember to use the "Parking Lot" to record topics to discuss after the Daily Scrum.

Tip 6: No phones + no checking email. No distractions.

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 7: Use a task board (even better use an electronic one)

A task board allows people to visualize what the team is talking about.

Figure: The Task Board from TFS Preview (TFS 2012)

Tip 8: 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 9: Don't let your Daily Scrum become a general meeting - use a "Parking Lot".

A "Parking Lot" is the place for any discussions that stop the Team from answering the 3 main questions. Only interested people stay for the "Parking Lot" to be discuss issues after the Daily Scrum.

 

Tip 10: If you have raised impediments, consider contacting the Product Owner

Figure: 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 last week, then do so. A disconnected or absent Product Owner is a sign of dysfunction.

Tip 11: How do you 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 12: Use Skype or Lync

Use Skype or Lync 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 scrumboard 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​

 

More information:

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 occured in the last 24 hours.

 

 

Figure: Daily Scrums will alert everyone if there is a major problem and get all brains aligned in the right direction. There is no sense in putting a Band-Aid on a patient's scraped knee if there is a big knife in his eye!

​
Figure: If you like this, retweet  https://twitter.com/#!/AdamCogan/status/168175594209681408 

​​​​​

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.

This is a common scenario: Your tester/client finds a bug, they log on to your on-line bug database, and enter the data, they save the error message as a gif and upload the image. As Project Manager, you get notified by email of the bug, you log on to the application, view the image, review the status, assign a priority, and assign it to a developer. The developer receives the email, logs on and sets about fixing the bug. When completed, he logs back on to the application, enters a completed date, and an email is sent to the tester/client. The tester/client logs on, and is told what to test, reviews the work, enters a checked by date, and the final email is sent to the manager who closes the bug.

Phew! That sounds like a lot of steps which is why most people resort to just sending an email. I believe most people send requests for tasks via email, if this is the case, why should developers have a separate "to-do" list, in the form of a bug-database in which they re-enter data?

MS TFS has an Outlook addin which can save you a lot of this work called Team Companion. This has a number of benefits including:

• Developers don't have to re-enter data
• TFS fully intergrates your bug tracking with your source control.
• Managers can see important information like Tasks Completed and Tasks Assigned in TFS Reports
• Clients can see what developers are working on via TFS

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.

There are 3 levels of "Done" in communication

Level 1

• Sending a "Done" email

Level 2

• Sending a "Done" email
• screenshots
• code

Level 3

• Sending a "Done" email
• video
• code (showing a full scenario e.g. a user story)

Example of a level 3 "done"

Subject: RE: Manad - Coded UI Tests #2

> Create a new CodedUI test on your feedback form – search only to test the telerik

Done

Figure – Coded UI Test passes in Visual Studio

Jing Video of the test running: http://screencast.com/t/ps17fqsV

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 on that user story

Team - Level 2

• All of the above, plus
• All unit tests passed
• 1% code coverage

Team - Level 3

• All of the above, plus
• Successful build on the Build Server
• Check in Policy - Changeset Comments Policy (all checkins must have a comment)
• Check in Policy - Work Items (all checkins 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 test passing (aka. Automated functional testing with Web Tests, Coded UI Tests, or Telerik Tests)
• Sending a Done email (with video recording using Jing)

Team - Level 5

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

Team - Level 6

• All of the above, plus
• Multiple environments automatically tested using Lab Management

Team - Level 7

• All of the above, plus
• Automated Load Testing
• Continuous Deployment

• All of the above, plus
• Inspected by the Product Owner
• Deployed to Production

Congratulations! You are frequently deploying to production. This idea 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.

More Information:

Do your user stories include acceptance criteria?
Do you enforce comments with check-ins?
Do you enforce work item association with check-in?
Do you follow a Test Driven Process?

Failing to follow this rule encourages developers 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!

Note: Other systems are used that are less aggressive than our 'zz' rule.

• In .NET, the keyword obselete  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, the keyword deprecated  is used.

Both allow for some backward compatibility.

See our Rules to Better SQL Server Databases - Do you add zs prefix to table name?

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.

After reviewing a few different options, we decided using Google Calendar to manage recurring tasks was the best option.

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

• If it will take less 15 mins to fix, do it straight away.
• If it will take more time, email the problem to the appropriate person (even if it's a 3rd 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. My view 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.

Figure: Do you want users to have good first impressions?

There are a number of different types of tests that you can perform:

• Unit Testing:

  It validates the smallest testable parts of an application. Unit tests do not cover the UI layer. There is no industry standard 3rd party unit test tool but at SSW we use NUnit and Visual Studio Team Test.

• White Box Testing:

  White box testing or structural testing is done knowing the internal code implementation and targeting specific aspects: for example security risks or a potential performance bottle neck. By looking at the implementation it helps to identify areas where the system could be flawed. Because the tests are designed to match the code, if the implementation changes, the tests will need to change.

• Black Box Testing:

  Black box testing or functional testing, unlike the White box testing, doesn't rely on the knowledge of the internal code structure. It relies on the software specifications and requirements. The tests use valid and invalid inputs and check that the output is correct.

• Integration Testing:

  Integration testing is performed when all the software components are put together. This testing should be done after each individual software component has passed unit testing. This type of testing highlights interface problems or misunderstanding of the software specifications where unit tests local to each component actually passed. Automated integration testing is essential and often run overnight due to the time it takes.

• User Acceptance Testing (UAT):

  User Acceptance Testing (UAT) or Beta Testing occurs at the end of the software development cycle (this could be at the end of a Scrum Sprint where the software is potentially shippable). As its name points out the end users will test the software and check it meets their acceptance criteria.

• Security testing:

  Security testing is done to check that a system protects data and maintains confidentiality as intended. The concepts covered by Security testing can include: network mapping, vulnerability scanning, password cracking, confidentiality, integrity, authentication, authorization, availability, non-repudiation and virus scanning.

• Performance testing:

  Performance Testing is used to determine the responsiveness, the effectiveness of a system under a given workload. Qualitative attributes such as reliability, scalability and interoperability may also be evaluated. Performance testing is often done along with stress testing.

• Smoke testing:

  Smoke testing is done to ensure the system doesn't have any critical bugs that would make other types of testing unnecessary. This type of testing is generally performed on a new or fixed software. A Smoke test should cover essential parts of the application so it is said to be shallow and broad.

Lead Developer responsibilities

Please cc the client in all your "Test Please" emails including internal ones.

1. At the end of a release, prepare a "Test Please" email.  Create the email by copying the text from the sample Test Please Report.
2. Get two testers to test your app - if it's a web app make sure one uses IE and the other Firefox.
3. Specify exactly what is required to be tested by adding some bullet points at the top and highlighting in yellow, so it stands out from the template text. e.g:
   • Run Timesheet report
   • Check changing a rate
4. Make sure the testers send one bug/suggestion per email.
5. Triage emails as they come in for completion in this release, or a later release.
6. Don't change testers in the middle of a release. It is just sneaky to get a test failed from a tester and then try again by using another tester :-)
7. Make sure that the testers know which build they are testing. The developers may be 3 builds ahead of the testers, but they need to complete a test run on an individual build to make sure that bugs are fixed and that there are no regressions.

   Note: Having a good branching strategy makes this easy as you can run an Internal and External "Test Please" on your DEV branch before allowing the code to be committed to Main/Trunk. This protects your Main/Trunk branch from contamination by code that does not work.

8. Randomly have the manager do a "Test Please" as well. He gives a pass or fail on the job the testers did.
9. When you receive a "Test Please Succeeded" from both testers (and never before) prepare a "Test Please" for the client. (If you are requested to issue a non-tested release to a client state "Has not passed internal testing" in the email.)

Tester responsibilities

1. Confirm you are a tester - If the developer did not name you, make sure he corrects himself and resends the 'test please' email.
2. Ensure you are working on the Standard Operating Environment specific to the client and using the right browser for web apps.
3. Use Team Viewer if you aren't available locally.
4. Test within the hour - testing is typically urgent.
5. Know what to test.
6. Be thorough - anything from a crash-to-code bug to a minor UI change should be reported .(one email at a time)
7. Classify issues accordingly to "this release" or "next release" following the report bug/enhancement standard. Any crash to code bugs must be fixed in the current release.
8. "Reply to all" for each bug or feature. (to ensure no issue is reported twice)
9. Specify how you replicated the bug through clear instructions and screenshots.
10.  When finished reply to the 'test please' email with "Test Please Succeeded (as no Critical bugs)" or "Test please failed (as per critical bugs reported)".

Figure: This is how to reply failed to a "test please" email

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
   - nUnit (for Windows Apps), or
   - Visual Studio Team System Unit Tests (for Web Apps)
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)

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 (using one of the 4 templates on the right)
• 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?"

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 know 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 others 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. Please see How to Develop and Reply "Done"

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 http://www.ssw.com.au/ssw/KB

Suggestions for features should be added to the backlog and voted on at uservoice.com

Servers

For server machines, we recommend using either Windows' built-in Remote Desktop (also knows as "Terminal Services" in Windows 2000) or VNC-based tool. Remote Desktop provides each authenticated user a Windows logon 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).

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), XP only allows 1 user at a time, if you logon to client's XP machine, the client will be logged off.

For the VNC-based remote tool, one of the main difference of VNC-based remote tool is it shares the same logon session with the user who is currently logged on the machine. The server administrator doesn't need to give us the Windows' username and password nor create a temporary user account for us. And because of both parties will share the same logon session, we see what the clients see, and so do they. Some clients may prefer this as they know what's happening exactly, which is important for a server.
The VNC tools we prefer: TightVNC and UltraVNC.

Desktop support

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

• MSN Remote Assistance in MSN is what you try first. It will work unless the user is behind a firewall or router.
• TeamViewer It’s easy, simple and works in most environments. Other benefits include:
  • The client can see what you do on his/her machine
  • You can use chat with client in TeamViewer and
  • You can transfer files to client's desktop
  You can also see TeamViewer for clients  
• UltraVNC Your second option is to try UltraVNC SC - there is no screwing with firewalls at client side and it is free.
• Copilot The final option is to try Copilot - there is no screwing with firewalls at both sides. Only downside is it is not free.

SSW Remote Support Standard

See useful tools The Best 3rd Party Network Tools - TeamViewer.

To achieve this, we run Microsoft Updates (not to confuse with Windows Updates) and install all latest updates for all the known Microsoft products.

Note: "Windows Update" only updates the operating system, where "Microsoft Update" updates other products as well, such as Microsoft Office, SQL Server, etc.

And then we run SSW Diagnostics to check the latest version of other applications (mostly non-Microsoft) are installed.

Warning: Of course if you are fixing a bug on someone’s PC, you should only update one piece of software at a time, so you know if an update fixes the problem. After that (if the company allows it), update all software to the latest version. If they get a new problem, then rollback.

Take a version control approach. It doesn't have to be too complicated, but you should keep a history of structure changes in a table. Some developers use a text file (.sql) or hardcode it in code, that's fine, just don't make changes in the interface (i.e.. Access or Enterprise Manager). Changes should be made programmatically, or in a method that they can be played back.

An assumption to this is you have a front-end and backend table that is used to record the version number.

Tip: If you’re using Next Gen and you’re changing just one table, then just regenerate for that table

The best solution is to use build scripts (.bat and .vbs files) to automatically create a setup package that can be used to deploy to testing and production environments. For backend changes, you can either include the change scripts with the setup package (if it's a localised database), or run those scripts as part of your deployment process.

Read more about setup packages at SSW's Wise Standard for Products.

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 might have been Orange (kind of like traffic lights) but the color palette in Word doesn't give Orange.

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

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

An application of this rule is how we identify our CRM servers - see rule Do you identify Development, Test and Production CRM Web Servers by colors?

Every member of a team plays an important role in maintaining standards. Whether it's my code or someone else's, I always keep an eye out for mistakes.

When I come across an error, I never just fix it, as the developer who made it is likely to make it again. I write an email to the person explaining what has been done wrong and how to do the right thing. I CC the manager so they are aware of the situation.

Of course, with everyone doing this in the office, it's not a matter of finger pointing, we all truly work together to write better code.

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

If you don't have the confidence to talk to the person, send an email from info. The important thing is to talk about it at the time. 

Clearly, this standard does not just apply to writing better code, it 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!

Equally important is your responsibility to ensure that others are doing their best to maintain and follow the standards.

I give a Project Management test to coders as well. I want my coders to be able to contribute to the working of a project from end to end. They need to be able 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."

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

1. Program the XP way - programming in pairs means you won't cruise the web or play Solitaire, you'll be forced to focus.
2. Don't interrupt people unnecessarily when they're working - create comprehensive standards for people to refer to.
3. Avoid multi-tasking as much as possible, don't open one email, respond to half the questions, and then open another. Complete the first, and delete.
4. Set your Browser default to "About:Blank" so you don't get distracted by msn.com.
5. Minimise Outlook distractions.
6. Minimise MSN Messenger distractions.

Figure: St. Bernards are known for rescuing lost mountaineers, bringing life saving provisions

• Business cards
• A network cable (optional)
• An extension cord (optional)
• A thumb drive on your key ring (a personal choice, but 16 GB is a good choice)
• An external hard drive (a personal choice, but 750 GB if a good choice if you have lots of 10+ GB VMs)
• Software DVD's (generally you can keep the .ISOs of MS Office and Visual Studio D:\DataSetup\ISOs\)
• Current brochures - Hand them out to interested clients
• User story cards - These help Product owners create user stories
• Evaluation forms - Ask for feedback if you did a presentation
• Even a text book or two

We have one guy in our office who carries two bags, each weighing about 10 kgs. He is the SSW St. Bernard! *

If you need to quickly share something with your mate:

• Use a thumb drive that you carry as per Rules to better Software Consultants - Carry a thumb drive
• Setup a wireless ad hoc network as per http://www.addictivetips.com/windows-tips/create-a-quick-ad-hoc-wireless-network-connection-between-two-computers-in-windows-vista/

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

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

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

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.

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.

1. Freebies/discounts need just as strict controls as regular projects

         When you are giving something away at a discount or for free you are expecting a loss compared with a regular client. If you fail to follow regular processes not only will you incur an even greater loss you provide a lesser standard of service and put greater risk on the success of the project.

         A discount or freebie should follow all the standard processes such as:

   • initial meetings
   • written contracts
   • specification reviews
   • release plans
   • triaging additional items
   • release debriefs
2. Feedback on service

         Often the people you choose to provide a freebie are the best people to provide feedback on your product or services. When you waive all your standard processes, they have no opportunity to review how you conduct your business. So if I'm offering a freebie (or any discount), I ensure every normal standard of business is followed (including sending $0 invoices!) and I ensure I get valuable feedback to help me run SSW better.

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

Figure: Good example – Add some code to check the timing, before fixing any performance issues (An example from SSW Code Auditor)

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.

Related

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

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.

Similarly, when we get some feedback we will send around an email, and store the email in a public folder.

However, requesting a signature (or just an initial) on non-contractual type documents, especially screen-shots or data-schemas, is very beneficial. When you ask a client to 'review this screen mock-up' they will generally take a cursory glance, perhaps make a comment or two and then move on to something else. Asking them to then initial the print-out of the screen mock-up 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.

Training clients to continually review work carefully leads to better quality work.

• Less time stuck on a problem - you have someone familiar with the project to help you work through the problem
• Your code will have less strange workarounds - because if something doesn't add up to a developer, he has someone to ask
• Cleaner code - because 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

But I don't promote classical pair programming which is two developers on one machine. At SSW we use our own type. We do put our developers in pairs, but they each have their own computer.

It's also a good idea for non-programmers to work in pairs. You can keep each other motivated, there is always someone to help if you get stuck, and you absorb knowledge from each other. Experience shows that developers are more productive this way.

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. Figure: Bad example - This is normal ‘pair programming’, two people working at one PC
Figure: Good example - This is ‘pair working’, two guys working on the same project, with their own laptops, but sitting very close to each otherIs 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.

We generally estimate the overhead as 20% extra. But 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 really working closely together, you will be using an application like TeamViewer to view one another's desktops so you can help each other out when necessary. You should have TeamViewer showing on a 2nd monitor. 

A release plan for a migration will typically include:

1. Business purpose for migration
2. Test migration
3. User Acceptance Testing of the test migration
4. Rollback procedure
5. Decommissioning procedure

Approved release plans are mandatory for a migrations such as:

1. Exchange Server 2003 to 2007
2. ISA Server to a hardware firewall
3. Phone system to VoIP
4. etc

Read Do you conduct specification analysis by creating mock-ups? to learn more about other mock-up types.

1. Budget - the release must be completed within the budget allocated
2. Scope - no more than 50% reduction in work item hours
3. Quality - must pass test please and get a mark of 7/10 or above from the client
4. Time - the release cannot be delivered 50% over time e.g. if the planned finish date was 14 days (two weeks) after the start, then the release must be delivered less than 21 days after the start date
5. Release debrief - sent to the client and completed and a review of "Rules to better project management" by the project manager

1. Confirm current tasks
2. Confirm future tasks
3. Confirm the primary contacts
4. Do a code review
5. Review the client portal
6. Confirm location of info and procedures (hopefully these are on a wiki or SharePoint document library)
   • Source control
   • Database
   • Documents
   • How to Build and Package
   • Testing Steps and users and passwords to access the test and staging servers  
   • Deployment Steps
   • Servers and Passwords
   • Failure & Recovery Steps
7. Test that the users, passwords, urls and server details provided in the handover are correct by logging in with each
8. Complete the Handover by sending an email with: As per our meeting the handover has been completed to my satisfaction

If you need to handover only a single task there are more details here:
http://rules.ssw.com.au/Communication/RulesToBetterEmail/Pages/HandOverTask.aspx

All peers that worked together should evaluate each other by filling the Peer Evaluation Form every month.

The evaluation is done by ranking from top to bottom and giving constructive comments in “Start, Stop, Continue”
e.g. (Start...) checking in with better comments  
e.g. (Stop...) coding without a user story  
e.g. (Continue...) with your helpful SEO comments

Note: Comments must have an option to be anonymous.

If you do not rank a listed peer it means that you have constructive comments to give them but are not qualified to assess the person’s value
e.g. an admin person evaluating a technician and vice versa; or a work experience person new to the company who feels qualified to give comments only.

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

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