Hans Aerts, vice president software development and agile coach at TomTom will talk about SAFe, Scrum and Agile in embedded software development at the Bits&Chips Software Engineering conference. This conference will be held at the High Tech Campus in Eindhoven, the Netherlands on June 3:
Engineering robust, reliable software for today’s industrial systems is a major challenge. Software increasingly embodies the intellectual property that enables businesses to compete and as such is one of the major pillars upon which the success of a growing number of companies depends. And yet software engineering as a discipline often fails to meet the needs of organisations that are more and more dependent on it.
The Bits&Chips Software Engineering conference brings together leading figures from industry and academia to exchange knowledge, ideas and experiences about the challenges of engineering current and future generations software systems.
The conference will be covered by InfoQ with news and articles.
InfoQ interviewed Aerts about why they decided to adopt SAFe and how it was introduced and used to simplify the organizational structure and stop doing projects, why they focus on throughput rather than output, how they modified SAFe for Custom Systems, and what using SAFe has brought TomTom.
InfoQ: What made TomTom decide to adopt SAFe? Which benefits did you expect to gain?
Aerts: In 2012, Agile/Scrum was already used for years in TomTom, but could use some re-vitalization. Ideas within the organization on what to improve/strengthen were in line with the concepts found in the SAFe methodology. These ideas included:
- Rigidity in 3 months release iterations and 3 weeks sprints
- Time and Quality fixed, variation is in Scope (no too early spec freeze)
- Strong focus on quality, move away from "full feature, full bug"
- "Branching is evil": regular and frequent (not yet continuous) integration supported by a large set of automated tests
- Split into "must have" / "might have" stories on backlog of the teams
- Clear "Definition of Done", (binary decision, no 90%-done)
- No buffers on the critical path, no management by commitment, no milestones
InfoQ: Can you briefly describe how SAFe was introduced?
Aerts: In 2013 Scrum was re-vitalized and the SAFe program level was introduced:
- Driven by heads of development of the various Product Units
- External consultants hired to support deployment
- ~400 engineering staff trained
- Rally introduced for managing features and user stories and for estimating and planning iterations and releases
In 2014 the SAFe portfolio level was introduced, together with further deployment and refinement of the SAFe program level and the completion and automation of a set of KPIs
In 2015 there will be further deployment and consolidation.
InfoQ: You are the VP for software development and an agile coach. How do you combine these roles in your daily work?
Aerts: One of the key objectives for an Agile coach is to help the scrum teams improve. The same holds for leading a software development organization. So, the two roles have a large overlap, which makes it easy to combine.
InfoQ: Can you elaborate how TomTom simplified the organizational structure using SAFe?
Aerts: We defined roles in line with SAFe, and stopped all other roles. Also we simplified the organizational structure (SAFe like) with clearer decision processes and feature/code ownership. There is no project organization anymore.
InfoQ: Since there is no project organization anymore, how do you manage product development? What are the major decisions points, and how are these decisions taken?
Aerts: Most teams have now implemented Agile Release Trains, led by a chief scrum master, for managing product development. Release dates are fixed, quality is fixed, scope is variable. Scope is determined by the teams via decentralized planning, using fixed iteration lengths and team velocity measurements. Every sprint the teams show fully integrated, working software to key stakeholders. Once per release, an Innovation and Planning sprint allows for estimating and release planning, innovation, education, and infrastructure work.
InfoQ: Why do you focus on throughput rather than output?
Aerts: The idea of throughput is part of the Theory of Constraints of which the guiding principle is that a chain is only as strong as its weakest link. By focusing on throughput, we will reduce work-in-progress in each individual link, and thus optimize the result of the entire chain.
InfoQ: Custom Systems at TomTom decided to use only elements of SAFe. Can you explain why?
Aerts: Custom Systems is a project organization delivering Connected Navigation Systems to multiple customers, often with a very traditional "waterfall" approach to systems development, on multiple platforms, often developed in parallel to our software application. As a result we do projects with not only fixed Time and Quality, but also with a fixed Scope. And without a stable platform at least in the earlier sprints, it is difficult to define a useful Definition of Done knowing that test automation has also not (yet) been realized on the target platform under development. Also we do not require the SAFe portfolio level. So, we decided to adopt only a subset of the SAFe practices (i.e., everything at team level, a lot at program level), and where needed we modified the SAFe approach to fit our specific requirements.
InfoQ: What has the adoption of SAFe brought TomTom so far? What do you expect that the future will bring?
Aerts: The GO600, the first product of the latest generation of portable navigation devices, was introduced in 2013. Delivery took 140 days with the best quality ever. Since then we observe comparable improvements in other product development teams.
