Dandy People > Articles by: Robert Nordh

Author: Robert Nordh

Enterprise Agile Coach, Interim CTO & Transformation I help organizations, leaders and teams increase value by adjusting strategy, architecture and ways of working. I always strive for wide-spread inclusion to achieve common goals.

Agile Architecture in a Nutshell – Free Poster

Written by

Technology is an enabler and accelerator for today’s modern product organizations. Companies and organizations often rally around agile working methods and creating effective teams. At the same time, the technology is paradoxically forgotten or taken for granted. It is often when technology poses an obstacle or when the technical debt has grown above the surface that technology issues come up on the agenda.

So the question is, how can we bring in technology development as an equally obvious part of product development? How do we ensure that features and technical enablers mutually contribute to great products? How do we ensure that the technology together with agile working methods solves bottlenecks and enables value flow?

This is where the poster Agile Architecture in a Nutshell comes in.

Download the poster as a High-Res PDF here

Buy a printed A1 version here

The poster is intended as a cheat sheet of condensed wisdom based on experience from digital product organizations. It can be printed and set up in the corridor and be a support in the dialogue between PM, PO, agile coaches, scrum masters, architects, tech leads and developers.

The poster helps to have a dialogue about complex questions such as: What is agile architecture and what is it good for, how do we accomplish technical transition through continuous improvements, how do we take bigger technical leaps, what can we do instead of reorganizing, how should we think when layering the architecture, what is the architect’s role in the DevOps journey, how do you achieve governance in an agile way, how do you get the teams to build in the right way, how should we visualize the architecture, what competence requirements should are important when we hire an architect, what tools does an architect need etc.

Solutions to questions like these differ, of course, depending on the company, industry, history and current challenges. But the poster can be used as a guide in the discussion with engaging illustrations, models and concepts that contribute to the dialogue. All to contribute to working agile with the architecture, which in turn contributes to even more awesome products reaching the market faster.

What is Agile Architecture?

There are plenty of definitions of architecture. There are also plenty of theoretical discussions when architects discuss. At the same time as the architectural work is something very concrete – a work of removing obstacles and creating new opportunities with the help of technology. An attempt to define agile architecture is therefore: “flexible structure that is created just in time to enable value flow”.

It may be wishful thinking, but what is needed is a “flexible structure” that helps the teams today and tomorrow, where it is easy to adapt the architecture to new product requirements, new forms of collaboration and to add new or remove old technology. It leads the thought to loosely coupled architecture that is layered, component-based or broken down into microservices.

“That is created just in time” where long-term and intentional design is balanced with emergent architecture. If the architecture is planned too far in advance, plans and target architectures are out of date before they are used, and vice versa, if the architecture is not planned in advance, the teams create hacks and workarounds. It’s about putting your ear to the rail and finding a sweet spot between the two. Something that must take place in close collaboration with product owners, flow managers and teams.

Architect to enable Value flow

Architecture is fundamentally about continuously creating and improving the flow of value to the customer through products using technology.

Central to achieving this is a constant tug-of-war between the drive to create business value and counter-forces in the form of technical constraints. Business value – the ability to constantly improve time to market, eliminate bottlenecks and improve product quality through technology. Limitations in the form of technical debt and lock-ins created by Conway’s Law which, in a simplified way, means that the teams build the architecture they need, which is often an obstacle when products, teams and ways of working change.

(more…)

The C-level Executives Role in Agile Transformation

Written by

Agile transformation is an exploratory work. It’s a change that takes place step by step to constantly improve products, architecture, organization and ways of working. In addition, all parameters are interconnected and affect each other.

The most important success factor in establishing agile on a larger scale, outside a team or a release train, is C-level support to influence the entire system. By the system is meant the total system in the form of organization, technology and people. Even if agile transformation is a gradual change, it will sooner or later impact the whole company, and the executives need to be prepared to make appropriate decisions. Exploratory change can also create confusion and uncertainty among employees, which makes it extra important that decision-makers are confident and supportive. 

A C-level executive (CEO, CIO, CPO, CHRO, CFO, CMO etc) is a decision-maker, inspirer and leader of the system in its entirety, and regarded as the “real” change leader. This means that agile coaches, scrum masters, product owners and change leaders should be viewed as catalysts and enablers for change. They are the messengers and doers, based on the direction set by the executives. Managers, other decision makers and teams make decisions in line with this direction. 

Success factors for agile transformation, based on what the C-level executives should focus on

  • Create a common vision and direction
  • Communicate the change
  • Lead through others
  • Create passion and psychological safety
  • Make the necessary decisions

Create a common vision and direction

The C-level executive needs to set a vision and direction for change. What to achieve and why. This should preferably be measurable and produced in co-creation, but the C-level executive needs to own the change. 

If it’s a change that affects several organizations, then it’s the managerial level above that sets the objectives, ultimately the CEO if it affects the whole company. Alternatively, the heads of the organizations need to agree on common objectives and avoid conflicting goals. Otherwise there will be conflicts on operational level, with fights about resources, and the development teams being stuck between priorities. .

Tools & methods: Company Bets, Objectives and Key Results (OKR), vision story, message analysis, time machine, storytelling, metaphors

Examples of areas to improve: time-to-market, value flow, number of releases per year, technical modernization (to achieve increased flow, reduced costs, higher quality, security etc)

Communicate the change

Communicate “What” and “Why”

