(Click below to see the live newsletter)
More than a few prognosticators have identified WebRTC as one of the tech innovations that will make a big difference in the coming year—and with good reason. Several major firms—Google, Microsoft, Citrix—have WebRTC initiatives underway, anticipating that the technology will find widespread use for consumer and business applications.
WebRTC (the RTC stands for real-time communication) is a framework that allows developers to embed real-time audio and video communication in browser-based and mobile applications. Google released WebRTC as an open-source project in 2011 and it has been picking up steam ever since, with browser developers Mozilla and Opera coming on board.
How will WebRTC reshape the technology landscape in 2015?
The medium and the message
It’s often difficult to predict exactly how a new technology will impact an industry and the culture at large. When, in 1964, he famously wrote, “The medium is the message,” Marshall McLuhan meant that the most significant effect of a new medium (such as a new communication technology) on the environment in which it’s released is often a result of the characteristics of the medium itself, not necessarily the content the medium conveys.
In the case of WebRTC, most industry observers are looking at how it will shake up existing services like telecommunications, online chat, and remote conferencing. And indeed, that shakeup is well underway. Skype is working on a WebRTC powered, web-based version of its service, for example, and services like appear.in, talky.io, and apprtc already use the technology to provide browser-based video chat. On the mobile front, Amazon is already using WebRTC to provide instant real-time tech support for its Fire devices through its Mayday service.
Clearly, there is a great benefit to embedding real-time audio and video in web and mobile applications without plugins. But, the fact remains that real-time audio and video already exist (albeit, with plugins). The real value of WebRTC won’t be in simply enhancing existing applications. The true message—to use McLuhan’s terms—of the medium of WebRTC has yet to be seen. We might not understand its full ramifications until it is supported by all browsers and developers begin to take full advantage of its potential to provide real-time communication, anywhere and anytime.
Let’s take a look at some of the things that might happen in 2015 to get us to that point.
WebRTC in the New Year
One of the most promising developments for WebRTC is that Microsoft has confirmed it will support the ORTC API for WebRTC in a future version of its Internet Explorer browser, joining Google (the maker of Chrome) and Mozilla (the maker of Firefox), which already support it. This will not only increase interoperability between the browsers in 2015, but it will also expand the technology to a much wider swath of the general public (with the notable exception of Apple Safari users).
Any browsers that add support for WebRTC in 2015 must also support both the VP8 and H.264 video codecs. Long a sticking point between them, WebRTC collaborators reached a compromise on video codecs in November. This was significant because, without a common codec, the dream of simple peer-to-peer applications or even “simple or lightweight” applications may have died. The need for transcoding would introduce and expensive middleman that would “kill” many peer-to-peer services.
Mobile support for WebRTC undoubtedly improved in 2014, as many chipset vendors started offering hardware-based support for VP8, which boosts performance and battery life. However, most WebRTC platform vendors are still focused on offering SDKs for building local applications. To achieve the vision of browser-based, ubiquitous real-time communication, this local mode of thinking needs to change in 2015.
Finally, we have already seen some consolidation in the market and acquisitions that indicate that major companies are taking WebRTC seriously. For example, telecom giant Telefonica bought TokBox—creator of the WebRTC video platform OpenTok—in 2013, Yahoo acquired WebRTC startup PeerCDN, and Snapchat acquired AddLive. We expect more such acquisitions in 2015. Meanwhile, the leaders in WebRTC technology, will become stronger.
Will 2015 be the year for WebRTC?
We expect that WebRTC will continue to gain strength in 2015 and will start to become a necessary element of consumer and business applications for communication and collaboration. But we don’t think it will necessarily be the year that WebRTC drives a new mode of engagement and interaction throughout the Internet-using world.
Bill Gates said once, “Most people overestimate what they can do in one year and underestimate what they can do in 10 years.” We think this applies to WebRTC.
As the technology is refined and standards are agreed upon and adopted, most of the soon-to-come applications of WebRTC will be the obvious ones: web conferencing, video chat, and so forth. The really interesting developments, the ones that will take a robust technology and apply it in exciting and unforeseen ways, are still a few years off.
Is your company doing Agile for real or are you only pretending?
It can certainly be effective (as we wrote about in our last article) to introduce Agile to small, self-contained units of your company before adopting it wholesale. However, we have seen numerous companies attempt to adopt the Agile methodology another way: with the company-wide implementation of a software tool. The problem we most often see with this approach is companies mistaking a tool that can be used in an Agile process for the Agile process itself.
Agile is not a software tool; it is a methodology, a way of getting work done. The various software tools that have been developed to support this methodology—while often useful when configured correctly—will not, in and of themselves, deliver the results most companies are looking for when they decide to try Agile, specifically, a faster and more flexible software development cycle.
This is why we say some companies are only pretending to do Agile. Consider the following example:
It’s Not the Tool; It’s How It’s Used
A software company had been trying to follow the Agile process for several years but hadn’t seen the results they expected. When they called us in for help, we found a semi-chaotic scene. The company had been using Trac, an open source project management system frequently used in Agile projects. The problem was, the company wasn’t using Trac correctly to support an Agile process.
Part of the problem was the tool itself. Trac has very restricted resources, demanding repetitive and tiring operations on the part of its users. As result, at this particular company, users frequently failed to update the status of their projects in Trac. It was also common to see people working on projects that had not been mapped into the system at all.
Our first priority was to get this company using Agile correctly, so despite its flaws, we did not throw out the tool. Instead, we helped the company use the tool to deploy the Scrum methodology (an Agile framework) for a single project.
Using the company’s existing tool, we:
And, we made sure statuses were kept up to date.
By using the tool with all the rigor required to do the job right, we were able to impress the company with the results we achieved following the Agile methodology. We were also able to demonstrate the limitations of Trac, and the company has since migrated to JIRA, a much better tool, in our opinion, for implementing the Agile methodology.
Proof of Concept
The example above shows that the most effective way for a company to start out with Agile is not to force a new software tool on its employees without regard for how it’s used. Instead, the best way to transition from a traditional software development process to Agile is to start small.
Try Agile out with a single team working within a larger project. At this point, you don’t need to worry about what software tool the team is using. You can always change that later on. At the beginning, the important thing is to adopt all the critical elements of Agile: user stories, epics, tasks, and so on. Once this small unit has demonstrated the effectiveness of Agile you can point to their success as a proof of concept as you expand Agile throughout your organization.
(Click below to see the live newsletter)
In November, a group of us from Daitan Group attended the leading WebRTC industry event, WebRTC V, held in San Jose, California. The event sparked several conversations between us and our customers comparing the current status and expectations for this technology.
Then we remembered that after we attended the first WebRTC event back in November 2012 we had written about the key takeaways and thought it would be fun to see how things had changed or not over the past 2 years!
2014 Reality and Projections
There were several facts and figures presented throughout the conference demonstrating the impact of WebRTC. Here are a few of the published facts:
o There are 1.5B WebRTC-supported devices today that will grow to 6B by 2019.
o Also by 2019, there will be 2B individual users.
o More than 10 telecom operators have some WebRTC related service, and telecom operators could have as many as 500M WebRTC users in the next 5 years.
Our own EVP of Sales and Marketing, Graham Holt, sat on a panel discussion relating to WebRTC and Carriers which concluded that there is, as of yet, no creative new services leveraging WebRTC. The Carriers’ role as bitpipes is still generating revenues for them but we continue to question if they are moving closer to the bottom of the value/revenue chain.
The undisputed, most significant impact of WebRTC has been in video conferencing. There are as many as seventy-seven video conferencing solutions available today along with enterprises implementing video conferencing in their existing communications services. Using WebRTC, business communications are rapidly changing to provide easy access to web conferencing for employees and their customer related contact centers. This is basically innovating old or existing communications methods proving the point that WebRTC is not creative.
Maybe it’s enough to give WebRTC credit for being a game changer in other ways. After all, WebRTC provides developers with the fundamental building blocks for plug-in free, high-quality, real-time communications in a browser such as voice and video chat applications and that’s no mean feat.
However, history has shown time and again that a “new medium” is typically misused to replace the old medium in the same applications before finding its true new place in the world. Remember, “The medium is the message”. (Marshall McLuhan).
In our 2012 blog, we stated that there were several reasons that WebRTC for mobile is difficult and specifically mentioned the lack of support for the VP8 codec in hardware. Several mobile devices are now shipping with VP8 support in hardware which has a significant positive impact on power consumption and performance.
There are still some big challenges which have led to the development of mobile SDKs implementing WebRTC. While this is good news in some ways it rather kills the idea of no plugin, no download.
For the optimistic we may believe that things will change soon. Industry reports coming from the IETF (Internet Engineering Task Force) RTCWEB working group meeting, state that a compromise has been reached to make support for both H.264 and VP8 mandatory for browsers. As reported by Andreas Gal, chief technology officer at Mozilla, “This compromise was put forward by Mozilla, Cisco and Google. The details are a little bit complicated, but here’s the executive summary:”
This is a major step forward for developers as it provides interoperability with any WebRTC endpoint alleviating the need for transcoding as well as ensuring better performance, costs and even battery usage.
For mobile, this still does not solve all the issues. So our statement that WebRTC on mobile is hard but worth the effort remains true today.
Back in November 2012 we wrote:
“Another popular subject of interest was interoperability with existing communication standards. WebRTC will provide a great platform for many new communications applications to be embedded into websites and other web based applications, and in many cases these can be complete end-to-end solutions using WebRTC. Companies today, however, have already made a huge investment in their communication systems for customer interaction, such as call centers, CRM integration, etc., and for their own workforce.”
In 2014 we believe this is still the case. As WebRTC evolves even more towards web architecture and away from telecom architecture the most common request we get at Daitan is for SIP interconnect and interop with legacy video endpoints. Interestingly, the first project we executed in WebRTC was a signaling and media gateway to allow interop with legacy video endpoints which was soon followed by requirements to interop with MS Lync. Interop is now much more feasible as this capability is appearing in commercial off the shelf SBCs, Media servers and gateways.
WebRTC should be available as a standard in your favorite browsers by the end of 2012. This was a stake in the ground that most were claiming at the 2012 event, including us. In 2014 many people are claiming that “WebRTC should be available as a standard in your favorite browsers soon” and it seems to be now more feasible with recent announcements from Microsoft and Google.
In October, Microsoft joined Google and others in support of ORTC (Object Real-time Communications) API for WebRTC, opening up real-time communications development for Internet Explorer. Shijun Sun, senior program manager for Internet Explorer, explains in the October 27th IE Blog, “We aim to make browser-based calls more convenient by removing the need to download a plugin. It’s all about convenience – imagine you’ll be able to simply open IE and make a Skype call to friends, family, or get real-time support for that new device right from your browser.”
There are still open questions about video codecs and how compatible different implementations of ORTC might be but let’s all hope that interop will soon be a reality across the major browsers.
The final cornerstone will need to come from Apple to have Safari and iOS join the WebRTC ecosystem.
In 2012 and even today, there is the consensus that WebRTC is a great contribution to communications technologies but it is not a fit for all of the existing or traditional communications infrastructures and services.
Douglas Tait, director of Telecoms Markets at Oracle, outline three areas where WebRTC has what he refers to as “The Chasm” between WebRTC today and its potential.3 These include:
o Identity, authentication and authorization
o More user name and passwords
o Network Denial of Service
o Lose sessions on browser refreshes or network issues
o Lack of support for large networks with many sessions and many connections
o Between networks
o Browser and devices
o Voice and video media
o Policy, charging, or internet traversal
From this list, it isn’t hard to see why WebRTC is not ideal where there are significant security concerns such as in 911 or highly regulated communications systems. While it may not be a fit for all communications services, it has had a significant impact on customer facing web solutions that extend companies' customer service and sales capabilities.
Although we were off on a couple of our predictions of WebRTC’s impact, the advancement of this technology of WebRTC has been extraordinary in the last two years. It is easy to fall back to the position that WebRTC is just a technology but we continue to believe in Marshall McLuhan’sclaim that “the medium is the message.” If proved true, then in this case it will mean another significant change in human communications.
Does a little Agile go a long way or is Agile an all-or-nothing proposition? For companies confronting the inadequacies of traditional software development methods and looking at alternatives, this is an important question.
Agile is certainly an attractive process to companies that want to respond quickly to their customers’ needs, adapt to rapidly shifting environments, and accelerate the time it takes to develop and ship new or improved products. But, it also represents a major shift in thinking—especially when traditional attitudes about software development are ingrained deeply among the members of a development team.
With the size of those teams often reaching into the hundreds and even thousands, some companies are warily eying the task of shifting the thinking of that many people and asking, “How much Agile do we really need?” Is it possible to realize some of the benefits of the Agile methodology without going “all in”?
Everybody on Board
For an Agile project to work, everyone involved with the project needs to be on board with Agile. If someone in the chain of stakeholders is not, eventually, something will go wrong. If the entire company is following the Agile methodology, that chain might need to extend on up to the business stakeholder, which, for a smaller company, could even be the CEO. Because Agile is such a radical departure from the traditional approach to software development, it can only be effective if everyone is speaking the same language.
Here are some of the key concepts everyone in an Agile process should understand:
Things Could Change
In contrast to the traditional development process, in which a single product has several set-in-stone requirements at the outset, without consideration that they might change, Agile calls for more flexible goals. Features may change over the course of the project, and if anyone involved is not prepared for that—is expecting the features to remain well-defined from start to finish—it could cause confusion for this person and the entire team.
The Product Owner
The product owner is an extremely important role in the Agile process because product owners speak for the customers. They are the ones who identify which features of a product will deliver value to the business and which are less important. Unfortunately, lack of a product owner or the unavailability of a product owner is a common failing of many Agile projects. If the product owner is too busy to answer questions, or doesn’t understand his or her role, the team will lack the critical information they need to keep their work on the right track and the product will begin to drift away from what the business and the customer really needs.
The backlog, according to the Agile methodology, is the ongoing list of requirements for a product. It can include features as well as bug fixes—anything deemed necessary for the product. The key to working with a backlog is to not let it stagnate. The backlog should be continuously reviewed and prioritized according to the business value of each item. Anything in the backlog that is no longer valuable should be discarded, for example, an older technology made obsolete by a newer one. Careful backlog maintenance will ensure a team’s energy is directed only towards work that creates value.
Collaboration is the engine that powers Agile. The continuous feedback and sharing of knowledge drives the process forward. When “heroes” try to go it alone, keeping information for themselves and ignoring aspects of the project that fall outside their specific areas of expertise, this engine comes to a halt. Sometimes these heroes are just stuck in their ways. They figure what’s worked for them before should always work. But fortunately, more often, hero syndrome is just a symptom of a lack of understanding. Once these heroes understand how they can benefit from the sharing of others, they’ll be more apt to collaborate themselves.
The Definition of ‘Done’
There’s done—when the bulk of the work required for a certain task is completed—and there’s what we call “done done.” “Done done” is when a task is really completed. This is when it has reached the common definition of what a finished task should be and the team member can move on to something else. For example, “Your task is done when your commit your source code to SVN.” Or, “Your task is done when you pass the acceptance criteria.” Whatever it is, the definition of “done” should be understood and adhered to by all members of a team, otherwise sprints will end with incomplete tasks and will fail.
To return to the question with which this article began, how much Agile is enough Agile? Clearly, there are certain elements without which the Agile methodology is ineffective. The five identified above are some of the most critical.
Still, it is possible to implement Agile on the small scale and grow from there. One of the best ways to do that is to isolate a small cell within a larger traditional software development environment and use Agile for that project (or element of a project) alone.
For example, on a recent project, we worked with a software team that had become accustomed to traditional development methods. We were finding it difficult to get the entire team working according to the Agile methodology. So, we split the team in half, one using Agile, the other not. As the Agile team demonstrated the value of the process, we gradually increased its size and decreased the size of the traditional team, until everyone was on board with Agile.
Then things really started to move.
By starting with small, self-contained Agile units, and scaling up, companies can benefit from the Agile methodology without the difficulty of implementing it before everyone is ready to get on board.
Page 1 of 9