Monday, March 26, 2012
Friday, March 16, 2012
Happy St. Urho's Day to all!
Ode to Saint Urho
by Gene McCavic and Richard MattsonVirginia, Minnesota
Ooksi kooksi coolama vee
Santia Urho is ta poy for me!
He sase out ta hoppers as pig as pirds.
Neffer peefor haff I hurd tose words!
Santia Urho is ta poy for me!
He sase out ta hoppers as pig as pirds.
Neffer peefor haff I hurd tose words!
He reely tolt tose pugs of kreen
Braffest Finn I effer seen
Some celebrate for St. Pat unt hiss nakes
Putt Urho poyka kot what it takes.
Braffest Finn I effer seen
Some celebrate for St. Pat unt hiss nakes
Putt Urho poyka kot what it takes.
He kot tall and trong from feelia sour
Unt ate kala moyakka effery hour.
Tat's why tat kuy could sase toes peetles
What krew as thick as chack bine neetles.
Unt ate kala moyakka effery hour.
Tat's why tat kuy could sase toes peetles
What krew as thick as chack bine neetles.
So let's give a cheer in hower pest vay
On Sixteenth of March, St. Urho's Tay.
On Sixteenth of March, St. Urho's Tay.
Tuesday, March 13, 2012
Friday, March 9, 2012
Tweeting @ 200 miles an hour
If you haven't heard the story yet, but at the Daytona 500 this year, one of the drivers-- Brad Keselowski (#2) actually tweeted during the race and sent photos of the track taken from inside his car.
If you haven't heard the story yet, but at the Daytona 500 this year, one of the drivers-- Brad Keselowski (#2) actually tweeted during the race and sent photos of the track taken from inside his car.
He was quick to point out that he doesn't actually tweet while driving (which would be a scary thought considering at Daytona the cars reach speeds of over 200 mph while racing inches away from other cars); but he did sent out updates during red flags and other breaks in the action.
Although this was rather ground breaking news in itself, probably the more amazing detail is that he picked up 160,000 followers during the race!
For those of you who don't follow NASCAR racing, one of the biggest differences from other sports is the heavy reliance of the drivers on corporate sponsors which the drivers always do their best to acknowledge any time they can in interviews, post-race photo ops and so on ("well, the Post Toastiesâ, Red Roosterâ, Days Innâ, Coronaâ, Days of our Livesâ car she ran real good all day but...").
Now combine those last two statements and think of the enormous impact social media can have in how companies advertise. Imagine 160,000 brand new, loyal followers receiving frequent tweets that drop small mentions of a sponsor ("just finished the race. now i'm off to drink some..."). Or mentions of special events and promotions by the sponsor. What makes this advertising even more potent is that it's directed to interested listeners and ones who trust and are willing to listen to the promoter (their favorite driver). Plus it's timely-- a real time commercial. Lastly but not least-- it's free!
I know a lot has been written in the past couple of years regarding the role social media is starting to play in how companies advertise; often though this is focused on how companies are learning to follow social media to monitor and protect their presence. Many are using Facebook and now Google+ to advertise or at least leave a footprint. I think NASCAR's experiment (or at least that of some of their drivers) is going to provide even more creative ways we learn to advertise.
Thursday, March 8, 2012
http://www.cracked.com/blog/4-hilariously-unexpected-feuds-between-fringe-groups/ - Check out this awesome article on Cracked.com
Sunday, March 4, 2012
Agile or Waterfall?
One thing that strikes me as I've followed many of the posts and discussions on LinkedIn lately are the many threads asking things like "What does Agile do for me" or "Why should I follow Agile if what I'm doing now works?"
And instead of promoting ideas on how to work faster or more efficiently most of the discussion I follow seems to promote things like why it's critical for each project to have a fully formed logical data model, or how no project is ready to start unless there is a specified set of artifacts that are formally approved and meet the standards mentioned in the IIBA BABOK.
I ask myself though-- how many times has one of my customers come to me after a project and told me how glad they are that all of the project artifacts had signatures? Or how many have users told me "boy, this project never would have happened if you hadn't written such a complete and accurate BRD!"
No, what the customer really wants is working software that does what it needs to do... and have it delivered to them as timely as possible. They don't care how the project team gets there or what it takes to get it done.
Anyone with me so far?
OK, now that we have that out of the way, does that mean every team needs to follow one of the Agile processes to be efficient, and will this ensure software is going to be developed and delivered faster and more bug free?
In a word, nope.
This might sound confusing, but it's not. What really helps teams improve is something else entirely: continual process improvement. Not applying the same tool and same process to each project. Not relying on the same checklist of artifacts or documents to each team. In a word... "being" agile.
This is what many waterfall based teams don't fully understand when they hear others promote an Agile environment-- assuming this new process requires some new mysterious set of steps and processes to follow, or throws everything out entirely. But it's also what many Agile teams don't seem to fully get either-- the Scrum discussions I follow are littered with questions like "how many days are required to be in a sprint" or "how many points should be in a story"? Good questions perhaps, but I can't help thinking most of these questions always have the same answer-- it depends.
You can see by these types of questions that many people are looking for the same thing when they go Agile: "what's the correct formula?". Meaning, they won't be-- because at it's heart Agile isn't a formula, it's a mindset. A mindset of continual change, course correction and improvement.
And instead of promoting ideas on how to work faster or more efficiently most of the discussion I follow seems to promote things like why it's critical for each project to have a fully formed logical data model, or how no project is ready to start unless there is a specified set of artifacts that are formally approved and meet the standards mentioned in the IIBA BABOK.
I ask myself though-- how many times has one of my customers come to me after a project and told me how glad they are that all of the project artifacts had signatures? Or how many have users told me "boy, this project never would have happened if you hadn't written such a complete and accurate BRD!"
No, what the customer really wants is working software that does what it needs to do... and have it delivered to them as timely as possible. They don't care how the project team gets there or what it takes to get it done.
Anyone with me so far?
OK, now that we have that out of the way, does that mean every team needs to follow one of the Agile processes to be efficient, and will this ensure software is going to be developed and delivered faster and more bug free?
In a word, nope.
This might sound confusing, but it's not. What really helps teams improve is something else entirely: continual process improvement. Not applying the same tool and same process to each project. Not relying on the same checklist of artifacts or documents to each team. In a word... "being" agile.
This is what many waterfall based teams don't fully understand when they hear others promote an Agile environment-- assuming this new process requires some new mysterious set of steps and processes to follow, or throws everything out entirely. But it's also what many Agile teams don't seem to fully get either-- the Scrum discussions I follow are littered with questions like "how many days are required to be in a sprint" or "how many points should be in a story"? Good questions perhaps, but I can't help thinking most of these questions always have the same answer-- it depends.
You can see by these types of questions that many people are looking for the same thing when they go Agile: "what's the correct formula?". Meaning, they won't be-- because at it's heart Agile isn't a formula, it's a mindset. A mindset of continual change, course correction and improvement.
Subscribe to:
Posts (Atom)