Roles in AO

I add this section because some of you need to understand a system from the perspective of the roles. That is ok.

From an agile perspective, three leading roles are necessary:

“Do the right thing” is about understanding where to go and for what reason. It isn’t the voice of the customer. Being the voice of the customer means that the customer is far away from those working to solve the problem. It is the customer´s interpret. In Scrum, it is the role of the Product Owner.

The Product Owner´s mission is to understand what the customer need is, which can be different than what he wants. He or she translate that need into a vision, the “right thing”.

“Do it right” is all the people having the necessary skills available to build the “right thing”. In Scrum, we called it the Development Team or, as I mentioned before in that book, the operations. The operations are looking to the solution from a technological perspective or all non-functional perspective.

“Do it fast” is the third role who tries to get as much feedback loops as possible to reduce the uncertainty of achievement as soon as possible. In Agile, it is typically the role of an agile coach, a scrum master or a process coach (Kanban). The position is about protecting the interaction of all stakeholders in the system called “team”. He or she is looking at the agile system dynamics.

Because the system is an agile one, it is self-managed. It means that all people in that system are accountable and responsible for the work they committed. That accountability is shared: the whole team is accountable for the results of their work.

In “ Agility “, you might think that the Product Owner is the only accountable and the Development team is only responsible for the execution. The consequence of that organization; you move the Product Owner out of the system, and he or she becomes a Controler. Even if it looks accurate, it is a residue of scientific management when the development is considered a service provider (commodity). It happens, unfortunately, too often, and the system reacts by having one of the team members playing the role of Proxy-PO. Proxy means that someone doesn’t do his/her job and is a bottleneck in the value creation flow. When Proxy is necessary, replace the former Product Owner (PO) and nominate the Proxy as PO.

Something similar happens with Agile coaches or scrum masters. In “Agility”, these roles are the new supervisors. They are the voice-of-the-management and not helping the team and all system levels.

Best agile teams don’t need a level of authority. It is a “praxis” approach where every three parties are negotiating the best way to move forward.

Outside of the system, you will find supportive roles. Those roles are usually experts that are floating around the systems. Those floaters are helping on-demand in a coaching manner.

The management is evolving too in the different AO phases. Once all the silos are broken, and focus is given to value creation, the need for supervision is no longer required. Managers can opt for any roles they expect: team member, agile coach, Product Owner, or Floater.

Ten years ago, while working on the sKale project, our customer asked how to help her to enforce the position of Head of HR towards the Board of Directors. With my colleague Erik, we tried a couple of scenarios intending to keep it as simple as possible. We used Scrum as a simple organizational model that we transposed in all the layers of that company (Bank). The concept was that a CEO is a Product Owner of a product called the company, and the Head of HR might be the Agile Coach of the system called the company. The same principle has been applied in Back, Front and Middle Offices, and all other parts of the structure.

Because Agile was strongly related to IT work, we started a conversation that we called Agile4HR to test our ideas and to understand better what HR does.

The outcome of that project changed the way I address Agile. If Agile is on a project, your change will stop once the project end. If the Agile is IT only, then you want to be able to align IT with all the other parties in the system: customers, business, compliance, etc. That’s not valid if agile is an HR topic. Because of its transversal impact of the enterprise, Agile should be an HR topic and all agile coaches and scrum masters considered as operational HR people.

In my mind, that thesis is almost valid. It is one of my bias from “ Agility” to “ Rubicon “.

Pigs & Chicken metaphor

When starting my agile journey, it was genuine to use a little story of a pig meets a chicken. The chicken is asking the pig if it was interested in opening a restaurant with it. The name of the restaurant will be “Ham and Eggs”. The pig answers that this is a bad idea because he has to be committed and the chicken only involved.

That metaphor leads to define engaged team members in agile as pigs. These pigs are committed and engaged with passion in their work. The chicken is all the stakeholders like management, customers and users, which are only involved.

Initially, I intended to call AO “how to build a pigpen”. But the organization of the Agile Tour Montreal asked me to change the name. Not a bad idea.

