New Certification - FAST Certified Consultant
Scaling by Dunbar's Number, Team self-selection and fluidity, Research time and slack, Self-organization
The most innovative teams are those that can restructure themselves in response to unexpected shifts in the environment; they don’t need a strong leader to tell them what to do. Moreover, they tend to form spontaneously; when like-minded people find each other, a group emerges. The improvisational collaboration of the entire group translates moments of individual creativity into group innovation. Allowing the space for this self-organizing emergence to occur is difficult for many managers because the outcome isn’t controlled by the management team’s agenda and is therefore less predictable.
Fluid Teaming, Fluid Structured Organization, Networked organization structure
Open Allocation, Self-management
Time slack and Control Slack for performance, innovation and adaptability
The Rule of 150 says that congregants of a rapidly expanding church, or the members of a social club, or anyone in a group activity banking on the epidemic spread of shared ideals needs to be particularly cognizant of the perils of bigness. Crossing the 150 line is a small change that can make a big difference.
Perhaps the best example of an organization that has successfully navigated this problem is Gore Associates, a privately held, multimillion-dollar high-tech firm based in Newark, Delaware.
Autonomy, Mastery and Purpose. (Autonomy has four parts: Time, Team, Task and Technique.)
Self-management, Scaling by Dunbar's number
Self-management
Self-management
It appears that there is a way to achieve high levels of productive work with minimum stress, nonproductive conflict, and exhaustion. It is even possible to have fun at work. If this can happen for two days—why not all the time?
The more open and unstructured a workplace... the faster new ideas would be sparked, disseminated, refined, and applied.
If in some way, you could contribute significantly to the way humans could handle complexity and urgency, that would be universally helpful.
Brilliant individuals who could not collaborate tended to fail.
When many parties must work together, simple trumps complex.
Simple rules impose a threshold level of structure while avoiding the rigidity that results from too many restrictions. The resulting flexibility makes it easier to adapt to changing circumstances.
Competing on the Edge argued that companies should avoid the extremes of too much or too little structure.
The idea of eliminating all dependencies in an organization is not realistic. An organization is not a container for completely independent teams—at least not in knowledge work.
Despite all of the cross-functional and teams-for-products separation efforts in this company, many acute dependencies still existed. The situation did not improve when the teams started using agile methods. A team might phenomenally increase their performance and continuously improve themselves, but the effect of this local improvement is limited to the team itself. Stringing together locally optimized units does not create a globally optimized system—as much as I hate to say it. Quite the opposite: If a team optimizes itself to the highest degree, the entire value chain can get messed up. Instead, the whole point is to create a value chain that is oriented towards the customers' wishes.
If we want to increase the system output, we must ensure that the right team is working on the right thing at the right time.
Business agility is not created when teams hold their Daily Standups and search for improvements during their Team Retrospectives. That is at best (local) agile development, which is okay. However, it has nothing, ABSOLUTELY NOTHING, to do with business agility.
For a long time, Kanban and Scrum were basically seen and marketed as high-speed plug-ins for teams. Fundamentally, this is okay if these teams only work for themselves and are not part of a larger context. However, teams are usually part of a larger organizational context
I have seen corporate divisions with more than 2000 employees radically rid themselves of all their old meeting formats.
If we want to manage the dependencies between several products, it's a good idea to bring all the products together on a single board and, as a result, establish a collective Backlog.
I am not saying that estimations are completely unnecessary. I do believe, though, that the effort for making estimations needs to be limited if the business should become agile. An estimation only needs to be as exact as necessary, not as exact as possible. In order to decide for or against an idea, you need nothing more than an approximate size of the implementation.
Trying to make a company agile does not inevitably make this situation better. Cross-functional teams are great to have and an important part of the company. However, it doesn't necessarily mean that old prejudices just disappear. Now you just have cross-functional Team A that performs better than cross-functional Team B. Instead of functional silos, there are cross-functional silos. Congratulations! If you reduce the dependencies and combine teams according to product lines, Product Y is naturally more idiotic than Product Z. And taken from the portfolio point of view, there are only complete morons sitting at the top. With "performance" bonuses, you can easily reinforce this animosity or even make it worse. In doing so, only individual parts of an organization will be optimized, but not the value creation for the customer.
It is a cultural process that already starts with recruitment. The required maxim should be "don't hire skills, hire attitude".
Cross-functionality is a company mentality and not an organizational setup for teams. It means creating an environment where it is ok, or even desired, to perform poorly locally (whilst learning) if it helps the overall performance of the organization.
I also think that many organizations are too hierarchical
Product development is for the most part a complex process, administrative tasks are often complicated [Snowden, Boone 2007 and Stacey 2000]
Focus on Outcome rather than Output If you want an agile business, you should focus on the result and its effect, i.e. the outcome, rather than on the quantity, i.e. the output. In our company today, agility is no longer seen as delivering the largest quantity of initiatives as possible. Instead, more emphasis is placed on considering beforehand—even by the employees recommending ideas—what and how much an initiative contributes most and where the focus should be placed.
The goal of business agility is to positively impact the business metrics. It´s great if you deliver eight percent more features – but if nobody needs them, you have eight percent more garbage.
You cannot implement new ways of working and thinking on schedule.
Do you want to make your business agile or do you want to simply implement agile methods in your company?
If you want an agile business, your focus should be on generating value (organizational processes) and not on organizational structure.
Cognitive diversity, innovation, natural leadership
In situations of complexity, dominance dynamics [positional authority] can have darker consequences.
Many brains are more effective than one brain—provided these brains are diverse.
People found themselves in positions of leadership, then, not by threatening or intimidating subordinates, but by gaining their respect. Hierarchies organically developed not through dominance, but what seemed like a distinct mechanism. To distinguish this form of social status from dominance, anthropologists gave it a different name: prestige.
Dominance hierarchies have different internal dynamics. Given that moving up the hierarchy depends on someone else moving down, it tends to accentuate zero-sum behavior. In other words, politicking, backstabbing, and quid pro quos, along with constant vigilance about internal competition.
Cognitive diversity, innovation