Today consumers expect more from their multichannel TV service than they did even just a few years ago. Thanks to the proliferation of compelling apps available on mobile devices, combined with generally elevated expectations from retail services fuelled by Netflix, Amazon and others, Pay TV providers today know they have to work extra hard to keep subscribers loyal.
Service providers everywhere are overhauling their existing services and launching entirely new platforms. They are investing heavily to augment Pay TV offerings with new applications and services which consumers have grown to love online and on their phones. This includes the ever-growing array of compelling features populating the Google-sphere enabled by the increasingly popular Android TV Operator Tier proposition for service operator platforms.
Rolling out a new Pay TV platform has never been easy, especially for set-top box (STB) offerings. As our industry has evolved, the complexity of systems has grown, and today a formidable cast of vendors are involved. Providers of STBs, content protection, middleware, front-end, back-end, player components, recommendation engine, video transmission platforms – just to name a few key items on an operator’s shopping list – all need to be wrangled and work harmoniously together.
Furthermore, they all need to integrate seamlessly with vital back-office business operations including content management, subscriber management, customer care and billing. Then there’s the integration of popular apps and services, and advanced features like voice control. Netflix is now a ‘must-have’ and viewers are loving being able to easily access their favourite Google services via the Android TV powered STB. Behind the scenes, though, integrating and certifying Netflix and ensuring timely and smooth operation with all the very latest guidelines and standards from Google are both critical resource-intense responsibilities.
Considering all this, launching new platforms and services quickly and elegantly is no mean feat. Given the dramatically increased complexity of such projects some potentially disruptive changes in the development and delivery environment must be considered. Alternative project approaches in this complex world are, by necessity, being introduced.
Furthermore, the traditional roles of the multiple parties involved in the sophisticated platform deployments of today are changing to meet tougher delivery schedules and budgets. Savvy professionals in our field increasingly need to be nimble and willing to adapt.
Stephen Hawking famously said: “Intelligence is the ability to adapt to change.”
We are seeing that projects are being managed differently these days, with new kinds of team structures that reflect how roles and responsibilities of stakeholders are shifting, both in-house and with third-party providers. The change from the old-style top-down decision path towards greater empowerment of the delivery team is becoming more visible in our industry. And frankly, for sheer expediency, this change in the way of doing things is essential.
The established ‘assembly line’ approach to application development for multiple devices – where an app for one device is completed, then handed onward to an integration team, and then passed to operations specialists for adaptation for the next device – is becoming a thing of the past. Tighter, more parallel integration of all project stages is becoming more prevalent. The point is, people involved in project delivery today are already recognising that the sands are shifting. Hopefully, they see opportunities and advantages of this new reality.
Powering true agility
“Agile” has been a ubiquitous buzzword for a while now. Originating in the traditional software industry, the concept of agility is getting slowly adopted for product development in other business environments. For established media companies, publishers and large telcos looking to deliver next gen TV, agile working is of significant interest.
In the ‘classic’ model for a major project deployment, a great deal of time and effort is invested in defining and drafting technical specifications and UI/UX design in advance of any ‘real’ work starting. After teams have agonised defining and writing specs, an RFP is issued to multiple vendors. Proposals are received, evaluated, queried and finally a contract is awarded. Detail definition, development, quality assurance, integration, and acceptance all then have to follow step-by-step before the magic eventual ‘Go-Live’ date.
This method of implementation typically means that easily a year or more can elapse before even one subscriber can switch on the great new service. Furthermore, the time period between definition of the product and seeing a real, functional result can be extremely, sometimes excruciatingly, long. This means that concepts defined many months in the past can only be verified for usability very late in the process. If something isn’t right, it may mean drastic changes in requirements (even downgrading of expectations) and sudden major delays. Risks are numerous and their consequences are serious, possibly deal-breakers.
Such a work mode is simply not fast enough in today’s competitive landscape. Service providers are demanding more operational and cost efficiency, as well as speed, from their new product launches. Teams tasked with delivery face new pressures. Understanding the theory and practice of agile delivery can be a game-changer.
TV projects today are benefiting from the employment of agile project delivery practices. These principles, such as SCRUM or Kanban, are being introduced to counteract the challenges described. These methodologies allow the individual teams to dramatically reduce lead time between definition and delivery of a product, cutting waste inside projects, and increasing stakeholder satisfaction. The core concept here is empowerment and trust in the delivery team by the stakeholders.
The concepts are being successfully applied in a wide range of mid-size TV projects. However, for big multi-platform projects with numerous dependencies and a larger set of involved parties, extensions to these techniques are required. One paradigm which has been applied successfully in the multiscreen world is the use of SAFe (Scaled Agile Framework). SAFe takes the agile concepts of SCRUM and Kanban to the next level, enabling scaling and broadening of reach, blending in multiple third parties for major delivery projects. SAFe is becoming increasingly popular and has proven successful in accelerating and optimising large scale system deployments.
Managing dependencies while SAFely ensuring forward momentum
We occupy a complex world today with multiple dependencies. Many parties are involved in modern multiscreen projects and inevitably, this throws up surprises and challenges along the way. You sometimes discover that some of your pre-conceptions of how things work, and how elements fit together, were wrong. Unanticipated additional time, money and staff requirements might be necessary to get back on the correct path.
Going back to the drawing board is a very expensive worst-case scenario in traditional delivery projects.
Embracing the ways of true agile development cuts these unwelcome surprises to a minimum. Less time is spent in detailed advance planning and predicting what the long-term will look like based on hypotheses and conjecture. This lowers the risk of making plans based on incorrect assumptions, and of failing to account for time and resources for unplanned activities. In SAFe, for example, the timeframe to complete any product increment typically ranges between two and four months. This is short enough to react to the unknown, but long enough to ensure a decent progress rate. This is not to suggest that using SAFe or other agile concepts for long-term planning is inappropriate – we all still have long-term business roadmaps on our minds. And SAFe has the means to accommodate this as well.
Agile is all about minimising waste – of time, energy and money. By closely managing elements in parallel, you can concurrently adjust what you do to advance multiple parts of the project along the way, on-the-fly – you can shrink the timespan from specification to shipping a product to just a few months.
Meanwhile, the operator can feel confident and still retain a high level of control: The difference is that rather than having one lengthy delivery phase, you simply have many more small ones, with success building on success, thus reducing risk, getting greater nimbleness, and far better ability to react to new information. And all the while, in-house staff and vendors can all see with their own eyes a modular, iterative progress of sign-offs and continuous forward momentum.
There is an additional and very welcomed outcome of this: It is highly motivating for everyone involved.
Similarly, we are seeing that operators are benefitting by placing greater trust in technology providers – considering them to be long-term partners rather than ‘vendors’. By considering tech partners as virtually embedded on the team, operators can reap maximum benefits from sometimes very extensive real-world experience gathered from deployments that might have taken place on the other side of the world. They hear deep subject-specific expertise face-to-face, brought to the table by people who feel ‘invested’, something which otherwise would be prohibitively expensive to hire in.
With ever more complex projects, inter-dependencies among all the teams and individuals are far more complex, and frankly, almost impossible for any individual to oversee and orchestrate to a high level of reliability. Monitoring and ensuring granular control and perfect alignment of multiple vendors and in-house staff needs a new kind of collaboration. Encouraging ‘self-organised teams’ is a pragmatic response to inter-connected tasks.
With the agile development philosophy, all teams are always kept apprised of all aspects of the work. All people working on the project have a greater understanding of how much they rely on each other, every hour of every day of the project, and they will more likely pull in the same direction.
A much greater sense of individual accountability, as well as closer friction-free co-operative working, can make a dramatic difference in the smoothness and speed of the deployment.
SAFe makes delivery a more iterative process. This involves greatly increased regular communication, from daily stand-up meetings to reviews and retrospectives. Compared to SCRUM, SAFe adds cross-party product increment planning meetings, cross-team objectives, and last but not least common risk management.
The result of all these forces is faster-time to market and higher quality and reliability of services.
Becoming agile may require culture change
While many organisations say they are embracing agile development, the fact is, truly doing so requires an organisational culture which in reality is sometimes very different from that of many companies, especially big ones.
In most organisations, a delivery team can only progress and move on to the next task after approval from a more senior manager. But as said earlier, today’s complex projects can require hundreds or thousands of small decisions to be made each week. We have seen that decisions can be far more powerful and much, much faster when the team as a collective is allowed to prioritise and agree decisions and to immediately move on. But having this level of empowerment and trust in every team member can fly in the face of hierarchical company cultures.
In parallel, responsibility for delivery is moving towards Product Leads and away from traditional project managers. These product leads are tasked with the concurrent responsibilities of resource management, technical delivery and commercial RoI/service profitability. Basically they are effectively charged with running their own micro-businesses. This new reality might well completely change what is expected from a Project Manager. A PM accustomed to the overarching power of technical delivery, sitting both at the pinnacle and the hub of the project team, may be entering a new world.
The SAFe methodology is a pretty radical way of doing things in the TV delivery industry. But the positive outcomes speak for themselves. And operators who embrace SAFe and other agile principles are becoming its latest and most vocal evangelists.
When every individual on the team feels personal ownership in the project’s success, and feels accountable for when things go well and when they don’t, you have a community of expertise and energy working together with a common vision.
A best-possible outcome is ensured, with the service provider and subscribers all reaping the benefit. www.3ss.tv
Find out how SAFe was used for the Com Hem Android TV Operator Tier deployment
Videonet is hosting a live webcast on Tuesday, June 5, taking a detailed look at the project that resulted in Com Hem’s new generation set-top box, which is based on Android TV Operator Tier. This project used the SAFe methodology and this will be one of the areas discussed. See more details about, and register for, the free webcast here.