If we are doing something for our user, (who now secretly turned into a customer, because the user now does not actively use our work product) we need to focus on the workflow for the activity. This workflow is actually the value stream. There is a number of methods or recipes out there that tell and educate you on how find the value stream. Just find it yourself. When you are done you will have a structure like this:

Value stream for a hypothetical activity executed for our customer

There are three “swim lanes” associated with with three different teams or competences or manufacturing stations, and the work is being passed through the different entities and teams until it gets finished. There are parallel activities, there are dependencies. Each box describes a discrete activity that has a start and an end, receives some specific input and delivers a specific output. This work breakdown is like an architecture of the workflow. The building blocks are specific activities. Time by the way is running from left to right. There might be some improvement potential, but at least the work is structured and well prepared for improvement measures. I will not discuss them here. They are in the expertise of lean management or lean manufacturing.

For me it is enough that we see clear input and output and clear interfaces. The work can be modularized and measured and improved in the sense of scientific management – if the management knows how to do the steps in the boxes or we can use the ideas from the Toyota Manufacturing System to have the value generators improve the process. (The only place where value is generated is a the shop floor. Everybody else is doing work classified as “non value-add necessary”. In best case. All other cases qualify as “waste”.) In a way, this is also classical scientific management by F.W. Taylor.

In the case of a physical or logical product, i.e. some output the customer wants to use him or herself to generate value no his/her own, we have a similar concept: the boundary diagram.

A boundary diagram for a system. Boxes denote an internal structure called subsystems. There are well defined inputs and outputs for the system and its subsystem.

There probably are a number of definitions for boundary diagrams. A very simple one is that we structure the system in such a way that all sub-units are independent and communicate with the environment though interfaces with defined

• material transfer
• information transfer
• energy transfer
• mechanical contact.

(Yes, information transfer is the same as energy transfer in a Physics world, but in engineering it is smart to separate both, even when it is not correct at all.)

If you follow me down this rabbit hole (see “Alice’s Adventures in Wonderland” by Lewis Caroll), we can realize that all products and services can be implemented in independent boxes with defined interfaces. Pretty spooky thing, right?

Now it is time to learn from some big guys. I can describe everything in units with interfaces. Sounds like service based solutions. Yes. This would be service based and each box represents a service. If I now freeze the interfaces, all these services now become independent. Correct? In consequence, all the insides of the boxes can be hidden behind a magic curtain. You might want to check out the famous example of the Mechanical Turk. From the outside you cannot detect if there is a machine or a person. (Yes, you can remember the Turing test now ). Same story: as long as I do not tell you what is in side the box, I can do what I want and you will not be unhappy as long as I am delivering according to what I promised. In our speak: I deliver according to my output specification.

If you are at that point, you may want to check the ideas of Simon Wardley on Wardley mapping. (Simon, I know I am oversimplifying, but this is the way my brain works. Sorry.) The Amazon way of monetizing services is also an option. I believe this is how Amazon Web Services were started.

Back to our architecture. Perfect situation: I am free to do whatever I like if and when I keep my promise. I can optimize my work. I can use the tools I want, I can use the methods I want, etc. Which tools and methods do I want? Typically the ones that make my life as easy as possible. Nature always takes the path of least resistance. No, that is a lie. Nature takes the path of least action, which is the physicist way of saying: “The path of the least effort.” We can describe nature pretty well, when we assume it to be lazy. Now tell me Physics is not fun. After sneaking in some Richard Feynman wisdom, let us have a look at the ideas of Application Programming Interface first (API-first) as a useful concept.

The Steve Yegge’s “Google Platforms Rant” CSE 452: Google’s Introduction to Distributed System Design

“[…]

His Big Mandate went something along these lines:

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols – doesn’t matter. Bezos doesn’t care.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!

[…]”

This is what Steve Yegge claims has been mandated by Jeff Bezos for Amazon. Quite some time ago.

In the light of what we just looked at before, these are some simple rules to follow in order to generate something very modular, adaptable and externizable, i.e. if you find the function somewhere a bit cheaper and it is not of strategic value for you, buy it, don’t make it. If you can sell the function as a service: sell it. Maybe you have heard of Amazon Web Services before. Something they sold to the outside world. This is the meaning of “externizable”. If you can sell it, sell it as a package. The same thing in reverse: If you can sell it as a package, you can easily also buy it from somebody else and weave it into your solution.

