Much of the conversation in social media around agile techniques seems to be based on the differences between the variety of choices of a method, a process, or a practice and definitions of terms for those choices. There seems little in the way of shared principles, when in fact, there is a great deal of sharing of principles.
I work in a domain where systems are engineered for the customer. These systems fall into the Software Intensive System of Systems (SISoS) category. In this domain innovation is the basis of success. The notion that innovation and engineering - software engineering - are somehow in conflict is common.
... creativity is simply the production of novel, approprioate ideas, from science, to the arts, to education, to business, to everyday life. The ideas must be movel - different from what's been done before - but they can't be simpmply bizarre; they must be appropriate to the problem or opportuntiy presented. Creativity is the first step in innovation, which is the successful implementaion of those novel, approproate ideas. And innovation, is absolutley vital for long-term corporate success - "Motivating creativity in organmizations: On doing whay you love and loving what you do," [2]
In many conversations about managing in the presence of uncertainty - which is the ubiquitous condition for all non-trivial software development projects - the notion that principles, processes, and practices of Engineered Systems appear to be the antithesis of Agile software development in some quarters.
Both agile advocates and engineered systems advocates practice innovation and creativity. Both fields are supported by a history of creating innovations - and in fact, collaborate on many of the programs I work. In the software engineering domain, like the developer domain, design is the basis of innovation. Design from a generalized perspective is purposeful ...
... thinking, problem-solving, drawing, talking, consulting and responding to a range of practical and aesthetic constraints to create - ideally - the most appropriate solution(s) under the given circumstances. - [3]
So why is there a great divide between the traditional engineered software-intensive system of systems and the current agile development paradigm that appears to reject the basic principles of developing value-based products from capital investments, using the core principles of managerial finance and microeconomics of decision making in the presence of uncertainty rejected by many in the agile development community?
Why does the engineered system paradigm reject many of the practices of the agile community as undisciplined, ad hoc with little or no basis in the principles of management?
Let's start with five core organizational principles of agile...
- Regular delivery of incremental business value - defined in a Product Roadmap, scheduled in a Cadence or Capability release plan.
- Iterative development focused on the delivery of Features that enable the needed Capabilities that fulfill the business case or accomplish the mission of the software system.
- Responding to changing requirements and priorities to assure continuous release of products needed to enable the needed Capabilities to be fulfilled.
- Engaging in multiple levels of planning with detailed planning occurring at the Sprint level to produce working software for needed Capabilities produced as planned in the Product Roadmap.
- Open and regular collaboration across teams and stakeholder to assure a shared vision of the desired project outcome.
The engineered SISoS domain has the same paradigm in principle because these principles and five implementation principles are Immutable. The five implementation principles are...
- What does done look like described in units of measure meaningful to the decision makers?
- What is the plan to reach done for the cost and delivery date to produce the needed value to those paying for the work?
- What resources are needed to provide the needed capabilities to fulfill the business case or accomplish the mission?
- What impediments will be encountered along the way to Done and what handling activities will be applied to remove or reduce these impediments?
- How will progress to plan be measured so the decision makers will have confidence their investment will be returned as planned?
So what's the disconnect we hear between Agile and Traditional systems development?
The first is the principles listed above are not established first before idea exchange starts. So when there is a gap in the semantics of a conversation, there is no touchstone to go back to. Without this shared understanding of the principles, the conversation becomes self-centered (an echo chamber) and any possible exchange in pursuit of learning is lost.
Second is there is no shared domain as the basis for applying those principles. I work in the SW Intensive System of Systems world. Others work in website development, others work in internal IT shops. While the principles of developing software for money are likely to be the same, the processes and practices can be dramatically different. What is a good practice for our spaceflight avionics system development, is probably of little use to a web developer. And vice versa.
Until we come to agree that the principles are a starting point, and then put a shared domain on top of those, it will be an argument without end.
Same Same but Different
† "Same Same but Different" is a phrase used a lot in Thailand, especially in an attempts to sell something but can mean just about anything depending on what the user is trying to achieve.
[1] Same Same but Different Perspectives on Creativity Workshops by Design and Business," Alexander Brem and Henrik Spoedt, IEEE Engineering Management Review, Vol. 4, No. 1, First Quarter, March 2017, pp. 27-31
[2] "Motivating Creativity in Organizations: On Doing what you Love and Loving What You Do," T. M. Amabile, California Management Review, 40, pp. 39-58, 1997.
[3] The Design History Reader, Grace Lees-Maffei (Editor), Rebecca Houze (Editor), Bloomsbury Academic, April 15, 2010.