Six rules for APIs according to Werner Vogels:

1. APIs are forever
2. Never break backward compatibility
3. Work backwards from customer use cases
4. Create APIs with explicit and well-documented failure modes
5. Create APIs that are self-describing and have a clear, specific purpose
6. Avoid leaking implementation details at all costs

According to Werner Vogels, these are lessons learned over 15+ years or so in AWS. He talks about cloud -facing software development. I have more of a systems background. Let me just look at the six rules and translate them into systems speak as I understand them. I am not interpreting. Werner can speak for himself. I just take the punch lines and transfer them into my universe.

1. APIs are forever. Whatever you are exposing as an interface, people will use it. They will build their functions on your API. DO NOT CHANGE IT. It does not need to be a software interface. Any interface will do. 
   O.K. this is a bit scary. I am a big advocate of iterative development. How does this then go together? It does well. Just think of working with a sandbox. In a sandbox you have a lot of freedom in what you are doing and how you are doing it. Remember to start your activities with some architecture. Architecture is the founding principle. Later I will discuss function centricity vs. data centricity and data orientation. Right now we are agnostic to what we are focusing on. 
   If and when we start something entirely new, we will have an idea on the solution architecture of our function. On thing is a given fact: The first idea will not be the best one we will have. Very likely we are going to learn something. A statement you can already find in the Melvin Conway paper. We need to adapt the architecture as we go. Interfaces between the architectural elements are defined via APIs. So fixing the interfaces will fix the architecture. Simply do it as late as possible. I am not advocating to avoid decisions or delay them. No. Just commit as late as possible, but if you commit, commit. You need to be brave. That is all. And there is one more thing, I learned from some digital lawyers when writing terms and conditions for a product. Once you publish an AIP, you have NO CONTROL over how people are using it. You may have had the best intentions. When it is published, it is published and what follows is damage control. 
2. Never break backwards compatibility. If you break backwards compatibility, you are going to hurt people. You need to have a good reason to break it. (When I was working as a function developer, I needed an approval by the department head to generate a branch. You could get a branch if you really needed it. Well, there always was a better solution. You can do many things on the trunk if you are forced to think. Yes, you are not fast in the beginning, but imagine all the time saved in the future. – Kudos to Gerd! What a valuable lesson.) The same goes with backwards compatibility. If you break it, you are going to upset a lot of people. BUT: Very few people oppose progress. You will find a solution. If it is in mechanics, a solution might be a physical adapter. Like in SIM-cards for example. They come in different sizes. With adapters to make them fit physically.
3. Work backwards from customer use cases. Each of the units in the value stream or boundary diagram needs to produce something. If a block does not deliver a tangible result, what is the justification for its existence? Why is it there if it does not do anything? The entire value stream needs to have a purpose, just like the product or artifact I am delivering. Once I have that, I can throw the entire Wardley Mapping machine on it and get make or buy decisions and focus on what is most important. Again, I am simplifying a lot. I believe Haier is driving the idea of architecture centricity and working backwards towards an extreme and very successful direction. Again, I am only interested in some aspects of the story. See the full HBR article on the Haier concept. What I have in consequence is a succession of sub-systems or process steps with a defined input and output and a price tag in terms of duration and costs. I can assess if I want do do the job on my own (for financial or strategic reasons) or if I am going to buy it. This is pure Taylor scientific management at its best – to my understanding. And Wardley mapping. Taylor focuses on money alone. Wardley adds the strategic component. Get your strategy right and put the effort into what separates you from the rest and is not worth buying. Or buy what is not worth generating yourself. How to decide when to do what? My suggestion is to look at what Simon Wardley has to say. Again, do not copy. Understand and apply the concept to your problem.
4. Create APIs with explicit and well-documented failure modes. This sounds familiar to systems engineers. In our context the APIs are representing the architecture of our system. All inputs and outputs are documented. If I am attaching the malfunctions and failures to this documentation, I can see the propagation of failures and basically can define countermeasures for these failures. That is an FMEA (Failure Mode and Effect Analysis) built into the design of the function. In the modern times of “anything as code” I can have this all linked and even automatically generate a Fault Tree Analysis. I could have this “life”. Directly from the code. Right in the beginning of the design of the function I can control all consequences of failures. This is essential for safety relevant functions or otherwise regulated functions. This feature generates enormous transparency and will lead to new solutions of known problems. This is not science fiction. The products you need to get a concept like this up and running do exist and even are open source.
5. Create APIs that are self-describing and have a clear, specific purpose. O.K. this is a bit redundant to my interpretation of point 3., but that does not matter. The purpose was mentioned in 3. already. What was not mentioned was the self-describing nature of the API. Who likes to read manuals? Well, I was know in the laboratories I worked in for actually reading manuals of the devices we were using. Not everybody likes to read manuals. If and when the API is self-describing, nobody needs to read a manual. I acknowledge the benefit and think it is a good idea. If the function is self describing, who then needs a manual or instructions? It is not about reducing work or documentation. The point is simply, no matter how hard you are trying, there is always the challenge that two documentations (code and specification) will separate at some point. Solution: see above. Document in the code, a.k.a. documentation as code — I understand, this is not the same, but you get the picture. 
   There is another thing: If the API describes a sub-unit of a functionality, with a specific purpose, then each of the sub-units can be seen as a process. This a 1:1 correspondence to a production line if you like. There is a definition of the a process as “having an input and an output and consuming time, i.e. modifying the input into output (adding value).” 
