There are a number of questions that come up when I'm introducing new team members or people from the business to our Agile Software Development process. That question is... "Should we estimate a Spike with Story Points?". Since I've started by definitively answering the question, let me explain.
First, lets remind ourselves what a Spike is: A Spike is a time-boxed piece of work who's goal it is to answer a difficult technical question SO THAT the developers can properly illuminate a User Story or Epic. By illuminate I mean; the ability to estimate those User Stories or break down Epics into estimated User Stories. There should be no other real purpose. Even if the spike is about making a broad architectural decision, that decision should have been required because there were multiple user stories that would depend on that decision. The result of a Spike is deeper understanding and estimates. The physical manifestations of a Spike is usually some whiteboard diagrams, a page on your wiki, or even some simple throw away code to test a hypothesis.
Remember this item from the Twelve Principles behind the agile manifesto:
Working software is the primary measure of progress.
Completing a spike does not directly create working software so it does not directly deliver value to the customer. Given that a spike is not about delivering actual customer value (completing a User Story) then it should not be estimated in Story Points. Story points are how we broadly estimate, and communicate size and complexity to the business. The business comes to understand what a story point is and they learn in general what they can expect in an iteration from the development team. If you spend iterations delivering 30 points worth of spikes instead of 30 points worth of User Stories then the business will not understand what a point means to them. They will not understand what your team's velocity is. At best they'll be confused. At worst, they'll stop trusting you.
Given that a spike is time boxed (not estimated in points) and that the measure of progress is working software:
Spikes should be used sparingly. You don't have to know every detail of how you'll code up a story in order to estimate it. Unless the whole team is really confused, you should want to do real code for the story instead of spiking.
Spikes should be short. If Spikes are too long then they steal actual value from the iteration and make you start to wonder if you should decrease your velocity. If Spikes are used sparingly and they are short, you can get back to actually coding working software.
Spikes should be driven by actual User Story needs. Spiking on architectural concerns for things that you DO NOT know you actually need in the near term, or that are not directly tied to what the business wants to accomplish could (and usually does) end up being a waste of everyone's time [See YAGNI]. Don't spike on simple stories just because you think someday you may have as many users as Facebook. You may never, and if it looks like you might, you'll have been refactoring your code and architecture anyhow.
Not only has this heap of grievances failed to deter DecorMyEyes, but as Ms. Rodriguez’s all-too-cursory Google search demonstrated, the company can show up in the most coveted place on the Internet’s most powerful site.
Which means the owner of DecorMyEyes might be more than just a combustible bully with a mean streak and a potty mouth. He might also be a pioneer of a new brand of anti-salesmanship — utterly noxious retail — that is facilitated by the quirks and shortcomings of Internet commerce and that tramples long-cherished traditions of customer service, like deference and charm.
Nice? No.
Profitable?
“Very,” says Vitaly Borker, the founder and owner of DecorMyEyes, during the first of several surprisingly unguarded conversations.
Threaten your customers with physical violence and you can get to the top of the natural search results. Your google ranking is based on a lot of things, but attitude or opinion is not one of them. Using machines to determine 'sentiment' is a significant artificial intelligence challenge and likely one that will not be fully solved in the near term. I do think its likely that machine learning will soon get good enough at it to have some statistically relevant value over large amounts of data.
Kelly Johnson created the "Skunk Works" at Lockheed Martin in 1943 to rapidly build the first US fighter jet, the XP-80 "Shooting Star". Below are his 14 Rules of Operation for Skunk Works project...
The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
Strong but small project offices must be provided both by the military and industry.
The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).
A very simple drawing and drawing release system with great flexibility for making changes must be provided.
There must be a minimum number of reports required, but important work must be recorded thoroughly.
There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.
The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.
The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.
The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.
There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.
Adobe should remember that they sell content creation software, not free plugins that increasingly serve no purpose. Make authoring tools for HTML5 and stop fighting the ruination of your plugin.
The new version of Digg, v4, is based on a distributed database called Cassandra, which replaced the MySQL database the site ran on before. Cassandra is very advanced—it is supposed to be faster and scale better—but perhaps it is still too experimental.
As a technology leader, it is important to know what technologies are just around the corner. However it is equally important to understand the potential impact on your business. Understand the 'bleeding edge' but be pragmatic enough to avoid the 'bleeding' part.
From Dan Pink's talk at the RSA, animated. Like Attlassian, and on the topic of autonomy and motivating smart people, we recently started 'Developer Days' where we encourage all engineers to work on any technology related project they choose during the 2 days and then present it to the larger team at the end. Very casual, very fun.
Unfortunately nobody wanted to pair with me on writing a program in Scala that generates objectiveless meeting agendas and powerpoints filled with 3x3 diagrams.
Many moons ago, in the days when "client-server programming" on Windows 3.1 was what the cool kids did, I had "some success" on my regular project and so would often get to jump in on other project teams to coach and even do some coding. Since I always wanted to learn and do everything, this was a huge reward for me as a developer. One team I got to jump in on was having a lot of trouble with their version control system. They were using Visual Source Safe (at this time, it was a pretty hot, if you can believe it).
They HATED VSS. Despised it. Could not stop complaining about it. They were constantly losing code changes, accidentally deploying bugs that one developer or another would have SWORN they had fixed. Some of the developers started to suggest that they go back to the old way of version control, which was more or less like this:
"Hey, I'm about to edit that file on the file server... Don't do anything until I tell you I'm done". And the ever popular "Who deleted my file!!".
I knew full well, that was NOT the answer. I had coached others on the use of version control and had not seen the types of problems this team were having. So, I decided to sit down with one of the developers and talk to him about how he worked, and how he used VSS. He seemed to get the mechanics of it just fine. He understood check-in and check-out, getting the latest version and so on. So I asked him to show me what he was currently working on and he opened up the file explorer to show me. I immediately saw where all the problems were coming from. He had a large number of folders labeled "Copy of BlahBlah" where he would check out a file, copy it, make changes to the copy, make another copy, make changes to that copy, and so on until he was satisfied that he was done. At that point he would check out the files again and copy his changed files over the check-out version and then do the check-in. Turned out, in many cases he would even work on files for several days beofre 'checking it in'. During which, any number of other developers had worked on the same file or files and he would then effectively erase their work, re-introducing 'fixed' bugs, removing new features and so on. Once I made sure he and the rest of the team (just in case) understood not just the mechanics, but the whole POINT of version control, problems abruptly ended (or were replaced with the other well known problems VSS had, mechanically).
This person, who was a really nice guy, had his PHD in Mechanical Engineering. See the theme here? You can learn, or even get your doctorate, in the mechanics of anything, but real software development is about creativity and common sense. Its hard to coach common sense, but if you happen to have an ounce of it you should do your best to share.
These days I've been spending a chunk of my spare time in XCODE, which offerers a lot more configuration options than most IDE's I've used before. I've been able to make it look just like my favorite TextMate theme, more or less. When I used to spend most waking hours a day actually coding, I never had the opportunity to use an IDE with a black background (except VI and a terminal), and now I find that I need the contrast so I can stare blankly at the screen trying to remember a fraction of what I've forgotten without going snow blind.
I'm curious, what is your current font of choice? I'll thoughtfully consider the value of all comments except for anyone that says Times New Roman, which is the devil's font.
Below
Here are the details... everything is Monaco 11 but i use Courier New for comments to make them stand out a bit more...
