Nice and non-denominational, right? For all of you celebrating this weekend (and really, you should celebrate every weekend. And weekday, if you can manage it), may it be a merry one.
xoxo (and ho, ho, ho),
The SA Crew
Another best-of list blog post! Another best-of list blog post whose preface warns you it is a best-of list blog post! So sue me. Or don’t read it. ‘Tis the season, and I’m a copycat.
2011’s been a kind of wild and crazy year, both for us as a company and for the software world as a whole. But rather than do a straight recap, I decided to poll our crew on the hands-down coolest thing/language/trick/product/comestible/visual symphony/regular symphony they’ve ingested this year, and let you extrapolate your own state-of-the-union conclusions from these. Alors:
Traditionally, a disconnect exists between IT and business operations. Departments don’t understand IT processes and IT doesn’t understand departmental workflow and procedures. Committees, task forces, and “super teams” may remedy this issue on a short term basis for a joint project where both sides receive a narrow view into each other’s underpinnings, but focus can be lost after project implementation as both parties shift attention to new priorities.
The solution to this problem may be simple. Each department or several combined departments, depending on company size, employ dedicated IT personnel to service their IT needs. This strategy does not remove the need for a centralized IT department. Core IT services (i.e. email, networking, hardware, security) need to remained centralized to ensure operational consistency across the organization. Instead, departmental IT Pros will implement and directly support departmental applications, cloud based or otherwise. They will be the bridge between the department and IT when projects require internal IT resources. Most of all they will posses integral departmental knowledge and savvy IT wisdom that will help drive future business directives while breaking down the business IT barrier.
I returned from vacation today to find my neighborhood newly populated with balsams, Christmas lights and the gentle clang of the Salvation Army Santa’s bell. While that and other national charitable organizations are certainly worthy benefactors of your Christmas/Hannucka/Kwanza spirit, why not consider donating to a local nonprofit instead/ in addition? What Boston’s nonprofit landscape lacks in quantity, it more than makes up for in innovation, accessibility and creativity, as the following five nonprofits demonstrate. Each offers multiple avenues of involvement, easy-to-use websites and visible and visible and tangible testaments of your impact.
1.) Cauzoom: On this “Community Cause Marketing” site, you get to pick or start a project, contribute directly, via giftcard or by spreading awareness. Recent projects include holiday gifts for foster children and their families in Woburn, art supplies for the Brookline Arts Center and the Northeast Animal Shelter Senior Visitation program in Salem.
Continue reading The Charitable Locavore: 5 Boston NonProfits Worth Donating To
The concept of scrum can seem very simple in theory. As stories come in, the team analyzes them, and then story points them based on the complexity of the story. It couldn’t be simpler. But in practice, it is rarely this simple. The problem is that sometimes you won’t know just how complex a story is until after you’ve played around with it a bit. At my company, this is a problem we face almost every time we meet to story point backlog items.
Usually, a bit of uncertainty is fine. That’s the entire reason teams usually story point with a non-linear scale (one the popular scales being: 1,2,3,5,8,13,20,40,100). If a story could be anywhere from a 30 to a 40, then just give it a 40 (assuming we’re using the popular scale). Even if the story ends up closer the 30, there’s probably some other story that was more complex than its story point implied and it all generally averages out. But every now and then, there’s just too much uncertainty. A story might be anywhere from a 5 to a 50 depending on factors you won’t know until you’ve looked into it a bit and done some research. Continue reading Scrum Debates: Research as a Task
Keep in mind that most people in the hiring process, especially in Human Resources, review somewhere close to a googol of resumes in their career. Hyperbole perhaps, but hopefully you understand the extent of the sheer numbers you are up against when you apply for any position. Needless to say, if your resume does not pass the first review, you are highly unlikely to get that position.
Most HR staff, myself included, look at resumes and quickly put the bits of information contained therein into one of three categories:
Time and time again, the same types of mistakes occur. Since categorization seems to be a sub-theme of this blog, here is my list of the types of mistakes to avoid and the good, the bad and the ugly. Caveat — I’ve participated in many resume critique workshops at colleges helping students perfect a resume — one thing that I have noticed is that each college’s idea of a perfect resume differs. For example, one college insists that you have an “Objective” statement and one college insists that you DO NOT have an ‘Objective” statement. This segues into #1:
Our company adopted scrum as our method for development over a year ago. And to this day, we’ve yet to get it entirely right. Over the months we’ve had to address issues ranging from “What do we do when critical issues come up?” to “Who should be a part of our daily scrum meeting?” to “What the hell is a story point anyway?” But one such problem that our Product owner recently brought up is, “Should we really be story pointing bugs?” And the answer, of course, is… well, actually, no one can really agree on an answer.
Well, let’s start out with why we all originally said yes. In any given sprint, our team will have to commit to some handful of stories and bugs off the top of the product backlog. If both the stories and bugs are story pointed to the same scale, then we have no problem deciding how much we can commit to this sprint given our previous velocities. And for a while, this worked fine.
But let’s look at this from the product owner’s point of view. Let’s say we’ve just released the next version of our product and now our product owner is looking over the backlog, trying to figure out how many sprints we’ll need to complete the required features (let’s say there are 10) we need for the next release. Each of these features gets defined as a story. For the sake of simplicity, let’s say they all have a story point value of 10, resulting in a total of 100 story points. In our past sprints, our velocity has averaged 20 story points. So our product owner can set the next release date for five sprints from now. Easy! Continue reading Scrum Debates: Story Pointing Bugs
Recently, I referenced something quite obscure – the “sheep-goat effect”. The reason I say “quite obscure” is that no one had any idea what it was. And I spoke to literally scores of people. The “sheep-goat effect” was coined in ESP experiments whereby people who believed in ESP did significantly better than those who did not believe in ESP on ESP-type tests. The believers were called “sheep” and the non-believers, “goats”. The “sheep-goat effect” is therefore used (apparently by only a very small handful of people aside from me, if at all), to illustrate that the belief in something can have a causal effect on that event happening.
So why was I making this reference in the first place? Because the sheep-goat effect goes beyond ESP tests–it can be a very powerful concept in marketing. This is especially true if your product or service is not widely accepted, is novel or is subject to public skepticism (like ESP).
Marketers love to gather feedback – by way of surveys. Just Google how to create a good marketing survey and you’ll run across suggestions regarding target groups and sampling. Here are a few you’ll find regarding target group: Continue reading Notes from the User Testing Files: The Sheep-Goat Effect