The Wall Street Journal published Rupert Murdoch's December 1st remarks to the Federal Trade Commission's workshop on journalism and the Internet in today's paper. It's clear Murdoch is running headstrong through new frontier. He stated that there are two principles media companies need to come to grips with:
In a move to appease the likely move by more media giants, and avoid legal wrangling, Google has just recently made it possible for companies to avoid turning up on their search engine by embedding some special tags in their web pages.
In my opinion, Murdoch delivered a compelling argument in his remarks before the Federal Trade Commission.
The experiment with online advertising is not bringing in the revenue that media companies have been looking for, and quite frankly need to sustain the independent and quality content being delivered.
People will only pay for content if they believe that they're receiving value. With this, media companies can support their business model to deliver this quality content to the people.
The need to protect and recognize the professional investments of time, effort, and resources of distinguished journalists to provide this quality.
Without what Murdoch is proposing, think of the alternative. Unable to manage a profitable business model, more and more print media are closing their offices. There are several reasons for this, but part of it has to do with trend towards digital media. Without reputable and independent media sources to provide quality content, it will be difficult to discern what digital news is worth noting and listening to in the massive sea of the web. Just search the blogosphere. You won't need to search too far to find a ton of misinformation being spewed on there today. Wikipedia has already had trouble keeping their entries clean, not to mention maintaining incentives for volunteer contributors to continue to contribute their content.
To stay ahead of the technology curve, News Corp and other media outlets are also pursuing an innovative mobile strategy to provide their print and televised content on any number of mobile devices. (I plan on following up on the potential impact of this for the Amazon's Kindle, Barnes & Noble's Nook, e-readers, Blackberrys, iPhones, etc., in another posting.) This strategy I believe will be the catalyst for these media moguls to find the balance between a sustainable and profitable business model, and delivering independent quality content to customers at a modest price.
To read the WSJ's article on Rupert Murdoch's remarks to the Federal Trade Commission on December 1st, click here.
With my current work in technologies within the financial market, I see low-latent risk management software applications as an answer for the controversy surrounding 'naked' sponsored access. But before I delve into the details of how such a solution would work, let me set the context of this posting with some background.
For those of you unfamiliar with some of the intricacies of the financial market, here’s a quick summary of what you see in the picture to the left regarding sponsored access. Brokers, like Bank of America and Goldman Sachs, are members of exchanges (ie. NYSE, Nasdaq, etc.). Brokers go through registrations, pay considerable fees, and are regulated to have access to these markets. Clients of these brokers who are interested in high-volume trading, for example in some cases hedge funds, want access to these markets.
Traditionally clients would pay the brokers a fee to access the markets via the broker’s own internal systems. It’s a win for the broker, who generates extra income in charging for access, and a win for the exchange which makes its money with the increase in trading volume.
The problem arises as more and more clients, who are also interested in high-frequency trading, want faster access to the markets. Using the broker’s internal systems to access these markets only increases the latency. The clients already have their own networks, usually optimized to meet their performance objectives, whereas the brokers may or may not. Either way, the broker’s systems will only add to the latency by adding an additional 'hop' to reach the market. (Again for those of you unfamiliar with high-frequency trading and the sensitivity surrounding latency, performance is measured in milliseconds and microseconds.)
To address latency concerns among their clients, brokers have given them 'naked' access to these markets (NYSE, Nasdaq, etc.) by providing their broker 'market-participant IDs.' The client (ie. hedge fund) directly accesses the market as if they were the broker (Bank of America, Goldman Sachs, etc.). The advantage is that the client bypasses the broker’s internal systems, directly connecting to the actual exchange, and avoids the additional latency.
Two problems, among others, that arise from naked sponsored access are:
Since clients are using the market-participant ID of the broker, the market is unaware that the trader is not the actual broker but a client of that broker. This therefore puts to question transparency (one major purpose of exchanges).
The broker is also held responsible for all trades made on behalf of those clients, since it’s their market-participant ID being used on that exchange. This puts brokers at risk of a client over-leveraging. Multiply the risk of over-leveraging by the number of clients trading with naked sponsored access, and there are legitimate concerns of another financial crisis.
This past November 20th, Senator Ted Kaufman urged the Securities and Exchange Commission (SEC) to stop sponsored access all together. The issue argued by many against the senator’s move is that sponsored access accounts for more than 50% of the daily trading volume that occurs on exchanges today. Sponsored access has also created more liquidity for buyers and sellers, essential for trading.
A variety of firms have explored and invested in building a low-latent solution to address the concerns surrounding naked sponsored access. The solution they’ve built is a low-latent risk management application which sits on top of naked sponsored access. A division at NYSE Euronext, NYSE Technologies, calls their solution a Risk Management Gateway (RMG).
What does it provide? Sponsoring brokers can manage the risk of their clients through a web-based user interface that allow them to:
Manage a set of trade filters, that are configurable, and controls the level of risk for each of the sponsoring broker’s clients. Once a threshold is hit, the RMG can block further trading activity until a risk manager/administrator removes the block or resets the limits.
A means to visually monitor the level of risk based on all client order activity pre and post trade.
Cancel all orders, or specific orders, for a given client.
RMG, and other low-latent risk management products like it, may be a way forward to keeping the practice of naked sponsored access alive with secure enough safeguards to prevent abuse by high-frequency traders.
Technology is moving so fast that it’s hard for the SEC to keep up with deciding what the right amount of regulation is needed while understanding all the ramifications with or without it.
Click here to read more about the Wall Street Journal's article on 'naked' sponsored access.
Besides opening up it's eBookstore back in July of 2009, Barnes & Noble is now striking back at perhaps its strongest competitor, Amazon and its Kindle. The Wall Street Journal has announced that B&N will be unveiling their own eReader, produced by E-Ink. It is widely speculated that the product launch will be on October 20th. Now B&N understands that an existing customer of the Kindle is a lost customer to them, basically because the Kindle funnels the customer to Amazon. I speculate that some of the tactics B&N will use to attract customers who don't already have eReaders today, as well as enticing those who currently use Kindles, are:
Leveraging B&N's existing partnership with Plastic Logic and Irex, announced a few months back. This deal gives their devices access to B&N's eBookstore. Making B&N's book content not exclusive to just their own eReader and potentially establishes an "open device/source" policy for all e-book devices. Perhaps eventually pressuring Amazon to open their device up to using content not just from their store, as well as Amazon's content to be available on devices other than the Kindle (like the eReader). This may be B&N's strongest long-term strategy in potentially gaining some of those lost customers back from Amazon.
Promoting B&N's Book Club membership deals and expanding this into the eReader content. Customers may want to seize on the savings, and will be reminded of it by B&N's in-store promotions and shopping experiences.
Exploring an "e-book loaner" program to get non-eReader and Kindle users to take advantage of their new device. Users would be able to recommend a book to a friend, and electronically allow him/her to read the book from their own device. Details on how the program would work are still in the works (as per the New York Times' article), but the strategy could give the eReader an edge.
Lastly, besides using AT&T's cell network to download materials onto the eReader, B&N's device will also work on Wi-Fi (currently not available on the Kindle). This will allow B&N's daily 14 million in-store customer walk-ins to try out the eReader, further promoting the device.
Sony is still trying to edge its way into this market, but I believe Barnes & Noble has the ability to win a sizable market share if their new strategy gains traction. Anyone with other ideas for B&N to try?
Inc.'s September 2009 issue has a well-timed article for my current work environment in the financial industry, especially given the economic climate. It's an interview with John Kotter, the author of "A Sense of Urgency", and his thoughts on why urgency, not panic, is the key to moving your business forward.
Currently I find my work environment chanting a mantra of "doing more with less", and emphasizing the need for increasing our speed of delivery. All the while with all the noise and pressing demands, on a team by team basis, there is little focus on what matters most to the organization on the whole. Kotter's points out that in many organizations there are a lot of signs of false urgency. Your teams are working long hours and are just plain exhausted. "Frenetic activity," he calls it. That word accurately depicted some of the scenes I've been witnessing lately.
How do you distinguish between good and bad urgency? Well Kotter suggests one way of spotting the bad. Ask how hard is it for someone to schedule a meeting on your calendar? If it isn't easy, it means that you aren't leaving enough white space on your calendars to leave room for the important stuff that is going to happen and needs to be dealt with immediately. The unintended fallacy that people tend to believe is that during urgent times you need to take on more and demonstrate your value by being busy. Otherwise risk losing your position. Instead, Kotter insists we should be looking at our calendars and removing anything and everything that isn't moving our business forward.
This point resonates with me, and illustrates the value of being focused on what matters most. All too often I find the business is trying to please all of their constituencies at the same time with resources working at over their capacity. By doing so they're settling for mediocrity in their delivery and ultimately failing. Following Kotter's thinking, focus both your efforts and resources on the initiatives that meet the bottom line. And either delay the delivery to those other constituents, or completely abandon those efforts if they do not bring the value needed to meet the demands dictated by your organization's urgency.
To get there you need impassioned leaders. Leaders need to set the direction to get to the place where the entire organization is truly focused and seizes on the opportunity presented by urgent situations. Nothing will be gained by merely announcing urgency with lackluster and stoic rallying calls.
At the end of the article the topic of a leader's role in times of urgency is addressed. Kotter is notably quoted in saying, "True urgent leadership doesn't drain people. It does the opposite. It energizes them. It makes them feel excited. And the idea isn't so much that the leader is always showing emotion as that he's trying to produce the right emotions in the people he leads. But again, he has to model it. You can get people to respond rationally to a problem, but if you haven't stirred their hearts and minds, once the immediate crisis has passed, you lose them. The sense of urgency dissipates."
I think I'll be checking out Kotter's book on my Kindle in the coming weeks.
In continuing my postings around my takeaways from the Agile 2009 conference, while also promoting a post-Agile 2009 conference here in New York hosted by LiquidNet, I want to cover another great session presented by David Hussman.David is this year’s Gordon Pask award winner, and with his unique background in music performance and production, has applied a unique agile coaching style.He views coaching from a holistic approach, and designs his strategy with the organization’s cultural context in mind.
Perhaps the most important one-liner I was able to quote from David at his “Coaching & Producing Value” session was, “…bring the cost of failure to zero so we can do it a million times; failure is a learning tool.”I couldn’t agree more.But how do we go about bringing that about, without harming the organization and still increasing our agile adoption’s effectiveness?
Well David goes about listing what he calls “Pre-Production Tasks” in order to execute effective coaching and producing value to the organization.They are as follows:
Assessment – Interviews
Coaching Plans – Practice Selection
Chartering
Personas – Story Mapping
Creative Eco-Systems
Road Map Planning
For this posting I’d like to focus on the first two.
Assessment – Interviews
Here David recommends us to turn away from being an agile-zealot or purist, and with good reason.Implementing all of the agile practices in their strictest fashion will completely backfire unless the organization understands the values that those practices bring.Therefore to select and introduce these practices, the ones that makes the most sense for the culture and environment of the particular organization, need to be understood.The only way to do so is to spend time interview and assessing the organization and its people.Some questions he suggests to ask are:
How do they work now?
What works – what does not?
Why change?Why agile methods?
What strengths and challenges exist?
David emphasizes that in this change process of adopting agile a coach’s approach needs to be descriptive, “This is what I have seen work.” And not prescriptive, “This is what you should do.”A prescriptive approach will appear to be dogma, and dogma kills.
Coaching Plans – Practice Selection
With undersanding the context of the organization, its culture and people, you can start to understand and see how the agile practices fit into the scheme of things.Hussman organizes these practices into valuable groupings (pictured at the right).For the practices that you decide to employ, for their given grouping, you need to describe to your audience not only what you know about it (“the how”) but also describe the value of that practice (“the why”).
This and many other topics are planned to be covered at the post-Agile 2009 conference here in New York City. If you're interested in attending, please email me (grochejr@gmail.com) and I will be sure to send you the details.
David Hussman’s Agile 2009 conference presentation on "Coaching and Producing Value" at be found here.
In an article in today's Wall Street Journal, the Open Invention Network, or OIN, is seeking to protect users of Linux from "patent trolls" by purchasing patents formerly owned by Microsoft. For those of you unfamiliar with the term "patent trolls" it's generally a term used for groups that do not create products but acquire patents to earn financial rewards through lawsuits and settlements. OIN is made up of several major corporations such as IBM, Red Hat, and Sony.
OIN is currently seeking to acquire patents from Allied Security Trust (AST), another organization that purchases patents and provides licenses as well as reselling those patents on the open market. AST previously won several Microsoft patents in a private auction.
My next takeaway from the Agile 2009 conference is a session given by a mentor and coach of mine, Pete Behrens. First let me say that Pete is one of the best Agile coaches I’ve worked with. He’s trained me and even now continues to supply me with a wealth of new ideas and techniques to help me with my current endeavors in the financial industry. Pete shared some of these ideas and techniques at the Agile 2009 conference in his session titled, “Death by Scrum Meeting.”
Many of us can relate to the wasted time and efforts we spend in so many ineffective meetings at our organizations. For those organizations practicing Agile, following lean principles in every sense is the mantra. Therefore we should avoid long, multiple, and unproductive meetings and instead make them lean. If we’re practicing Agile, or specifically Scrum, how do we conduct effective, necessary, lean meetings? Well, below I highlight a few of the tips Pete shared.
The four main elements for keeping your (Scrum) meetings lean and effective:
Determine the focus of the meeting. Is it strategic or tactical?
Timebox the meeting.
Attendees need to be able to visualize what is being discussed by using color, sizes of objects, or calendar/timelines in your meetings.
Engage the team/attendees during the meeting by having them participate in it.
How should we timebox all of our (Scrum) meetings?
Pete recommends the following guidelines:
Daily Stand-ups: 5-15 minutes
Retrospectives: 15-30 minutes
Reviews: 30-60 minutes
Planning: 60-120 minutes
Release Planning: 120-240 minutes
Daily Stand-Ups:
They should be collaborative.
Team members should care about each other’s tasks, so that there’s vested interest in the outcome of each other’s work.
Perhaps try rotating who organizes the stand-ups so there's shared ownership.
Use the stand-up as a thermometer on how the team is doing and how they feel about the project and the organization.
Retrospectives:
Instead of asking the team “what worked”, “what didn’t work”, and “what should we start doing”, try focusing on just two aspects:
What went well? (What were the takeaways?)
What are the changes or improvements that need to be employed in the next sprint?
By focusing on these two questions at the retrospective you can quickly vote for the top three changes to employ in the next sprint. Also the timeboxing of the retrospective helps to avoid the meeting from just becoming a reoccurring “bitch-session”, or worse, a “bitch-fest.”
Reviews:
Try visually displaying:
The team’s commitment compared to what the team actually delivered.
Product progress by feature.
List specific work done within the current sprint.
The focus for the next sprint.
Planning Sessions:
Avoid using a software tool to help with planning during the meeting.
Try printing out your stories, with their details on a single page, and prioritize them from left to right on the wall.
Engage the team to design and break-down the stories via post-it notes or on a whiteboard. Instead of sitting down and talking leisurely about the stories and their requirements, the team is up and actively producing valuable information.
When estimating stories, try leveraging a technique that Pete calls, “affinity-based estimating,” as opposed to planning poker. I call it the “card-wall exercise.” Where we lay out all the outstanding stories on a wall and let the team members sort the stories from easiest to hardest (left to right). Afterwards I assign the story points as columns at the top of the wall and the team will then line up the stories underneath the points accordingly. I have post-its on hand to document any new stories or spikes uncovered during the exercise. This basically helps the team and I to document the conversation. This technique is especially effective when trying to estimate an entire backlog. Trust me; I know from personal experience after trying to get a team to slowly poker plan through each of the 400 outstanding stories over the course of several weeks.
There’s a lot more that was covered during Pete’s “Death by Scrum Meeting” at the Agile 2009 conference. I invite you to take a look at the presentation deck used at the conference (click here). Also to learn how Pete can help your organization’s goals of becoming more lean and agile, check out Trail Ridge Consulting.
On my first day at the Agile 2009 conference, and after my presentation there on “The Amazing Team Race”, I attended a session by J.B. Rainsberger titled, “Integration Tests are a Scam.”He wasn’t suggesting that integration tests aren’t needed, but rather the way they handled today by the majority of organizations is a lie; a scam.The title, an assertion, was a bit shocking for me but I attended mainly because the teams I currently manage face several challenges with regards to testing.What follows is what I learned from Rainsberger.
One main problem with integration tests have to do with excessive test setups.This causes:
Messy test structures.
Assertions to be repeated throughout the structure.
Programmers/testers to check all the different places to determine where the test precisely failed and why.
Another problem is that integration tests take a long time to execute.Is there a way to address this?Well, one problem Rainsberger asked is to determine how many tests are actually needed to consider your testing truly complete?Assume we have a large-scale application to test, and after considering all the combinations for complete test coverage we come up with 4 million tests.That’s 4 million tests we will never ever write.Therefore if we won’t ever write that many tests, what tests should we even bother to write?Some suggest writing a small percentage of the total possible tests that are geared to test 80-90% of the application’s functionality.Rainsberger throws out 2,000 tests as the number of tests that a team may actually consider writing for this large application.2,000 tests out of 4 million only cover less than 1 percent of the total possible number of tests.Even by selecting the “right” 2,000 “focused” tests to write, your chances for good coverage run somewhere in the range of 20-80%.And how do you know you’ve covered 20-80% of the application’s functionality in your integration tests?You DON’T!
Here’s where J.B. introduces the concept of “Basic Correctness.”What is “Basic Correctness” of an application?His definition is “…given the myth of perfect technology, do we compute the right answer?” Integration tests should NOT be needed to prove basic correctness of an application.His solution is, “…write only focused object tests for programming tests… this deals with 98% of the problems, leaving you to use the majority of efforts to address the 2% of tests that fail that aren’t address by your focused object tests.”
Steps to writing good focused object tests are:
Don’t test the platform.Trust the equipment and libraries that are being used.
When writing a single object to test with four other collaborating objects/points, use four interfaces for those four other points.Interfaces are not the actual collaborating object you are testing, but merely something that behaves like the actual collaborating object.J.B. also notes to only use interfaces for services.
Leverage the interfaces so you don’t need to actually test the other objects/points.
Test the single object to speak to itself, aka State Tests.
Create your focused Collaboration and Contract Tests.
Above is a diagram for what J.B. describes in setting up focused object tests.
What are Collaboration and Contract tests?Well to start, Collaboration tests are what J.B. refers to what others traditionally call integration tests.To have your collaboration tests be focused, you only need to ask two questions:
Do I ask the collaborators the right questions?
Can I handle the collaborators’ responses?
For example, perhaps your function needs to determine how many upcoming customer birthdays are there.Your focused test needs to ask of its collaboration point(s) to find the number of customers with a birthday in the next seven days.Your focused tests needs to handle the following responses: zero, one, many, or lots (for capacity and performance reasons perhaps).
When writing your focused collaboration tests, it’s important to handle the responses from the interface and not the actual object/point.Don’t do the backend work for the test.Leverage the interface.
Contract tests are a test for the interface you are leveraging.It’s also a systematic way for setting up tests reliably.They complete the other side of the test and in essence fulfill a contract.The two questions to ask to create a focused Contract test are:
Can the interface accept the question being asked of it?
Can the interface supply the responses expected?
In the end you have focused object tests that are succinct and complete in the verification of both what is being asked of its collaborators as well as ensuring that your collaborators can complete their side of the contract by supplying what is needed.
As shown in the diagram above, Rainsberger tells us that the number of tests needed is directly correlated to the number collaboration and contract tests per interface for each related collaborator object to the focused test object. This also eliminates the worry of the numerous combinations of code paths to tests. Therefore when you find a test failure, you only need to check in two places.So when referring back to the example J.B. gave us, as I mentioned in the beginning of this post, about an application with the need to have 4 million tests in order to have complete test coverage:
The need to create 4 million tests for complete test coverage has been brought down to 10,000.
Performance time in executing the tests is now shorter.
Actual effective test coverage can be achieved.
Pushes engineering towards a good modular design.
Your integration tests are sound and complete when you have:
State tests
Collaborator tests
Contract tests
Now J.B. admits that there may an issue in automating contract tests, but he suggests that there may be some workarounds.
Finally the benefits, which he says he has not been proven but that some PhD potentially could, are:
When integration tests fail, engineering will only need to check in two places for where and why the failure occurred.
Integration tests only need to be written into Collaboration tests and Contract tests.
There is no need to write integration tests during design.
J.B. Rainsberger is heavily involved with the Agile community and has spoken at many conferences. To learn more or follow J.B., be sure to check out his blog at: jbrains.ca.
To see a sample of what J.B. means by Contract tests click here.
This year's Agile conference in Chicago certainly did not disappoint. Besides presenting at the conference with my former colleague Belkis McCall-Vasquez on "The Amazing Team Race", there was plenty to learn and plenty of exciting people to meet.
This week, before Labor Day, I plan to devote my posts to highlighting some of the interesting lessons learned during my week at the Agile 2009 conference. Some of these highlights include:
J.B. Rainsberger's thoughts on how most organizations' integration tests today are a scam and how they can be more focused and effective.
Pete Behren's recommendations in running effective and successful Scrum meetings.
David Hussman's savvy approach in coaching and producing value for organizations adopting Agile.
Renzo Borgatti's presentation on leveraging the Pomodoro technique to get your teams focused on completing their tasks on a daily basis.
Luke Hohmann's approach to prioritizing your backlog for profit.
Scott Ambler's myth-busting approach to statistics he's found with organizations using Agile.
Finally, the entire conference was honestly a great learning experience and even a lot of fun. It included Muzik Masti music every night, engaging networking events (especially those put together by ThoughtWorks), and a fun night on a Lake Michigan cruise around Chicago with fireworks hosted by VersionOne. To the right is a picture of Jeff Patton, Belkis McCall-Vasquez, myself, and Pete Behrens in front of the Mystic Odyssey for our cruise that evening.
An interesting talk given by Alistair Cockburn during his keynote speech at the Agile 2009 conference today. His speech was titled, "I Come to Bury Agile, Not Praise It." Don't be mistaken. He's not suggesting that Agile is dead, but rather that we all need to seek to effective means to apply Agile principles to our circumstances. One idea from his presentation I'd like to highlight here is his thoughts on the Japanese words of:
Shu - meaning to learn, a technique that can be generally applied.
Ha - meaning to collect, techniques to be applied.
Ri - meaning to invent or blend, techniques to be applied.
The Japanese characters for "Shu, Ha, Ri".
All too often, many of us (especially novices) look to learn a specific technique to apply to our own work and circumstances. Alistair suggests that the "Shu", or the learning of a technique is just the beginning. When you learn one technique and apply it to your project work, you will find that it may work but not necessarily optimally. When you seek to refine your technique, some tend to "Ha," or collect a string of techniques to see which can be applied to his/her projects and work environment. Kind of like having a toolbox of tools to use that could be applied to each unique circumstance. Alistair challenges us as professionals to leverage "Ri" and invent/blend techniques so that they are customized and are compatible for the unique circumstances your work environment needs. It is only when we experiment and blend our learned/collected techniques that real innovative value is achieved. You may not at first understand what it is you are actually doing, but clarity will be attained with your results.
"Ri" will be my mantra during my attendance at this week's Agile 2009 conference.
The Wall Street Journal (WSJ), in collaboration with MIT's Sloan Business School, came out with a Journal Report on Innovation this past Monday. It's a must read for most business professionals, especially for those who work in areas with a heavy focus on R&D and technology. Reflecting on my 12-year history with software technologies, especially on my enlightening time at McKinsey & Company, I learned the importance of innovation. Now that I'm currently working on some green field projects that are providing new products and services within the financial industry, I also see the importance of the strategies employed to seek innovation and stay competitive while maintaining low costs.
In leveraging certain strategies, some business executives believe they gain innovation, a competitive edge, and cost benefits through acquisitions of other organizations. In reality, after the attrition of some of the workforce during the re-organization that always eventually ensues, the business only gains innovative products and short-term cost benefits. Products are not the source of an organization's innovation. It is the talent pool of laborers within the organization, whether in R&D, engineering departments or elsewhere. I see this struggle when financial companies, seeking to provide such things as innovative high-frequency trading services, under appreciate the value of the engineering talent pool and focuses solely on the headcount costs. Losing talent, in many cases, also means losing domain knowledge and the innovation that comes with it.
In my first post regarding innovation, I'd like to point to a recent event in the technology world where a specific strategy to gain innovation was used, the acquisition of FriendFeed by Facebook (see TechCrunch's take on the acquisition here). Now FriendFeed had 989,000 unique users in June. Compare that to Facebook's 340 million, all according to comScore, and you can see that the acquisition wasn't done for market share. There was also a clear overlap in features and functions in what both Facebook and FriendFeed offer. So what was Facebook's angle in doing the acquisition? Talent acquisition. FriendFeed's 12 employees, all but one is an engineer, clearly demonstrated their ability to quickly innovate and deploy new products. Products that raised the bar on what Facebook could currently offer with it's comparable features. This talent pool was the asset that Facebook sought, especially in their quest to competitively battle Twitter. (Note: Facebook failed to acquire Twitter last year.)
Although the future of the FriendFeed application remains uncertain, the belief is that the talent pool from FriendFeed will integrate the existing features onto the current Facebook application and further their innovative design mind-set within the engineering organization at Facebook. In their WSJ Journal Report article on innovation, "Finding an Innovation Strategy That Works", Frank Rothaermel and Andrew Hess state, "...we found that the most effective way to achieve continuous innovation over the long term is to hire and cultivate talented people."
To learn more about Facebook's need to absorb FriendFeed's innovative features, as written by CNet, click here.
Students at universities all across the country have been complaining that their inboxes are too small for the tsunami of emails that they receive on a daily basis. As a result, many universities have been outsourcing email services to companies such as Google and Microsoft. Most entrepreneurs and businesses would see a profitable business opportunity to charge at least small fee for such services to universities, just as several already do for companies. The interesting thing is that Google and Microsoft charge nothing to the universities for email services.
Universities benefit in cost savings by avoiding costly equipment upgrades/maintenance and number of employees managing information technology services. Also students' satisfaction with a university's outsourced technology services, in this case email, dramatically increased. So what's in it for Google and Microsoft? College students are generally early adopters of new technology. The idea is to gain the participation and feedback of students for other web services, beyond email, being developed and deployed by Google and Microsoft. The hope is to gain early acceptance and adoption for those products/services and have them become mainstream. This approach doesn't only apply to companies following a Web 2.0 model. Chris Anderson talks about such strategies leveraged by cutting edge companies in his book, "Free: The Future of a Radical Price."
So...got a new idea? Desire early and free feedback to perfect your product or service? Want to quickly gain market share? Then consider rushing out to offer it for free to the students of your nearest university before your competitors do. Come to think of it, didn't Facebook start off as a college social networking site?
Here's retired Dave Bradley of IBM, the inventor of the "Ctrl + Alt + Del" shortcut and how it evolved to become so popular. Interesting reaction by Bill Gates...
In an article on the front page of today's Wall Street Journal, Starbucks is leveraging a new discipline and practice to their culture, 'Lean.' After making some comparisons on the ability of their fast food chain competitors (McDonald's and Dunkin Donuts) to service more customers in shorter time, it seems that now Starbucks sees the value in the Toyota Production System (TPS) where lean process and fast delivery, without compromising on quality, is paramount.
What does this prove? That lean processes, such as Agile or TPS, are not strictly defined methodologies that may only prove to work in certain environments, but that they are mere frameworks that can be tailored to work for your organization's needs regardless of the industry. In the end the idea is to:
Streamline the waste and needless bureaucracy.
Free and empower your organization's members to focus on delivering the highest business value.
Enable your teams to become high performing.
Any thoughts on how lean practices could benefit other organizations in industries outside of automotive, technology, or food services?
I'm technologist with over 12 years experience in software development in several different industries: at start-ups and F500 companies. I'm also a former firm member at McKinsey & Company, a certified Scrum Master and an experienced Agile practioner and coach.
I started b-Speaking to share my professional experiences and lessons learned, as well as engage with and learn from the community about general business technology and trends.
Using data replication in legacy displacement
-
*Alessio Ferri* and *Tom Coggrave* complete their article about introducing
seams into mainframe systems by looking how we can use data replication.
Done...
Progress on the Block Protocol
-
Since the 1990s, the web has been a publishing place for human-readable
documents. Documents published on the web are in HTML. HTML has a little
bit of… Re...