Wait a second though. Steve Yegge writes that Jeff Bezos wrote about teams, while I talked about functions and subsystems. You can match sub-system structure with team structure. Mathematically this is an isomorphism. In the original paper, Melvin Conway promoted a homomorphism between team structure and product/service architecture. He did not talk about service architecture, but see above. Difference between isomorphism and homomorphism? Something is isomorphic if the structure is exactly the same. If two subsystems or two functions are very small and it for some reason makes sense to keep them separate, you can ask one team to work on both. Voilà: the isomorphism becomes a homomorphism. Very simple. One team does one sub-system. If the sub-system is too large, make it smaller, BUT fix the interfaces.

The screw can be turned one more notch: Haier, the appliance maker, or rather its CEO Zhang Ruimin has taken an extreme approach to generate sub-system solutions: Micro-enterprises. The internal contracting as principle for coordination can be seen as a (very abstract) API. Simply an API between companies. In the bottom of the article, you will find the statement that complex systems cannot be engineered top down, but that they need to emerge bottom up. We will come to this point in the next chapter.

On the practical side: How should I know in the beginning which structure is the right one? Building teams takes a bit of time and in the end we are dealing with people. We do not want to move people around the organization with a high frequency. Simple solution: Separate the flow organization from the hierarchical organization. In the areas of high uncertainty, it make sense to separate line responsibilities from content responsibilities. If you do that, you can borrow the idea of “Tiger Teams”. Keep the team structure malleable until the solution becomes clear. Then harden the structure to give security to people. Still hierarchical leadership does not need to coincide with technical leadership. It can however. Understanding this concept explains the success of a number of startup compared to teams from corporations. In the startup, you focus on the product and the hierarchy follows. Like the Bauhaus Form follows Function concept. Keep even your hierarchy product centric. Corporations often react differently to challenges.

