Sunshine Report
Sunshine Report: A status report which only reflects the positive feelings one is having.
For the most part, I have found that engineers tend to focus on problems in their status reports, but the first person who gave me sunshine reports took me by surprise. These next few paragraph detail my first enlightening experience with the sunshine report.
-
1st Status Report
When asked for his status, he responded that, “Everything is great, I’m looking into this one issue, but I’m confident that I’ll be able to get everything done on time.” My first thought was wow, a part of this project is going well. I recorded his report and moved on to my next task.2nd Status Report
I asked him for his status report, he said again that everything is good. He was still looking into this one issue, but is confident that fixing this issue will resolve many other issues he has assigned to him. According to him, everything will still get completed on-time. At this point, warning bells started to sound. I was concerned that he is still on the same issue and that this issue is starting to spread to other sections of the code. But, he still seemed positive about it. I let it go to see where he would get to next week.3rd Status Report
Now, this time I came to the meeting much more prepared. When I asked him how it was going, he was still one big happy ball of sunshine and confident that it would be done on time. I thought differently. He had just spent three weeks working on the same issue. I began to question him much more in-depth about his work. Driving down on the issues. After only about 5 minutes of drill down, he started to come to the realization that he was in over his head. We worked together to come up with a plan to get him back on track.
After that, I monitored his project more closely. Unfortunately on the next project, when prompted for a status report he still gave “Sunshine Reports”, but it just took a few minutes to cut through the sunshine to get to the truth.
Release Notes
Filed under: Development, Management, Process, Product Management, Project Management, Quality Assurance, Templates
Software is never releases, it escapes. Usually when it escapes, it comes attached with a listing of caveats and other information for the user which are listed in release notes.
There is a big difference in the internal defect description and the external description. For instance, internally a bug may have the summary, “XML Parser occasionally dies horrible death when comment field improperly terminated”. The external release note could be, “The XML input functionality requires that the XML is well formed. Usage of poorly formed XML may result in termination of the application.”
The selection of content for release notes is defined by the culture of the organization and the relationship with the customer. I have been involved with the two extremes of release noting, where at one end we documented almost nothing, and the other we listed everything. When choosing your philosophy, keep in mind the following:
- Release Notes Leak
Each release note you write will end up in the hands of the sales force of the competition. Your competition will lie about your product, this just gives them more ammunition to confuse the customer and increase the duration of the sales cycle.
- Release Note Visibility
You need to know who has access to the release notes. Some release notes are published on the internet, while others are hidden inside of the product installer. If the release notes are visible to those who have not purchased the product, it may be time to get marketing involved in their creation as the notes could affect product demand. If the release notes are only visible to those who have purchased the product, you can be much more open.
- Does the customer care about this issue?
Yes, it is an important question to ask. Often dev will flag an issue for release noting because they think it is very important, but often they do not consider the program usage by the average user. I know that the program will crash if the XML being imported does not have the comment terminated, but I think it is safe to not release note this since the XML being imported is almost never edited by user. Development means well be asking for the release note, but after they have spent so much time working inside of the program, they often lose perspective.
- What happens if we don’t release note this?
There are consequences for customers finding bugs on their own. It is usually better for the customer to be provided advance notice of the issues so that they can plan their work flows around the defects.
- Will documenting this issue kill our chances of winning the product evaluation?
This is the one I hate the most. You should be proud of the product and acknowledge its short comings. The customer will find them out sooner or later. You will look more professional in the long run if you tell them the issues ahead of time rather than them finding them out themselves.
In one organization, I was specifically told not to mention any defects in the release notes because we were in the middle of product evaluations. This fostered a sense of mis-trust with the evaluators, who would constantly call and complain to me about the quality of the product. I finally convinced the organization to change their philosophy. Once we started producing real release notes containing useful information, their perception of our product quality by the evaluators actually went up. Before knowing the all the defects, they thought that almost all areas of the program were unstable. By telling them specifically what the supported scenarios were, it helped create trust and converted them from an evaluator to customer.
- Does this make the company and product look really bad?
If it makes the company look bad and the product bad, it is time to consider changing it from the “Non-Gating, Release Note” to “Gating”.
- Can this be explained concisely?
Why can the issue note be explained concisely? Perhaps it is to obscure of an issue to release note.
When in doubt, more is less. By trusting in your customers, they will trust in you.
A sample release note template is contained in the template section.
Best … Demo … Ever …
Filed under: Big Company, Crazy, Development, End User, Small Company
There are certain aspects of a good demo, but it all comes down to practice, practice, practice.
Lets set the stage. After starting coding four month ago, we were running out of cash. There was a potential VC deal on the horizon, but it wasn’t going to happen until we had a sale. This was `the demo` to our only real customer in the pipeline. We had all the right people in the room for the demo. The customer had made it clear in our last demo what the sales objections were going to be, and that they had to be resolved for this next demo. It was a hail mary pass with two seconds left on the clock.
Lets dissect the days before the demo.
Day: t – 14
We gave a demo to our early adopter evangelist on the inside. He provided valuable feedback and pointed out the areas which will be the objection points. We scheduled the demo two weeks from that day. Several show stopper bugs, but we have two weeks to fix them.
Day: t – 13 to t – 3
Code like you’ve never coded before. Keep cranking it out. Don’t stop. Fix all those bugs.
Day: t – 2
We created the demo script. Although the meeting was to be 1 hour in length, the demo part was scheduled only to be 10 minutes long. The script covered all the users important pain points along with the requested objection points. All of the show stopper bugs were resolved except for one. We still have one day till code freeze to fix that nasty bug.
Day: t -1
24h before the demo was to begin, we froze the code. From now on, it was nothing but practice. That nasty bug is still there.
Now, about that bug. If an item was dragged in our interface, it would crash the entire application. Think BSOD. The only way to prevent the crash was to drag it to an exact pixel co-ordinates. Think of having a 1280×1024 resolution screen and having to drag to an unmarked x,y co-ordinate. If you missed, the application could crash and the company could fail. No pressure.
Day: t – 0
After our demo’er practiced nearly for a day, we were ready. He typically was able to hit the pixel about 50% of the time. Hedging our bets, I made sure we had two applications running at the same time, with the second setup to be at the exact point right after the crash should occur in the script. If a crash should occur, hopefully we can <ALT-Tab> before anyone notices. The demo went perfectly. He hit the pixel right on, no crash!
Best demo ever!
