Good. Let us get started. Two questions are to be answered first:

1. What is a product?
2. What is a viable product?

First things first: What is a product?

For me a product is something that one person creates and some other person uses. It could be something physical that you can touch. It could be something immaterial, such as a service. An idea that I have and somebody else uses, does not count as a product. There are strange situations possible, where one person creates something and nobody is actually using it. O.K. there was an intended user. So more complete would be “something the somebody creates for the intended use by somebody else. That should be good enough. There is no need to be mathematically correct and complete in the definition. The definition is simple and very close to what is found in wikipedia.

The second point is about a “viable product”. What makes a product a viable product? In the biological sense, something viable is able to live and to develop. This is the definition I am going to use. That means, the product needs to have a lifecycle. It needs to be able to develop, change its features and adapt to changes in the environment. It needs to respond to different needs. Worst case, it will perish in case it cannot adapt enough to the changing market requirements. The definition of the death of a product then is related to its use. In case the product is still there, but nobody is actually using it, it needs to be considered “dead”. The mere existence of a product does not make it alive.

Based on these considerations, we have some boundary conditions for our products:

• products are never static. Products adapt to the changing needs of the user or stake holder.
• they fulfill at least a subset of desires expressed by the user. They fulfill at least one job that needs to be delivered by the user or that pleases the user.
• maybe more…

This is an abstract definition of the entity product, however it excludes built-to-order deliverables. Built-to-order jobs in some cases are built on top of a product platform or are just simple configurations of a platform. The trivial example is computer hardware that is “built-to-order”, where you can select RAM size and mass storage space, and maybe the color of the housing. This is “built-to-order” in many cases just to reduce the amount of material in the storage. There might be a yacht that you order, that is built according to your specifications or large truck. Both products are products in a sense that They are built on top of a certain platform, but very customer specific. In case of the yacht, we may enter a pretty unique job at the higher end of the price range.

In most cases, things developed based on a specific order are built on top of something that had been pre-developed and are then adapted. The adaptations may be larger or smaller. that does not matter in principle. The delivered units however do not have a lifecycle. They do not have versions after they went into production. They will not be phased out and replaced with a new version.

Now it should be clear what we discuss when we talk about a “product”. If what you are doing, falls into the category of “built-to-order” items – no matter how big your item is – many things what we are discussing will not directly address your topic, but: Aspects of nearly everything we discuss can be of good use to you, so please stay with us. In an extreme case, your product might be a harbor. It will be built to order. It will be very unique, but it has a lifecycle. You very likely will not build it once and then forget it. It will be extended (hopefully for the owner), maintained, adapted, changed, modified, re-purposed, … . It for sure has a lifecycle like this. In consequence many of the practices and treats I am introducing here will be perfectly useable.

”Stop scaling agility” is the title of this post. Why should I use agility and by the way, what is “agility” at all? And why should I scale it?

Definition of terms continued: “agility”. Many people have tried to define it. There is no definition for a good reason. I believe the best thing is: Follow the agile manifesto. If you do that, then the next topic is also solved. Then there is no need for “scaling agility”. That then makes no sense. Logically. You may need to scale scrum for example. That is correct, but scrum is just a single method. Before now hell breaks loose, check the web page on the agile manifesto and read about the history. There are just principles, no recipes. There is nothing that needs scaling. Period.

Agile methods now mainly reflect on the “New New Product Development Game” article by Takeuchi and Nonaka. No discussion, there the teams need to be small, just like scrum teams for example. To build a large product in reasonable time, you need to have a large team. Here the work of Melvin Conway kicks in. –> with little interaction between the constituents of the system, you can develop a team setup that consists of units with little interaction. Scaling topic solved.

Scaling agility is a big topic and big business nowadays. Agility in its original form is used in teams to collaborate. One of the key elements is communication. Thus in consequence, the team size is limited. To the lower end at doubt three to four individuals. At this size or in even smaller teams communication and alignment is automatically build in. For larger teams, the upper limit may be discussed but lies somewhere between ten and 20 team members. If we want to organize work, delivered by coordinated actions of more people, we embark on so-called agile scaling concepts. These concepts come with more or less formal overhead.

There are commercial and non-commercial solutions available. All have one thing in common: they are more or less complex and involve coordination of different activities. Discussing complexity with system engineers shows that there are elaborated methods to manage complexity. No matter what, all of these methods slow down the value generation. In consequence complexity kills innovation and productivity. The most natural reaction then is to reduce complexity and make things simple: Always strive for simplicity to be fast. Complexity is killing speed.

This does not imply to the keep the problem we are tackling simple. Problems we are solving may be very complex. The solutions however need to be simple for the teams to develop them with high quality and little distraction.

How can we develop something complex and keep it simple for the teams? The answer is in the product, not in the way we orchestrate the project execution.

Focus on

• Architecture
• Loose coupling
• API first principles
• Data orientation

These are the big topics I will be addressing. In this order.

As Hors’d Oeuvre let me focus on the obvious thing: Do we always need agile methods (if you now come with “agile is a mindset, not a method”, please read here.)? My clear answer to that is: NO. And this is the most agile answer you can give. Do what ever gives the best results in the given context to satisfies the customer (and yourself).

The post Stop Scaling Agile appeared first on Grado.

The inverse Conway maneuver

The inverse Conway manoeuvre uses this observation to suggest organizational structures.

