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.
Demo Driven Development
Filed under: Crazy, End User, Product Management, Project Management, Small Company
• Your company is living paycheck to paycheck.
• No one has actually paid for your product.
• Product direction changes each time sales visits a lead.
Given the above situation, it is time to plan a software release. The PMBOK doesn’t cover this kind of project. There is no chapter for near Armageddon events. Planning a software release for a company which is just starting out or in a death spiral is not covered in classical project management literature.
The development plan will be:
The name of the game is to make it looks like you have what the customers needs as quickly as possible. You do not know your market, you do not know your product, you know nothing. Through many failures, the company will discover the market. The hope is that there is enough time and cash to realize this goal.
Someone on the sales team manged to get on the calendar of someone with budget and a pain large enough that they will spend 1 hour to see if you can help them. The sales team has provided you with the release date, and a feature set.
As usual, break down the tasks, figure out what is possible, drop everything that is not (ensure that you record what was not done, and that it came in from sales, not the customer directly). Then get started. While developing it is important to remember that if you are successful, this demo will most likely become the foundations of your code base. Also, this software on demo day will not be touched by anyone outside of your company (in its current form), it just need to be good enough that they believe you can deploy it when they purchase it. I am not saying to fake the demo, I’m saying that you need to focus on the core pain points and that you can illustrate the solution to the potential customer. Many times, before the demo, the requirements will shift when the sales guys enlightens you more on the problem that the potential customer has. Those changes need to be incorporated. You are trying to demonstrate that your product can satisfy their needs. Do the changes as best as you can. Refusing to demonstrate a product which can help a potential customer is a waste of both your time and theirs. No one loves the churn, but you need to suck it up and do it.
During the demo, ensure that you are able to listen to the feedback while it is happening. This is the closest thing to users you have. They will provide you with the next set of work you need to do on your program. Record all their feedback (product ideas and bugs). Discuss internally all their ideas and make a plan for addressing the issues. Start working on them as soon as possible because you have up until the sales team schedules the next demo.
Once the next demo is scheduled, all of the focus shifts towards it. When demo goes well, but the potential customer is not interested (this is the most likely outcome), record all the feedback. Triage all of the features (including the previous demos) and begin work immediately based on what appears to be the most important in your potential customers eyes which is blocking the sale. Hopefully after several demos you will begin to see pattern and specific items and themes which re-occur. The future of the company depends on if you can solve the customers problem before the company closes shop.
Perspective
Filed under: Crazy, Development, End User, HR, Management, Small Company
This post started out as a discussion on the common enemy, Ted. Ted is the guy who everyone hates in the office and wonders why he is still there (If Ted is your CEO, it is time to look for a new job). As I thought about the Teds of the world, the theme of perspective kept coming up.
One of my Teds would constantly distract us from our work, arguing the peculiar aspects of a specification interpretation. We had no problems discussing these issues in six months, but while we were trying to fix data corruption bugs, a bit of perspective was required. I had to constantly recalibrate him. One incident occurred during crunch time in the early versions of the product. “Damn it Ted, it doesn’t matter how we interpret this esoteric section of the spec because it is meaningless until our users can load the work they just saved! We have been working crazy hours for the past weeks trying to fix the load bug so that there would be a company in six months.”
It is important when you are deep inside a complex issue, that you do not lose perspective. Many good engineers have lost hours on less important issues trying to work them out to completion. Always remember that It is important to keep the end user user in mind, asking yourself if this is the best way to move the product forward for them.
