At the Bits&Chips Software Engineering conference Frank Penning, PMO manager from Philips Lighting, talked about their experiences with implementing SAFe elements in an organization that is using Scrum.
InfoQ interviewed Penning about the main challenges that Philips Lighting is facing in product development, why Scrum is not enough, how they apply SAFe, and the benefits that they have gained from deploying agile methods for product development.
InfoQ: Which kinds of product does Philips Lighting develop, and what is the contribution of software in these products?
Penning: The hue system provides for the best lighting experience in your home, that is upgradeable and extendable with new functionality from Philips, our partners and the developer community. It includes local control via mobile apps, wireless switches and out of home control via the internet accessible on our app or web application.
The hue lighting system for the home, consists of a whole range of lamps an luminaires – that are all internet accessible via the hue API. There are more then 300 mobile apps available for the lighting system and we provide our consumers with new functionality via frequent SW upgrades. The systems functionality – embodied by the software in various components is the key differentiator and reason for consumers to prefer our system over our competitor’s solution.
InfoQ: What are the main challenges that Philips Lighting is facing?
Penning: Our main goal is to make our lighting system easy to use and easy to understand for consumers. We do not want our consumers to be bothered about technology choices or hurdles. Our products need to work "out of the box" in a very intuitive way. The technical complexity of our system needs to be masked in day to day use, but the diversity of use cases makes it difficult – if not impossible - to model all behaviour. Our various teams build system components that in the end need to work seamlessly together. The integration into a system and the subsequent verification and validation of that system poses a challenge to do so in a predictable and repeatable way. The internet infrastructure as a particular example is different in many ways – dependent on country, internet provider, type of router and home settings in the end can make or break the performance of our system. It is simply impossible to test all possible configurations, and – in contrast to for example professional business – we cannot send an engineer to every consumer’s home. Hence the strategy of testing – be it unit, product or system – is key to have sufficient coverage to ensure the best user experience and a excellent working system.
InfoQ: Can you explain why is Scrum not enough for your organisation?
Penning: Scrum in itself provides for a very engaging way to have focussed, self steering teams drive developments with their creativity and energy towards a result that delivers value that our consumers want. Scrum is not enough however, as
- in a multi geography, multi competence and sizeable organisation our system architecture demands for frequent alignment and integration between scrum teams.
- we need to deliver new innovations to our customers and markets in a reliable manner that dictate long term planning way beyond the upcoming few sprints.
- many of our products are based on cutting edge system interactions that require some form of derisking/pre development up front that would be too unpredictable or even impossible to only do in scrum teams.
InfoQ: Can you briefly describe how you apply SAFe at Philips Lighting?
Penning: We are in the process of experimenting with and deploying parts of the framework in our organisation. While doing we fine-tune and adapt, and sometimes explicitly choose to not follow SAFe. We use the three layered approach towards portfolio, programming and team level planning. Where needed (like in our hardware developments) we do not bother, and explicitly choose for different approaches.
InfoQ: How did you do program and product management before using SAFe? Which changes have been introduced with SAFe?
Penning: Along with our business growth came the need to scale. Our programming practice has followed this. We grew from a project environment focussing on our initial launch with an easy to oversee, easy to steer and easy to adapt set of activities to a sizeable business with underlying multi project environment. We have felt the need to add additional layers of program and portfolio levels to facilitate our decision taking and execution. So we have taken along these growth requirements in our processes and way of working. Changes in the size of the organisation are more prominent then changes as a result of our experimenting with SAFe – I would say that SAFe introduction is a result of this growth, and that the changes are managed by this introduction.
InfoQ: At the Software Engineering conference you talked about accepting partial predictability. Can you elaborate what you mean with this, and how this impacts product development?
Penning: The challenge of any business is to be both fast and be predictable. These are clearly contrasting. In the conference I used the quote of US race car driver Mario Andretti "If everything seems under control, you are just not going fast enough", to illustrate this. Without risk taking, and without the eagerness to beat competition in speed, predictability does not bring us far enough – Philips hue is in the end a recognized leader in the Internet of Things, and our partners and competitors are dictating the required speed of innovation as much as we are. We are finding the balance in delivering reliable innovations to the market, but we are necessarily flexible in some of the specification and functionality of our launches – in other words we do not promise everything.
InfoQ: Can you mention some of the benefits that you have gained from deploying agile methods for product development?
Penning: We have set out using agile methods from our early project phase, and arguably the biggest benefit is to have small empowered teams that take responsibility for their product. We have seen this work in engaging ways where best practice shows that teams take a lot of pride in delivering high quality. However, balancing the autonomy of teams with the integration of these products into systems has proved to be a challenge and we have felt the need to keep the notion of a role of Integral Project Manager to coordinate across the engineering teams – as well as other non engineering teams that together ensure a product going to market. This role is purely absent in the agile as well as the SAFE framework. Again, we implement some parts of SAFe, but are not orthodox.