“Technology change is driving changing customer preferences and behavior, which in turn are driving organizational change across increasingly software-driven enterprises. The causality question behind Conway’s Law, therefore, is less about how changing software organizations can lead to better software, but rather how companies can best leverage changing technology in order to transform their organizations,”

Bloomberg.

“organizations which radically change their system design should expect changes in communication structure”

Roy van Rijn

The post Conway’s Law appeared first on Grado.

“While we must acknowledge emergence in design and system development, a little planning can avoid much waste.”

The architecture of a system must support the ability to provide frequent, independent releases to meet business objectives. In addition, the architecture must be easily adaptable to strategy changes. This is achieved by evolutionary design and a combination of both intentional and emergent architecture. Architects will spend less time defining ‘intentional’, big-upfront architecture and more time with constantly assessing incoming use cases to evaluate their potential impact on the current design.

Safety Advice
As with many analogies that are being applied to the digital world the Architecture analogy is one that is being misused the most. A construction architect would work mostly on the usage and the appearance of the building. So in comparison this would be a UX Engineer. What we mean with Software Architecture are Construction Engineers. A Software architecture has by its nature a dynamic construction that needs constant refinement. Thus the major focus is to identify the parts that are becoming to stiff and brittle over time. Software Architects should thus act more like Gardeners than Construction Engineers.

Related

• Portfolio strategy

Recommended Resources

1. “Agile Architecture” – Molly Dishman & Martin Fowler Keynote
2. How enterprise agility will redefine architecture by Jeremy Drumm

The post Enabling architecture appeared first on Grado.

“The glue that holds all relationships together–including the relationship between the leader and the led–is trust, and trust is based on integrity.”

Trust in the workplace has a big impact on how employees work together and how organization-wide learning takes place.

Feedback serves as a catalyst for learning, about yourself, about customer needs and about our ways of working. But this can only be nurtured through a permissive environment where people feel safe to open up.

Safety Advice
Employees trust their peers more than their senior managers and executives. The higher you are in the hierarchy, the more critical and difficult it is for you to build trust with those you supervise. As a leader you cultivate trust by providing clear direction, giving people what they need to follow through, and then getting out of their way. And don’t forget – trust is something that is given to you.

Related

• Shared principles and values
• Participation and communication

Recommended Resources

1. Tales of Creativity and Play

The post Environment of trust and learning appeared first on Grado.

“The real battle is not competitors. This is rubbish, very abstract. When do we meet competitors to fight them? The real battle is against ourselves, against our bureaucracy, our complicatedness – only you fight it.”

The behavioral capabilities of an adaptive organization needs to be underpinned by appropriate organizational structures, boundaries and processes. If people and structures are not aligned, the result would be an unconstructive culture. Clear roles and responsibilities reduce redundant work, accelerate decision-making, and promote ownership. Process discipline ensures focus, reduces coordination efforts, and improves information flow for decision-making.

Safety Advice
Structure doesn’t only allow an organization to run smoothly; it also helps prescribe how and organization runs. In fact, organizational structure can help dictate culture, values, and success.
Command-and control-structures worked well in the industrial age. The age of information economy requires structures which facilitate the flow of information, and, thus, maximizing efficiency through keeping the employees engaged and enabled to think, communicate, and work at their best.
Leaders must be willing must to critically assess whether their company’s structure aligns with its values and goals. This form of big-picture internal assessment often goes overlooked.

Related

• Identity
• People and culture

Recommended Resources

The post Structures, processes and workflows appeared first on Grado.

“Whenever there is a product for the customer, there is a value stream. The challenge lies in seeing it.

In Flow-oriented organization design we learn how to setup the company from an outside-in perspective around the ultimate goal to create value for customers.

Most organizations are structured vertically, yet adaptive organizations require more horizontal and process-oriented structures. We have to identify value from the customer standpoint, organize around value streams to fulfil that value, establish flow and implement pull. That involves bringing together all required business and technical capabilities needed to define, implement, verify, deploy, release and maintain solutions for customers.

Safety Advice

Most travelers still think that division of work by functional specialization will remain the right approach to scale product development in the future. Unfortunately, that only provides competitive advantage when efficiency by synergies are the goal but not when speed and adaptability are of primary concern. Misjudging your current situation and context can lead to dramatic suboptimization and complete failure.

Related

• Structures, processes and workflows
• Enabling architecture
• Situational Awareness

Recommended Resources

1. Flight Level Model for designing value stream oriented organizations and for achieving Business Agility

The post Flow oriented organization design appeared first on Grado.

Every company has two organizational structures: The formal one is written on the charts; the other is the everyday relationship of the men and women in the organization.

Structure is essential to the functioning of any organization. It is anything that creates boundaries and rules to orchestrate people and activities. Structure includes organization structures, policies, governance practices, and reporting relationships for people to align toward a common purpose.

An adaptive organization needs the capability to smoothly adapt its structures in response to changes in its business environment.

Safety Advice
The design of the organization defines the outcomes or as W. Edwards Deming put it, “Every system is perfectly designed to get the results it gets.” You cannot expect different outcomes as long as the structure won’t support it.

Related

• Flow oriented organizational design
• Structures, processes, and workflows
• Environment of trust and learning
• Enabling architecture

Recommended Resources

1. Structural Agility by Jardena London

The post Enabling Structures appeared first on Grado.