6. Avoid leaking implementation details at all costs. This is the pixie dust. Super tough for a technology person like me, not to present all the cool stuff I am doing to the customer/user of the function we are delivering. Just shut up and commit to the deliverables you promise. This is a big challenge in some business contexts that are dominated by lack of trust. There the engineers on the receiving side who often want to be convinced by technical detail. This spoils the game, because then you cannot improve what you have developed. At least not without disclosing all this to the customer. Challenge accepted. At least you should try as hard as you can, not to disclose any details. The less details of your function are known to the outside, the more flexibility you keep for improvement and ratio measures. I am not talking about keeping secrets in front of the customer or betraying the customer in any way. I am talking about keeping autonomy in the development of your function. As long as you deliver the promised result, why should anybody care about what is inside? You are the expert. You know best. I perfectly know that this may be a big challenge. However, when living in a world of mutual respect and co-development and partnership, this should not be an issue any longer. In the end, I could say: “This is what you are paid for.” 

In consequence, this leads to a service orientation-like architecture. Just with the limitation that the services have defined interfaces. There is nothing wrong with starting with a code-first, function and requirements based strategy if we know nothing. The more we however know, the more we should modularize the solution with the help of the API first concept. It is fine to “freeze” the proven APIs and keep flexibility for others. Rule number 6 should always be in place.

Is this all anarchy behind the APIs? No. For sure not. Remember that YOU can define rules yourself after understanding the principles. There could and probably should be governance guarding the methodologies or standards within all the teams. There could be overarching standards. Very likely, as a consumer of the interface, you will have some expectation with respect to the quality of the solution behind the interface. How the quality is achieved depends. Sometimes there is regulated business and there are expectations from external bodies with respect to regulations or so called “best practices”. This can all be part of the governance topics. It is important not to over-regulate the system in order to maintain adaptability and flexibility of the solution. In the end, the idea is that the sub-system or process step in the value map is delivering according to expectation and agreement.

Still there is the idea that all the APIs need to be externizable — the Bezos thing from the article before. Cool. Make or buy decision are then possible on the level of boxes. And the entire thing can scale. We had this earlier. If a subsystem becomes too big and slow to be managed, make it smaller. Either by splitting it at the same level or by introducing sub-level. The API being externizable however also means, I can buy the function somewhere. If I do that, I need to trust the supplier of the function that the supplier will deliver the agreed quality and functionality. Rule six simply means that I need to trust the API. 

A little story to loosen the discussion a bit. When I worked with AWS as a partner in some project, we had a management call. Somebody asked: “What would Jeff say now?” I was close to panicking. Whom did I forget to invite? Jeff who? There was no Jeff in the entire project. Then it struck me. O.K. THIS Jeff. They were checking guardrails. 

Externizable API simply also means, we are following Simon Wardleys mapping idea. This is the make or buy decision in the Wardley mapping. I understand that Wardley mapping is more than this single idea. I just want to give Kudos to where it belongs. And the idea of externalizing APIs is reversible. You can sell the functions to others, like AWS did with the cloud service or Amazon does with its accounting services. Or you can simply buy commodity services. It works full scale.

On big remark: sometimes modularity makes no sense. In this case, just dump it. You will save a hell of a lot of administrative work, but you will loose modularity and serviceability. There is a lot of polemics being exchanged. This and that company now goes back to monolithic solutions, so dump your modularity approach and so on. Remember: your choice. This is what you are paid for. Make up your mind and decide. Nobody will do it for you unless the person takes your job. Whatever gets the job done in your very situation is right. Nothing else.

When should modularity be dropped? There are cases when your adaptive cash-cow product turns to a commodity product. You will have a lot of competition. Others can do the same trick. Now you have the choice: There are two rabbit holes. One is to drop the product and let do others care for the commodity product and maybe buy yourself. Just make sure your supplier then has some competition. The other is to make you product a commodity product. Maybe even re-design it to make it a lot cheaper. Whatever it takes. These are two very valid paths. Make a data-supported decision on what to do and commit. Ever forget: Data does not take the decision for you. You decide, informed by data. (We can go on here on which decisions are to be taken by AIs and so on… I don’t do it here. maybe later.)

Is this now the solution for all the problems? Go API-first instead of code-centric and remember Melvin Conway to generate a homomorphism between team structure and product architecture? No. Something additional is needed. Experience simply tells that if we have no overarching governance in form of an architecture and a targeted functionality that is clearly specified, we are going to generate something that is not well structured and not easy to be modified.

And another question needs to be answered: When am I going to use agile methods and when is a classical set-up more promising? Closely related is a more general concept of how not to loose focus on the important stuff and how to find our what is important. The concept that helps us decide is called Situation Awareness and is formulated by Mica Endsley. Situation Awareness helps us to make the decision. The article “Agile or Not Agile” gives us the parameter.

The post Application Programming Interface First appeared first on Grado.

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.

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.

The post Cynefin appeared first on Grado.