Like on the illustrations above, you find “pigs” in “Organization” and “chicken” are mostly in “Structure” and some cases surrounding the “pigs”. No injuries here, the animals are reflecting a character or a behaviour. In some extend, some pigs can be chicken for other pigs.

The purpose of AO is to design an organization full of pigs with the lowest involvement possible of chicken.

How to work with Pigs

If you are part of the system (team), you are engaged, empowered and committed to the shared purpose of that system. In a pigpen, there are only pigs.

When trying to control that complex system, you destroy the expected co-creative dynamic from it. Chicken, the people outside of the system are trying to control because it is the only model they know to influence it. But, as mentioned previously, influencing a complex system only works when resonating with it.

In the AO model, former managers can choose between two types of roles:

• The value-oriented constructive irritant in charge of activities generating value for the enterprise like customer-centric activities (profit) or research and innovation (knowledge).
• Or people and systems-oriented servant leaders protecting the systems and ensuring the sustainability of the dynamics.

Servant leadership is the expected behaviour of a coach working in the system. The term is coming from Robert K. Greenleaf´s book “The Servant as Leader”. In a conference on VUCA, Erich Harsch, CEO of the dm-drogerie market explained that the company is experimenting a model called holacracy. In that model, Harsch tells that he turned the decision pyramid of the company around. He now has to serve the company and not expecting the company helps him.

The constructive irritant is a bold word but emphasises the expectations of that role: positive criticism. Criticism is understood as a negative but reality is quite the opposite. Having the freedom to speak- out loud your thoughts, is necessary to enable a co-creative behaviour. On the other side, when the dynamics in your system is mostly calm, nothing happens.

Emerging behaviour and how you can support complexity?

Complexity is not an obligation, and it is how the world behaves today. Let’s have a brief view of Product Lifecycles. In the traditional operating way, we believe in investing a requisite amount of money in research and development and then start a product line than runs forever. That was valid when demand was higher than the offer, or if you have a monopole.

Unfortunately, in a global 2019, offer is higher than demand, monopolies are challenged or not allowed by regulation. That paradigm coming from the 19th century is no longer valid.

From a systemic perspective, we try to optimise the maturity level of a product to ensure a continuous flow of profit. That flow is controlled to reduce the variability in such a system. Enterprises are expecting to maintain the maturity level as long as possible. Globalisation increased, and the whole product lifecycle has dramatically shortened under five years for manufactured goods to three months for digital assets.

That curve is understandable for products, but it impacts the whole enterprise. Products, Goods, Services are what distinguishes your company from competitors. On the other way, while working for a huge software company, the business processes improvement was always a priority. Business processes automation was vital to the company’s business, and that company is very profitable for years. While looking at the data, profits are still essential, but growth can now only happens in merger-acquisition of other companies. Business processes optimisation cannot proceed due to the enormous amount of processes.

If your company does software or steelworks, and more than 50% of your revenues are coming from Financials services, ask yourself what the company is doing? These are two different business models. Dos, your customer, really understand what you are doing? How does your personal, though? Coherence is key.

Coming back to my software development customer, the complexity of work has a different meaning. It means that all the standards bricks and business process are part of the legacy and no-one in the company knows all of them. A single person cannot gather any longer all the knowledge. It is not because people don’t have the competence. It is because the product is getting old (at the end of the maturity curve) and an alternative solution should have been set up for years. This kind of complexity is measurable when you spend more effort to support than to develop new solutions. In that context, all roles are spread out to experts, and a single Product Strategist is missed. A constructive-irritant being empowered to tell it is enough.

Summary.

In AO, the thesis is that the focus is given to the role and not function or job (Structure). You will have three principal characters:

• Purpose keepers are focusing on the “what”. In scrum, we call it Product Owners.
• Organization keepers are managing safe-to-fail containers. These are the Scrum Masters, Agile Coaches, Process Coaches, Systemic Coaches, etc.
• Agents are focusing on the “How” to transform the “What” in a value for the customer.

These three roles are part of the same system.

In the end, we have an alternative role, the floater. Floaters are “floating” around the systems. They are helpers. From “Awaken” to “AO”, floater are pairing with one of the agents to transfer their knowledge.

Originally published at https://myao.blog on September 21, 2019.