While SCRUM is the de facto state of the art solution for agile product development in software, it has a number of direct limitations that TAF Agile Framework addresses. These can be classified into two categories: handling innovation and mechatronics.
SCRUM is a framework that assumes a product owner who can answer any question on what to build. The product owner can define user requirements in the form of user stories that then only need to be split and refined by the team into actual tasks to be executed. This prior assumption is invalid for innovations. There is no product owner with complete knowledge but rather a team with a vision and a corresponding problem-solution idea. Further, SCRUM has no in-built method to react on any change on the business environment (desirability & viability) – instead it assumes that these changes are facilitated by the product owner who then prioritizes features in the backlog differently. As such, SCRUM provides guidance for efficient management of projects in a way that allows for high flexibility and adaptability. Nevertheless, SCRUM is mainly geared at pure development teams.
In contrast, TAF starts with a holistic view on the product from the beginning, encompassing business and engineering of a product. This holistic view allows to handle the limited knowledge on what to build and to react swiftly to changing environments, be it on the business or engineering side. Thus there is no requirement for a product owner role, as it is assumed by the framework and the interaction of the team with potential customers and users.
SCRUM lives off the assumption that there is an increment after every sprint that can be shipped to and evaluated with the customers and users. However, the nature of physical products prohibits this cycle. Once a physical product is shipped, making modifications to it is costly or even impossible except for the soft- or firmware part of it. Thus for a product to be mass-produced there is a start of production (SOP) date after which typically no changes are made to its hardware. It is thus in the nature of product development models such as VDI2221 to find and eradicate any errors through extensive specification, design and evaluation phases before signing off a product for SOP.
However, where these methods are too rigid, requiring detailed specifications upfront and thus cannot accommodate for changes in the market and technology landscape, SCRUM is too loose as there is no specification until the refinement takes place.
TAF addresses this by iteratively refining technical specifications and applying traditional product development methods as part of its process. Incremental development and rapid prototyping for example gives many opportunities for students to reflect and improve. This is based on the assumption that early guesstimates are better than not assessing complexity of parts at all.
While Design Thinking helps defining a product-solution-fit, it doesn’t help building the product. Rather it leaves the development process as a downstream activity. In contrast, TAF acknowledges that a product cannot just fail because it doesn’t address a customer need, but also because it is not feasible to develop or viable enough to create a business around it.