The C-level executive needs to convey the message of “what” to achieve and “why” at conferences, in newsletters and communicate in daily conversations with the same message. They also need to communicate progress and that the change is important. 

Executives should have a monthly schedule for the agile transformation. The monthly schedule can include: general meetings, release train meetings, product meetings, strategy days, team visits, visits to scrum meetings, etc. – all to show their support.

Tools & methods : Ask Me Anything (AMA), Big Room Planning (BRP), Management by Walking Around (MBWA), conversations one person at a time, what & why presentation, video, newsletter

Communicate agile values

At the core of an agile transformation are the agile values. The C-level executive needs to constantly refer to the importance of following the values. For example: Asking questions about what we can do today, to improve a little for tomorrow. The importance of delegating and that decisions should be made where the expertise is. The C-level executive should specify which agile values are most important for this particular change. 

Celebrate success

When the change is moving towards the objectives of the change, it’s important to celebrate. This is something that executives needs to encourage and sometimes invite to larger celebrations for the organization.

Create passion and psychological safety

Passion for change.

Change, at its best, leads to commitment and passion. Employees who have been waiting for the change, finally see that something is happening. Agile coaches help to create a safe and inspiring environment with the desire to experiment, where it’s okay to make mistakes.

Executives need to support this and pep, inspire and be a transformative leader who is transparent with his or her own change. It’s a great advantage if the personal change is in line with the organization’s. It can be, for example, to become a more servant leader, to delegate more, to ask more compared to giving orders. “Be the change you want to see in the world”.

Tools & methods: Positive psychology, storytelling

Psychological safety

Change can also lead to turbulence and resistance. Agile coaches need to know that there is support for the change, to be able to deal with the storm when it comes. Managers need to be prepared to have challenging conversations and guide employees. Executives need to coach and guide managers, especially those who are reluctant to change. If there are strong opponents to the change, there may be a need for staff changes. 

Tools & methods: Active listening, Non-violent Communication (NVC), coaching

(more…)

Architecture or What is Love?

Written by

Imagine ten architects in a room. 

The first thing they would discuss is: “What is architecture?”, and they would use all the time they have at their disposal. 

If no one comes into the room and yells at them that they have to create a target architecture, a guiding principle or anything that helps the teams solve a technical obstacle that stops all delivery in the release train, they will continue the discussion. 

The first architect will say that there are standards and you should not reinvent the wheel. 

The second architect would state that there are several standards and which one should you comply with? 

The first architect would argue that ANSI is the one and only, that states that it’s all about organizing a system, its components and how they relate to each other and the environment. 

The second architect would say that ISO is the preferred choice because it focuses more on the properties of the architecture’s elements, relationships and principles of its design and evolution.

At this time, the third architect would state that there are thought leaders out there like Gartner.

The fourth architect would interrupt and refer to the Zachman Framework from the 80s and that there are some really good nuggets there. 

“Domain-driven architecture”, the fifth architect says and then the argument is in full bloom.

“Event-driven architecture”. “Pipelines.” “Pace-layered”. “Togaf”. “Components”. “Microservices.”

Until the sixth architect, the veteran who will retire in six months, says: “OSI Model. If it’s not broke, don’t try to fix it”

The room all goes quiet until the seventh architect, the newly educated with fresh ideas from the outside world says: “SAFe” and all other architects say “No!” while he raises his arm and says with a fragile voice “They describe much more about architecture than you think”, and all other architects stare at him with a blank expression, some of them raising their eyebrows. 

“Anyway”, says the eight architect, “architecture is easier to understand if we use metaphors. Architecture is like a garden. If you don’t take care of it, it will grow freely and become chaotic. Entropy is a natural law that takes over”.

The seventh architect, still trying to understand why everyone didn’t appreciate SAFe, says: “it’s more like a runway where the code can land. You cannot build the runway while you are landing”

“That metaphor is lame”, says the ninth architect, “its better with train tracks that the train travels on. It’s a parable everyone understands.”

“Or the road railing that you have to stay within on the highway” says the first architect. “Otherwise you collide. Not everyone lands planes or is a train driver. On the other hand, many have driven a car and can relate.”

“No, it’s more like a pop song” says the second. “You have three chords that you can combine so that everyone can sing and dance along.”

“More like jazz where you can improvise once you have experience and have all the theory”, says the third.

“Or a classical ensemble where everyone plays an important part, and it’s only when all is combined that you hear sweet music”, says the fourth while the fifth, sixth and seventh nod in agreement. 

At this time the tenth architect, who has been quiet until now, would clear his voice and say: “Architecture is like love”, and all other nine architects turn their attention to him and listen.

“No one can define it, but everyone knows how it feels. Emotions flow, you walk on light clouds, nothing is impossible, no obstacles are in the way and you can conquer the world!”

“Yes!”

“Awesome!”

“There you have it!”

All architects give their acclamations and raise from their chairs and start clapping and dancing with stiff movements. 

(more…)
Shopping basket
Related Trainings
Our Trainings
Build the Right Product – Product Ownership Training – 2 Days On Site
Build the Right Product – Product Ownership Training – 2 Days On Site
Target Group: Agile coaches, Product Managers, Product Owners, Business developers, Architects and developers, User- and Customer Experience (UX/CX) (User Researcher, Interaction design, Graphic Designers, Art Directors) Anyone involved in the process, and those facilitating it.
Teachers: Mia Kolmodin
Read more and Book this Training
New date coming soon