• Separate line organization from technical organization, i.e. line leadership is different from technical leadership. This causes conflicts between leaders, but this is not presenting a problem, since leadership is “non-value add necessary” at best and the developer produce the value in the organization. The conflict is not where value is generated.
• Match the technical organization to the product architecture. That allows the right people to be in close vicinity (not necessarily in physical proximity, but in terms of functionality.
• Understand that the architects in your organization are in a leadership role. Choose and and educate them wisely. Listen to them and provide them with the necessary power. A seasoned developer may not necessarily be the best architect. Make him or her a senior or “executive” developer. A more junior developer may in fact be a better architect. Architecting things and developing things are two different trades. Sometimes.
• Architecture is more than the documentation of your product. It is defining the products future and modularity and feature roadmap. As a Danish proverb says: “Predictions are very difficult. Especially about the future”, the task is difficult. One solution thus is to keep the architecture as adaptive as possible.

So far so good. As takeaway for now, we have:

1. Understand the product/service.
2. Decide if you need a modular and adaptive architecture or you are better off with a monolithic solution.
3. If you want a modular and adaptive product/service, structure your product or service with focus on modularity.
4. Define and document the architecture. Make sure the architecture welcomes adaptations.

And two more things.

• There is intentional architecture and emergent design. Both work hand in hand.
• A monolithic solution has its benefits, just as modular solutions have their benefits. As always: It depends on the context. The lead architect needs to make a decision. The decision may be right or wrong, but a decision is needed.

Intentional and Emergent Design

Architecture plays at different levels. Above we discussed abstract boxes of functionalities in value streams and boundary diagrams. How boxes are connected at the level of interest is the realm of intentional architecture. An architect understands the functionality of the product or the execution of the workflow and structures the topic. This is what we understand as “intentional architecture“. What happens within the box is in the authority of the team, developing the functionality. On this level, one level lower than the “intended” architecture, we also have an intended architecture. Just one inside the functionality. When we now add feedback or “correction loops” into the system, i.e. we allow the architects and developer from inside the boxes to communicate with the architects defining the system architecture, new ideas and solutions may appear. If they do, new solutions ideas may manifest. This is the realm of emergent design. Emergence means that the system has properties that could not be foreseen in the properties of its constituents. Emergent design results from iterative delivery of constituents of the system we are working to deliver. (See also the HBR article on Haier.) There is no such thing as emergent architecture. In order to control the design of things, architecture needs to be intentional. If architecture just “happens” it may be seen as emergent, but in fact it is just reverse engineering of a solution and trying to justify decisions taken on the fly. Emergent design is a very useful consequence of iterative development. Architecture may change and evolve as the solution develops. There is no contradiction: if architecture is sketched/documented/drawn as the solution is developed, the solution structure is validated with an architectural description. Trust me: you will find flaws right away. It is similar to the statement “If you can’t explain it to a six-year old, you don’t understand it yourself.” (Probably by Einstein.) If your design is not simple, it will not be easy to modify and to extend in the sense of iterative development. Thus, you will automatically kill it after a few weeks latest. Simply BECAUSE you cannot extend the functionality in the sense of iterative development. But, you will only kill it if I insist on interactive development and frequent demos. This is where puzzle pieces fall together and generate a solution. Remember this thing with with agility? Always demo the product. This is the very reason why. If you can demo every week or every other week, you HAVE a modular architecture that welcomes changes. If you can’t demo frequently, I have an idea why… BTW: you can plan a modular architecture. Agility is not a must. It just points you to an adaptive solution.

After discussion architecture in general, let us have a look at possible solutions for easy and cheap adaptability: The API-first approach.

The post Architecture Considerations. More Important Than You Might Think. appeared first on Grado.

A-SPICE has nothing to do with spices. It is the acronym for Automotive  Software Process Improvement and Capability dEtermination. It receives some bad press recently and is often called guilty to slow development down. The thing is: it is not a process. It is not intrinsically bad. It just depends on the context and what you make out of it. No bashing of anything in this article. Here ideas in forward direction. You can replace “automotive” with any industry you like. I am 100% certain the concept is transferable.

My personal view:

Automotive processes do not need to be slow and overloaded. It depends on how you build them. Facts:

• Nobody ever said, automotive processes need to contain tools. Tools need to support what you are doing. Tools support methods. Nothing else is relevant.
• There is a natural food chain. Processes <– methods <– tools. Processes are supported by methods. Methods are supported by tools.
• Processes need to describe the outcome of the development process. Period.
• Nobody ever said, automotive processes need to contain methods. Methods describe ways to execute tasks that lead to outcome.
• Note: Output is not evil in itself. Sometimes outputs make sense for the execution of your method of choice. Metering output however is not a measure of success in general. In cases like Tayloristic workflows, it is, but it is not a global truth.

In consequence:

1. Separate the process from the methods that are used to deliver the process outcome. The process defines the succession of outcomes. Methods help us to generate the outcome.
2. Multiple different methods thus can lead to one process outcome. No more discussion of an “agile process” or “classical process”. The process can be the SAME, as the process defines outcomes, not outputs.
3. The process points to potentially different methods, leading to the same result. The process is method-agnostic.
4. The method now can be of “classical” or “agile” character. It actually does not matter at all.
5. Each of the different methods employed, uses tools to support the methods. Alternative tools are possible. The methods need to be tool-agnostic.
6. It is possible that two teams use different tools to deliver similar outcomes in the same process.

Yes, this is describing a tree. The process-method-tools landscape does not really need to be a simple graph, as one tool could support two different methods, but you get the picture. I do not want to overcomplicate things.

Therefore, if a tool is exchanged, the process does not need to change. Why should it? I can describe the process through the outcomes constructing the process. The output belongs to the method. i.e. it is method-internal. The same applies to the methods themselves. Why should the process change when I am using a new method to generate the same outcome? Makes no sense.

Think API-first in the context of the process.

You are thinking I am nuts? Maybe yes, but trust me, a process landscape like this is possible.

Use a general rule: No process step shall be more than three sentences long. English sentences, not German ones. It needs to be simple to read and understand. That is enough. Short and concise descriptors are the source of the API strategy. If I get tired reading the process, is it digestible for the developer? I do not think so. Put a bit of design thinking into the process development. Who exactly is the user of the process? What is the target? What does the user need right now? … Keep it simple and modular.

More points:

• Method descriptions shall be method descriptions and typically contain trainings or link to trainings. Sorry, if your developers do not know how to generate a process outcome, train them or better, give them access to training so they can learn what they need. It is not the job of the process to deliver knowledge and skill. Educating people is what line management (which also in agile setup exists, even if it is realized via self-managed teams) needs to do.
• Methods are supported by tools.
• You can model your process in a tool. Fine. It shall then lead the developer and project manager or product owner through the steps of the process. Understand that the process shall support product quality. It is not a flow chart for the activities to be executed by the developer or any other project member. The flow chart of the activities is call “method”. See above: not part of the process.
• Another word on tooling: The lifetime of a tool typically is short. Exchanging a tool is a big pain, unless your tool supports a standard interface. If there is a standard interface, I can exchange the tools. Anything else is a vendor lock-in strategy. “No problem, I will adapt my tool to your process.” I have my opinion on that. You might want to look at Data Centric structures.

If you let all of this marinade a bit, you will discover how to iteratively develop and improve a process including associated methods and supportive tooling.

A-SPICE is not evil. It is simply not always used in a smart way.

The post A-SPICE: Inherent Vice? appeared first on Grado.

Let us assume the main challenge were to deliver products with high quality, (defect free, lifetime of the product matching the expectations of the customer, always being close the state of the art, never outdated, …) with short turn around time, while requirements or actually feature lists a frequently updated.

These targets are probably agreeable by many people.

Taylorism is bad and agility is good. Or not? Is this the contrasting pair? Maybe yes, maybe no. It does not matter. Let us have a look at the rules of the game.

Taylorism

The basic rules in Taylorism are that the boss knows best and success can be measured precisely. In the last couple of years, Taylorism is widely regarded as out-of-time. As everything, it needs to be seen in its context. The challenge was to produce goods with relatively unskilled workers that work for money, not for purpose. This is the environment that was present at the time. Read Taylor in the original version to get some exposure. The writing style is just the style of the time, so have patience. What Taylor basically did was to take the division of labor in to small units as proposed by Charles Babbage and add a cost function to the equation. The division of labor simply meant that not all work in a production process requires the same skill level. Less skilled worker could take over the less skilled parts while more skilled worker would have execute the more complicated tasks. Equating in the salaries of the workers, you can see an optimization strategy.

Cost = time (worker_1)*hourly_cost(worker_1) + time (worker_2)*hourly_cost(worker_2) + … + time (worker_n)*hourly_cost(worker_n) + overhead costs

There is some overhead to be computed in for the handover and storage and maybe some inefficiency and whatever. Then you can optimize operations. You need to understand EXACTLY what you are doing, then you can optimize HOW you are doing it. This necessary precise knowledge coined the term “scientific management” as Taylor called it. If you are in a situation, where you can understand your processes well enough, you can use this method. Lean manufacturing is maybe the gold standard for scientific management. In lean, there are the overhead costs that need to be looked at carefully. Zero line breaks, no rework for electronics, target of single piece flow, … At first lean manufacturing does not appear to lead to cheaper production at impressive quality standards, but it is the holistic treatment of the entire value generation that does the magic. Single components are simply not enough and the introduction of a single action may destroy the entire party.

Now you can connect Taylor to Lean Manufacturing and Machine Learning. All the same thing: the cost function. Henry Ford added something more into it: you may want to not only include the wages of your workers in, but also the training and education costs. He widened the field of view if you like. Total cost of employment needs to be considered. At some point he realized that it makes a lot of sense to pay enough salary to make your people stay. Money is not everything, but it at least it helps. Sometimes. Legend goes that Taylor and Ford never met or never collaborated. I don’t know. The world is small and who knows what exactly happened around 100 yrs ago?

I made the connection to Lean Manufacturing already. What is now the difference between Taichi Ohno’s manufacturing system and the Tayloristic system? The workers and their culture that is ASSÙMED by the two people. In both cases, the laborer are pretty much untrained. The difference is their assumed interest in the work they are asked to execute. Why “assumed”? Well, who knows what really motivates people and who can look into somebody elses mind? You have to make an assumption on you “average” worker and his or her “average” interest in the work they are asked to do. For sure the assumption is wrong, but we only need to be right on average. And not even that. Taylorism assumes little interest of the worker in the result, Ohno assumes people want to deliver the best result possible. Thus Taylor controls, Ohno involves. It is that simple. If you submit Taylor’s clientele to Ohno’s process you will run into quality issues. The other way around will lead to boredom and attrition. – In simple terms. As always: the context matters a lot.

In addition, there is an extra twist with Henry Ford: He played with the production system. At one point he envisioned the production line at Highland Park, where the work was brought (by gravity) to the worker. Starting with the raw material at the top of the building and having the finished Model-T’s driving out in the bottom. In the end he reduced the production time of a car from more than 12 hrs to about 90 mins. If you dig into the details, you will find that the improvement process itself was not straight forward and it took a couple of years to see this huge improvement in production time. In addition he fought attrition rate by increasing the hourly salary to more than twice the salary paid by his competitors and lowered the working hours. Overall this improved quality and costs.

Anyhow, we now understand where Taylorism excels: In the well known environment. Only if I understand the cost function, I can optimize the system. If my understanding of the cost function is incomplete, there is no way I can find the optimum in terms of cost in a predictable manner. Intrinsically, the cost function can only be found iteratively. I make a proposal, use it and check I get the correct result. If not, I need to improve the cost function. The improved cost function then needs to be checked again. The old and nicely working PDCA cycle by Shewhart and Deming. In total, the scientific management method. That does not mean I can only start scientific management when I have 100% knowlege about my system. I can get started on incomplete information. If and when I go through the PDCA-cycle, my knowledge will automatically improve. Actually there is always something that can be improved, so you are never done with scientific management. Production is an environment, where scientific management excels. Clear data, clear cost functions, clear return on invest, short cycles, clear measured cost for inputs consumend and clear measured numbers for outputs generated are our parameter used for optimization. We do not need to be too picky. A few approximations here and there are acceptable.

As a consequence we now understand that accounting is key to generate the correct cost function. For production typically, the costs are more easily found and attributed to the correct production step. In development, the costs sometimes are not so well documented, i.e. the total costs are typically correct, but the documentation with respect to the individual steps sometimes has improvement potential. In this respect, Taylor, Ford, and Ohno follow a similar concept. Taylor apparently focused on manufacturing alone. Ford considered training and re-training of his workforce and non-conformance costs. Ohno tried to optimize the time needed to fulfill the order from the end customer. The time from the point the order was signed until the money was in the bank. In a similar way, Lean Manufacturing optimizes the money spent for the entire production process, leading to the reduction of stocks on input and output side.

The advantage of the Tayloristic approach and everything that may be inspired by it, is that it is a controlled, predictable process for repetitive activities. There is not much variance allowed within the process. In the Toyota Production System, just as in lean production and management, the worker are encouraged to propose and implement improvements. These process improvements from bottom up direction will optimize all production steps. Therefore workers are heard and will contribute to the improvement of the production steps. Not so much into the improvement of the product. It is often said that Tayloristic management limits the engagement of the worker in the process and reduced their identification with the product.

Henry Ford is not F. W. Taylor and both are not Taichi Ohno, nor W. Edwards Deming. Each of them propose valid, useful, and superb methods. All of them were developing for their specific context. Understand the context, know your context and choose the elements that make sense for your situation. One more thing: There is no best practice. There are only good practices and good ideas.

Agile Approaches

The basic rule in agile approaches is to understand that we are in a situation, where the well known Tayloristic approach does not work. We may know what to achieve, but cannot write a detailed plan. We need to question the paradigms to see what to do differently. Sometime it is just that we cannot optimize because we do not have a precise cost function. What is the added value of base development? The value generated by development can be calculated after we sold the last product. Nice, but too late. Return on invest is not a smart indicator to optimize the development. I cannot use this number to optimize the development process. What is the value of a line of code a developer wrote? Sometimes a smart idea reduces the number of lines of code and is very valuable. How does this enter the equation? If I am traveling in a well developed environment with roads and highways and maps and navigation systems, it is easy to measure the progress I am going to make towards a target destination. When we are traveling in the wild, maybe a jungle or a semi-desert and have no satellite data exploration of our route, it is very difficult to make a prediction. Well even with a lot of data available, predicting the arrival at a certain location is difficult. Here scientific management will fail. Iterative methods will flourish.

The first thing is that we need to know when following agile or iterative/adaptive principles is what we want to achieve in terms of customer experience. I we do not know the outcome as we think it should be experienced, we shall stop all activities. That is simple. If we know what to achieve, and know exactly what to do, stop thinking about agile and write a plan and execute the plan. Still it helps to communicate strategy, environment, plan, ideas, etc. If you cannot write a plan, do not know HOW to achieve your target, communicate strategy, environment, plan, ideas, etc. Listen to your team to get feedback and embark on the voyage. Respect your team and invite them to contribute with ideas and feedback. Together with the team, you need to develop a plan. We do not need to know exactly what to do. We simply ask “Who might have an idea?” This is the motto of the game.

As a consequence, we need to acknowledge that as a manager of such an undertaking, nobody can tell the developer/worker WHAT to DO. We need skilled and knowledgable people that if and when we tell them what to achieve will find a way to reach the objective. We are changing the role of the manager into the role of a leader that gives guidance. Guidance on what to achieve. In case we have the “right” people on the team, our job is to develop the team to keep the work efficient. We need to refrain from telling people what to do and need to develop trust into what they are doing. This is not a laissez-faire approach to leadership. As leader we still are responsible for the outcome of the activity. In the setup in the Tayloristic approach, the manager checks the fulfillment of the individual activities and needs to see the progress report in terms of activities executed. If all the activities are executed, success is guaranteed. In the agile approach the execution of the tasks anticipated is not a guarantee for success. Trust is generated by the delivery of outcomes, i.e. intermediate results leading the greater target. Team and leader agree on intermediate outcomes. These outcomes are tracked. Due to the large uncertainty in such a project, if an intermediate objective is not met, the team shall not be blamed automatically. What is to be done is to investigate the situation and act accordingly.

Working in the agile mode generates more overhead on the planing and alignment side of the undertaking. Instead of one person absorbed in planning activities, we have the entire team involved. In addition, we need alignment in the team. Depending on the challenge to be solved, one or the other method is the right choice. It might also be smart to run the activity in some hybrid mode, where some functionality is developed in a Tayloristic framework, while the rest is done in an agile setup.

And never trust your consultants too much. I used the picture of the voyage in the wild. Remember Henry Morton Stanley with the quote “Mr. Livingston, I suppose?”. The story is cool, but do you really believe you travel to Africa in 1871 to search a single man and actually find him just like that? The story told is a bit over the top, but entertaining. Agile works, Taylor works, but both need to be taken with some grains of salt.

Let us Compare

Back to serious content. The context drives the choice of the methodology, nothing else. These are aspects of the two different approaches. Depending on context, each of these aspects may be regarded as positive or negative. It just depends on what I need now.

Tayloristic approaches and agile approaches in consequence are solution paths to two different challenges. How to find out which is the right choice for the current challenge? Very simple: If you inspect the challenge and are asking yourself “What do we need to do now?” With high probability, the Tayloristic approach is likely good. If you are asking yourself “Who might have an idea?” Then the agile solution is likely the better choice. Maybe the person you are asking has a clear idea already, so you could get an easy fix. However, it is better not to randomly trust people because you like their assessment. “In God we trust, all others bring data.” is attributed to W. Edwards Deming. Do not get the impression that Deming and Taylor were proposing similar management techniques. Remember, they differ dramatically based on the role and a competency assumption for the workers in the line. Also here the context is essential. Tayloistic Style is made for workers that do not identify with product quality. Deming and Ohno are focusing on the situation, where worker identify with the product and product quality. The best thing is to understand method and context and not to copy anything, but take what makes sense in your context. Adapt. It is hard to imagine in current times that we still find value creators that are not interested in the quality of their output. If there are some in your context – the proven method is clear. If you have engaged value creators, some aspects of scientific management still make a lot of sense.

A more formal and very interesting discussion is found in the works by Gerhard Wohland (unfortunately not translated to English language – yet).

Gerhard, please do not be upset. I know your concept has many more details, what is reproduced here this is all I need right now. In addition, I think, the world is a little bit more complex. Instead of “dead” and “alive” I prefer “formal value creation” and “adaptive value creation”. Let us define terms first.

Formal value creation refers to classical Tayloristic value creation. The boss kows best, defines the processes and orders the worker/developer what to do. The structure is going to deliver high value and quality if

• rules are defined and followed.
• methods are developed and trained.
• clear processes are defined and followed.
• the organization is steered based on data.
• we define a plan and follow the plan.
• we have clear targets to be reached.

The condition for this to be successful is that we have a slowly evolving market situation. We have enough time to adapt to the changing environment and situation. We do respond to changes of the environment, i.e. we are in principle adaptive, but there is enough time to adapt the methods, processes and workflows to the changing outside world by the modification of the guidelines for the value creators.

In contrast, we will use adaptive value creation when we do not have the time to adapt the workflows and methods on management level. (Basically this refers to adaptations with a process release of every 6 months or less frequent.) In the case of the need for higher responsiveness, what we need to communicate and define to be successful is

• common principles and rules. Decision are made locally, but aligned via common principles.
• habits and values are developed and trained.
• the target outcomes are defined and guardrails are respected.
• the organization is lead based on information, i.e. correlated data.
• a tactic is followed, based on an agreed strategy. A plan exists and is adapted to new learning.
• An outcome as target is defined, but options to get there are respected.

In consequence, the formal value creation clearly has advantages when the change in the environment is slow enough that the leadership has time to analyze the situation, adapt the processes in the organization, and roll them out. When the market is changing faster than the organization can adapt, then the adaptive value creation has advantages. However, people need to behave differently in both types of value creation. Executives, leader, developer, and worker need to show different talents and skills. In the shop-floor environment, adaptive value creation is close to craftsmanship or even the Toyota Production System. Still differences sure exist, but the overall atmosphere is similar. In the adaptive value creation mode, the value creators need skill and knowledge to create the best workflow. In the realm of formal value creation, diligence is what brings us forward. Adaptive value creation is prototyped by agile ways of working, but not limited to agile practices.

What to Do …

In very simple terms:

• if management and the steering part of the organization has enough time to analyze new customer requests, and can respond, Taylor and the like are a very good choice. We can analyze the new features, break them down to requirements, define an architecture and simply write a plan and deliver. This is working with internal references like documents and specifications.
• in all the cases, where the is not enough time for the steering part of the organization to analyze new customer requests, we need to allow the value provider to take decisions and deliver independently. The central part of the organization then needs to issue rules and guidelines to steer the organization. Otherwise we will end up in a pretty disordered setting. You can envision this as working with an external reference since you will need to ask the customer if you are on the right path.

Here again, context rules. Working in adaptive mode without getting feedback is not going to lead to satisfied customers. The same way, following a clear plan and schedule and asking for a review will iterate the customer. You should be knowing what to do. Don’t ask.

O.K. so far? That just directly tells us that the good old Taylor with scientific management is still the a very good approach under the premise that we exactly know how to do the job we are asked to do. No research, no REAL development. With REAL development I am targeting challenges where in the beginning I do not know for sure how the solution will look like. There are development tasks, were I just need to adjust some parameter and I am done. In this case, yes I will generate something new, but the learning is very limited. In challenges, where I will be learning a lot and new knowledge is generated, the Taylor approach is not so effective. Whenever learning is involved, i.e. I have a plan, I am executing the plan and check the result, a.k.a. I am following the scientific method with the option to fail and actually generate new knowledge, the Tayloristic approach is not smart. Then agile or other adaptive methods are of advantage.

Reflecting these two aspects, it is clear that the adaptive approach on a higher level is always the best solution. If Taylor is the best choice, I will use Taylor. If agile is the best choice, I will use agile. In addition, we always can blend in some Toyota Kaizen: even in Tayloristic settings, the worker or developer have direct exposure to the work. They know how to improve the workflow. Kaizen is thus somewhat in the middle between Taylor and agile. Somewhat. It really does not matter much.

Thus, there never should be a discussion or dispute V-cycle or agile. If you really are agile, you will use the V-cycle or a real Tayloristic setup whenever it leads to faster and cheaper and more reliable results. When it is not faster or generates issues, you will use agile approaches.

To turn the screw one more time: Tayloristic approaches, Lean ideas, Toyota Production System, Agile mindset/methods are actually solutions to challenges. They all have their right of existence – that is granted anyways – and they all have their environment, where they flourish. At this point we need to look at reference points. This is something from the old greek philosophy: Without a reference point you do nothing. Archimedes a bit far fetched.

After we stopped this useless discussion through the understanding when to do what, we shall go to something important: architecture of things.

The post Agile or Not? appeared first on Grado.

The post Resource Fluidity vs. Resource Balancing appeared first on Grado.

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.

In a second it struck me that there is something dreadfully wrong in this statement. I just could not nail it down.

Some years ago around the same time. Enter podium discussion at a tiny conference close to Detroit. Some agile “what-ever”. I was on stage with two big names. No idea why I was asked to participate on stage. The topic was agile scaling or rather how to run big projects in agile. At the time, I was very much into micro services and reversing Conway’s law and architecture centricity and topics around it. We were discussing the standards like big room planning, program boards, minimum viable products, walking skeletons, whatever… At one point I had an idea. “We need to manage the work such that there are as few as possible dependencies on the board. Best case scenario is NO dependencies.” That one touched a nerve and I was disqualified as not understanding systems at all. Easy bait. Lesson learned: Do not be creative on stage. Does not work.

But: Still, the idea was attractive to me. It leads to simple solutions with very little dependencies and dependencies is where I get a headache.

Fast forward to some project management conference. Quite a few system engineers were presenting. I have seen a few people proudly showing off their skills in management of complex dependencies.

My mantra became a lot clearer: “Keep it simple, stupid.” There are many variants to the idea and it dates back a couple of hundred years. Just search the web for some trivia. Anyhow, the recommendation to the executives by the consulting company should have been:

“You need to reduce complexity.”

How to reduce complexity? Make it complicated for few and simple for many. This involves

• Unterstanding that architects are in a leadership role. They shape business and products. Cannot be separated. Both go hand in hand.
• Understanding that organizations that develop systems are systems themselves and that these are social systems of people, developing for people. (In the end there most of the time there is still a human interacting with your product. The product should be there to serve a purpose.)
• Understanding that the world is changing at a certain pace. To manage solutions, you need to be faster than the changing environment. Elements of self-management might be a good idea to maintain speed.
• Understanding that “divide and conquer” does not necessarily mean micro-management.

Why should we reduce complexity at all?

• Simple solutions are easy to build.
• Simple solutions are easy to adapt and to modify.
• Simple solutions are cheap.
• Simple solution can be delivered very fast.

Complexity kills speed. I want to move

The post Dealing With Complexity appeared first on Grado.

However, money in itself is not a goal – it’s more the effect of doing the business right.

The post Economic objective appeared first on Grado.

Shared and respected values serve as a universal north star that aligns team members on how to approach any challenge or disagreement, even if there is debate about the approach or outcome.

Values are a set of shared beliefs that guide the organization. Our values shape our thoughts, words and actions. Our principles are the rules for how we will act.

The post Values and principles appeared first on Grado.

A just cause must be:

• for something – affirmative and optimistic –
• inclusive – open to all who would like to contribute –
• service-oriented – for the primary benefit of others – thereby building a loyal base of employees and customers (and investors) who will remain loyal to the company through thick and thin.
• resilient – can withstand political, technological and cultural change –
• idealistic – big, bold and ultimately unattainable – attainable is a vision that also plays an important role.

What doesn’t qualify as a good thing is

• Moon shots, i.e. hard to reach targets
• “to be the best”, that is, to measure oneself against the competition.
• growth per se
• Social responsibility, i.e. things that the company pursues in addition to its primary objective

The post The common cause appeared first on Grado.

A system that is surrounded and influenced by its environment is described by its boundaries, its structure and its purpose and expressed in the way it functions. Systems are the subject of systems theory.

Examples of such systems are

• Drivers traveling on the A8
• A beehive
• The spectators who want to go to a football game in a stadium
• A software team

Some basic properties of systems can be named:

• Systems have a purpose. The beehive ensures the survival of the bee swarm.
• Systems have a function or form of interaction. The function of the software team is to work together on a software system.
• Systems only function as a whole. The structure of the system is important. A beehive without the element of “worker bees” does not work. If you cut a mouse in half, you don’t get two smaller mice. On the other hand, if a wrench is lost, I still have a collection of tools.
• Systems want to remain stable. They achieve this through feedback loops that build on the way the system works.
• Systems, especially biological and social systems, are emergent, i.e. they continue to develop, they can also develop their purpose further. This will not happen to me with my car as a technical system – these are more limited.

Without these conditions, it is not a system, but an accidental collection of objects or a collection.

System thinking as described here is not the same as the work of, for example, systemic coaches.
The former focuses on describing relationships and feedback cycles.
The latter comes from the description of sociological and biological systems and works with even more general concepts.

Recommended Resources

1. Introduction to System Thinking A very precise and compact introduction. After that, everything is actually said.
2. The Fifth Discipline The classic for system thinking in organizations. In addition to a consistent systemic picture of organizations, it describes central patterns of relationships and feedback loops.
3. Autopoiesis (de) An introduction to the key concept of the world of Luhmann, Maturana and Varela (in German)

The post System Thinking appeared first on Grado.