agile42 and Divimove

/by

agile42 + Divimove reference video

agile42's CEO and Founder, Andrea Tomasini, spoke with Tobias Schiwek, the CEO of Divimove, about how Divimove has grown in resilience through agility, with the help of agile42. This discussion has been recorded as a reference video. A fun way to share client experiences and the work that we do!

Divimove, Europes leading digital studio, has recently gone through a major merge, and as a result has had to overcome challenges within the new organization. One of the hurdles was the merging of teams and finding a way of working together. Divimove's aim was not only to grow in numbers, however, also to grow in a coherent way.

The video covers the early days of agile42 & Divimove's collaboration, along with how we helped them visualise their work as well as tools we used to support their transition. Alignment and getting people on the same page was one particular challenge. We found that supporting the new culture and structure became critical, and in the video you will hear in more detail what the outcome of working with agile42 in only 6 months looks like.

Check out the video and listen to the story of Divimove!

Archetypes for change – Leadership coaching in complex times

/by

I wrote an article (08/2020) for the Coaching-Magazin Online about "Archetypes for change - Leadership coaching in complex times" and I'm happy to share the content with you here on our blog. The different archetypes are part of our ORGANIC Leadership® framework which we support organizations with.

Archetypes tie together in an intuitive and powerful way a diverse range of concepts that affect leaders and organizations. This article examines the concept of leader and organizational archetypes. Starting from the root of archetype in myth and narrative and combining this theoretical literature with leadership theories and psychological literature on behavior, it discusses the coaching of leaders through the process of changing themselves and their organizations by understanding their relationship to certain archetypes and the effects of their behavior.

If you want to read the story online, you can do so from Coaching-Magazin Online's webpage.

 

Introduction: what is an archetype?

Archetypes are part of stories: they represent structures or character types that stand for, or even represent, collective ideas, ideals, characteristics, fears, and desires. Some archetypes are almost universally recognizable, such as the self-sacrificing hero, or the loving mother, while others are more culturally specific. It is important to note that archetypes are not stereotypes (Snowden, 2005). People or situations are not shoehorned into them and they are not used for categorization. They just emerge out of repeated collective representations in stories, and we might recognize them when we see them. They also continue evolving as stories are retold or new ones are added into the canon. Because that makes them essentially pattern abstractions with a personality, archetypes can be incredibly flexible and practical: they are instantly recognizable, but rooted in different specificities.

The roots of archetypes go back to ancient Greek philosophy and Plato, who envisioned a world of ‘ideas’, ideal types whose specific reflections make up the real world. They were then picked up in Renaissance philosophy. In the 20th century, the psychoanalysis pioneer Jung gave them clearer shape and much of their modern understanding, identifying archetypes with prototypical images of the world that we all carry around with us, and which are so inherently bound to us that they keep surfacing again and again in our stories. These days, archetypes often feature in narrative research and literary criticism, informing approaches that seek to take a big-picture, comparative view of the word (Campbell, 1968; Frye, 2001).

 

What do archetypes have to do with coaching, leadership, and organizations?

It is clear then how archetypes might be relevant in approaching a book or film, but what do they have to do with coaching leaders? In fact, there are two major connecting points: one has to do with stories themselves, and the other with the kind of understandings and representations that archetypes can support in an organization.

Narrative has of course become a dominant theme in organizational coaching in recent years, with leaders often encouraged to take courses in storytelling (see, for example, Choy, 2020 or Denning, 2005). In fact, narrative goes far deeper than that. The unstructured, natural stories that are told every day around the coffee machine, the stories of success and failure that circulate and justify organizational practices and choices, the elaborate mythology and grand narratives that make up and support organizational values, all these are part of what constitutes the all-important organizational culture (see, for example, Ravasi & Schultz, 2006 or Gabriel, 2004). And archetypes, once we start looking, are one of the elements that crosscut across different levels and connect them, appearing in different forms in all kinds of stories.

By seeing and understanding those archetypes, a point of access in organizational culture in all of its complexity becomes available, which means that we can start affecting it. Archetypes bring together different elements in a natural way. Those studying the art and science of organizations know that the attitudes of leaders in an organization, the underlying culture and structure, and the response of others to those behaviors are connected: directly, indirectly, and sometimes in ways that we cannot immediately see. Understanding archetypes means that these connections are built into our perceptions and interventions without reducing the complexity of both organizations and leadership.

 

Complexity theories of leadership

Mentioning this embeddedness of leadership in partly visible and partly understood networks leads us to necessarily discuss a complex approach to leadership in general. Leadership theories can help us understand what archetypes contain. Given the characteristics of archetypes and the way they are used in coaching (to be more specifically addressed in the next section) it makes sense to turn to complexity theories in particular (Uhl-Bien et al., 2007). Complexity leadership theories were developed as a response to the changing world of work, from a more structured and mechanical to a rapid-based, adaptive one that is primarily built on human knowledge, relations, and capacities. This modern world of work moreover operates in dangerous, constantly shifting markets, sped up even more by technology. Complexity leadership draws from complexity science, which focuses on large, dynamic systems of interconnected components that evolve over time and are in a constant state of change, even without external inputs. In organizations, those components include people and their networks, which brings complexity to a whole other level.

Leadership for an evolving dynamic system should be evolving and dynamic itself or fall behind and desperately try to maintain control of the uncontrollable. In this environment, flexible leadership (now meant as a quality and a dynamic, and not as a position of power or a job description) can create the right conditions to enable responsive evolution, and therefore resilience, and trigger the evolutionary potential of the system without directing it, focusing on speed and learning over efficiency and process control. In order to achieve that, a high degree of well-connected autonomy will be necessary.

Because coaching a dynamic is generally rather difficult, in this article reference will often be made to leaders themselves, with the understanding that they are especially well-placed to influence how leadership is exercised. The rest of this article will focus on how coaches can facilitate through archetypes the emergence of coherent autonomy in a context that enables evolution.

 

Complex-friendly movement through change and coaching for awareness

So how do coaches put that to good use in the process of organizational change, and what does it mean for coaching leaders through it? There are processes for extracting the archetypes that are present in different parts or groups of an organization (see for example Snowden, 2005): contrasting those reveals unarticulated, sometimes critical, variations in perspective. Here, however, we will propose using a series of pre-existing, high-abstraction organizational archetypes that can then be given specific form into the context of application. These high-level archetypes bring together leadership attitudes, organizational expectations, and culture, as well as levels or types of structure and autonomy present in the organization.

The last point is critical, because the range of autonomy levels represented in archetypes makes them an ideal transition tool. The proposed archetypes start from The Expert, characterized by a leader who is the primary decision-maker and communicator with the team. Relationships are one-to-one with the leader and the culture is focused on control. All five high-level archetypes proposed will not be outlined here, but they move in increasing levels of autonomy from The Expert, through The Co-ordinator and The Peer (includes collective decision-making, solid feedback loops, increased responsibility for personal action and a collaborative culture). Finally, at the higher levels of autonomy there are The Coach and The Strategist archetypes, where ultimately leadership is distributed instead of concentrated on the person of the leader, in true complexity fashion, and the leader as a person acts as a strategic conduit between the team and the organization.

 

Identifying relevant archetypes and using them to better understand autonomy

So how does a leader, a team, or an organization know which archetype they can identify themselves with, and use that knowledge to intervene and gradually increase the level of autonomy, and therefore adaptability and speed of reaction, in the organization? As a coach, the process can start with facilitation: in a workshop, people from diverse perspectives share stories of success and failure in the organization and then map those on to archetypes. This shows the coach, not only which archetypes are more typical of the organization, but also which ones people feel more comfortable with and which they consider more effective. Comfort levels are something to take into account in leadership coaching, because pushing premature change will only get rejected and lead to conflict.

Using the most common and successful archetypes as a guide, leaders can start seeing a possible evolutionary path, from the existing conditions to greater autonomy and interconnection within and between teams. The path however is not to the archetype representing the highest possible level of autonomy: it is to the next most autonomous archetype from the one the team is at right now, whatever that is. This is where leadership coaching becomes most crucial, because the key to triggering change are leadership behaviors.

For the practicalities of coaching, leadership behaviors can also be distilled down to six major categories, which of course subsume a whole range of actual actions. These behaviors exist simultaneously in various dimensions, from the perspective of the leader, to the perspective of the team, to ideas of how work gets done and what constitutes success. These overarching behaviors can be described with words like directing, demanding, conducting, or catalyzing. Behaviors and archetypes are mutually reinforcing and feed off culture: a leader’s behavior shapes the culture and archetype, while at the same time being affected by it.

 

Coaching leadership through behavior and contextual awareness

From a coaching perspective then, the first step would be coaching on Emotional Intelligence (Beldoch, 1964; Goleman, 1995), observation and awareness. Beyond the debate on the general validity of Emotional Intelligence as a concept, it is used here as a tool that can be particularly helpful in making connections: the leader can observe the way their own emotions trigger their actions which in turn shape the impact they have, so that they realize this chain for themselves and, through practices such as journaling or regular coaching and reflection sessions, build the capacities for observation.

 

 

With awareness heightened, conscious behavioral change can be possible. Going back to the evolutionary path that archetypes have helped us recognize, coaches can associate the present and the desired archetypes with specific behaviors (which are already part of an archetype’s constellation). Each archetype involves multiple different behaviors and these partially overlap between different archetypes, so for the leader the key is to start adopting some of the new behaviors of the desired archetypes, while maintaining those among the old ones that are still present in the goal archetype. This continuity is an important element for change to be accepted and happen naturally. So, for example, if an organization or group is trying to move from The Expert to The Co-ordinator archetype, a leader might still use demanding-type behaviors, but they will no longer be dictating every detail, and will instead move to a higher-level co-ordination. As the leaders’ behavior changes, the structures around it will start shifting as well, as people and structures around them respond to the changed leadership behavior and new rituals and practices (that can be reinforced to support the change) emerge. The key here is that instead of forcing organizational structure to change in appearance only, the leader uses this heightened awareness and sense of direction to change their own actions and practices, and magnify that impact.

 

The letting go of control and its rewards

This process sounds theoretical, but in its application on the ground it has the advantage of making the abstract immediately specific and graspable by honoring existing knowledge through the intuitive connections embedded in the idea of archetypes. This means that the leader isn’t being aggressively guided to unravel everything and break it down into constituent parts in order to make a difference, but they are being given a way of seeing things that offers power and understanding over their own actions.

The implication here is that the leaders’ control primarily extends to themselves and what they do, as well as what they are able to observe, which sometimes might be hard to accept. It means that leaders will have to recognize that deliberate changes in organizational structures, or stating ideal company values might have very little effect. They will have to recognize that their control over others’ actions (except in the most direct and damaging way) is very minimal. The coach can encourage that process by emphasizing why it is worth it for creating the kind of impact most leaders dream of having on their organization through the cumulative power of small interventions. So what they can do is take action themselves, encouraging the direction they have chosen, as the archetype of their organization changes more smoothly around them, alongside the stories people tell.

 

Literature

Beldoch, Michael (1964). Sensitivity to expression of emotional meaning in three modes of communication. In Joel R. Davitz et al. (eds.), The Communication of Emotional Meaning (pp. 31–42), New York: McGraw-Hill.

Campbell, Joseph (1968). The hero with a thousand faces. Princeton: Princeton University Press.

Choy, Esther (2020). What Is Leadership Storytelling, Anyway?. [online] Forbes. Available at: https://www.forbes.com/sites/estherchoy/2020/01/26/what-is-leadership-storytelling/#313d19f07b17 [Accessed 23 July 2020].

Denning, Stephen (2005). The Leader’s Guide to Storytelling: Mastering the Art and Discipline of Business Narrative. San Francisco: John Wiley & Sons.

Frye, Northrop. (2001). The archetypes of literature. In Vincent Leitch (ed.), The Norton Anthology: Theory and Criticism. New York: Norton.

Gabriel, Yiannis (ed.) (2004). Myths, Stories and Organizations: Premodern narratives for our times. Oxford: Oxford University Press.

Lavine, Marc (2014). Paradoxical Leadership and the Competing Values Framework. The Journal of Applied Behavioral Science, 50(2), pp.189–205. https://doi.org/10.1177/0021886314522510.

Goleman, Daniel (1995). Emotional intelligence. New York: Bantam Books.

Jung, C. G& Franz, Marie-Luise von (1964). Man and his symbols. New York: Dell Pub. Co.

Ravasi, Davide & Schultz, Majken (2006). Responding to Organizational Identity Threats: Exploring the Role of Organizational Culture. AMJ, vol. 49, pp. 433–458, https://doi.org/10.5465/amj.2006.21794663.

Snowden, David (2005). Stories from the Frontier. E:CO, 7(3–4), pp. 155–165.

Snowden, David (2002). Narrative Patterns: Uses of Story in the Third Age of Knowledge Management. Journal of Information & Knowledge Management, 1(1), pp. 1–6.

Tong, Yew Kwan & Arvey, Richard D. (2015). Managing complexity via the Competing Values Framework, Journal of Management Development, 34(6), pp. 653–673.

Uhl-Bien, Mary; Russ, Marion & McKelvey, Bill (2007). Complexity Leadership Theory: Shifting leadership from the industrial age to the knowledge era. The Leadership Quarterly, 18(4), pp. 298–318. https://doi.org/10.1016/j.leaqua.2007.04.002.

Post agile42 Connect

/by

The agile42 Connect - A Series of Fortunate Events was a great success. We had public sessions running from the 27th to the 29th of July, as part of agile42's Innovation Sprint. Usually every year the whole company, including families, gather together for a week of Innovation. Besides working together, creating new things, supporting ongoing work and services, we most importantly - have fun!

This year we were supposed to go to Canada for our Innovation week, however COVID-19 forced us to change tack. We instead went virtual and decided to make some parts of the Innovation Sprint public. We miss not being able to see each other in person, but what can we do?

In this blog post, we will share the Panel discussion with you as well as the other 3 webinars we ran this week.

Help us to help!

This year, we chose a needy charity, Nutrition with Love & Kindness, where those taking part in the #agile42Connect event could donate. This charity converted their venue kitchen business to provide 12000 nutritious meals a month to vulnerable families during this COVID-19 crisis.

Funds raised will enable them to keep providing 12000 meals a month to the local community. Good nutrition improves immunity and creates stronger, healthier, happier humans. With just €8.00 you will feed 1 person for a month.

Please donate and help those in need!

Let's start with the Panel discussion. Through out the week, in the back of our heads, was the thinking around "The NEW NORMAL". What is the new normal? Or is it just the normal? The Panel discussion was about pandemic effects, market changes and what might happen next. The panelists discussed their various challenges, how they've adapted their way of working and insights into how companies can try weather the storm.

We had a great group of panelists - agile42's, Peter Hundermark, was the moderator of the panel, along with guests, Christoph Bornschein from TLGG, Richard Sheridan from Menlo Innovations, Tim Mois from sipgate, Tobias Schiwek from Divimove, Sonja Blignaut from Cognitive Edge and last but not least, Andrea Tomasini from agile42. Below you can watch the recording of the session.

 

OrgScan Summer Offer

If you want to see how your organization is handling the changes we are facing, the challenges and how work is moving on, you can test your organizational culture with OrgScan Starter summer offer. The summer offer is valid until August 15th 2020.

Tuesday started off with a session in the morning by Bastian Wilhelms, one of the founders of sipgate. At sipgate, Bastian has been driving the change to an all-in agile, decentralized and mission based organization since 2009. He is a Senior Advisor to the Product Leads at sipgate and helps set the vision for success with Scrum as well as sipgate’s overall company strategy.

He gave us very interesting insights into how work has been continuing at sipgate, as well as how to find and establish meaningful metrics for any recurring fee business model. He also delved into story-telling techniques.

Please find the recording of this session below.

Tuesday ended with a session together with Richard Sheridan who gave us a virtual tour of Menlo Innovations. Richard shared Menlo’s history, culture and practices – and how they're rebuilding a joyful culture in our new normal of today. It was nice to be able to take part in the largest (so far!) virtual tour of their company. Some of our agile42 colleagues actually visited Menlo a few years ago, and now we had the chance to hear how Menlo works today.

The stories which Richard shared are something that we all can relate to, and if you missed this session, please find the recording below.

If you want to sign up for a tour, please feel free to contact our friends at Menlo!

Wednesday was the last day of our public webinars. The day started off with a presentation by Yasmin Akay and Lena Natus. Yasmin is the Managing Director of Divimove’s Production and Strategy Studio, Europe’s leading digital studio and home of digital content creators. Lena is a consultant at Divimove, and her role is Company Culture and Organizational Development. She is also an actress. This session was about Human Behaviour consuming entertainment content and interacting with it.

They spoke about Social Media, different platforms, what to think about, how to try out new things, to be human, to breath and to listen to the audience you are trying to target. This session was incredibly valuable to all of us trying to build images of ourselves online, as well as branding our companies.

Have a look at the recording here!

Last but not least, I want to thank everyone that took part in our #agile42Connect event this week. We had many new faces join the webinars along with our valued regulars.

A big thanks to all of our guests, some of whom even took time out from their vacations to join us! It was a pleasure to hear your thoughts and ideas on the "New Normal". As the guests donated their time for free, we really hope that you can make a donation to Nutrition with Love & Kindness!

A big thanks to all at agile42 for the fantastic virtual Innovation Sprint. 2020 will be the Innovation Sprint we will never forget. We're also sure our "fun day" on the 30th July will be just as memorable!

See you next year! 

Meet Richard Sheridan and Andrea Tomasini

/by

We are pleased to announce that the webinar that took place on July 2nd, held by agile42's own Andrea Tomasini and his friend and colleague in leadership, Richard Sheridan from Menlo Innovations, was a great success.

We had people joining the session from all over the world, asking these two thought leaders great questions, and interacting with us in the chat.

The webinar kicked off with Richard giving an introduction into how they have been tackling the "new normal" at Menlo Innovations. Letting everyone in on stories about how they shifted to operating virtually and how they are maintaining social connections in these difficult times.

 

Here you will find the slides from Richard's talk!
https://menloinnovations.citrixdata.com/share/view/s81fd9587b4d4fb4b

 

Andrea then gave an introduction into how agile42 changed their way of working, not only internally, but also with their clients. There was a need to adapt quickly and agile42 managed to steer the ship in the right direction. He also shared how proud agile42 is of their clients, the way in which they pivoted their way of working whilst taking into account the safety of their employees. Andrea's presentation focused on ORGANIC Leadership, and how this framework can help organizations lead in this "new normal".

Below you can see Andrea's notes from the webinar:

 

The focus of the discussion between Richard and Andrea was also about the safety of people in organizations. They stressed that it's important to ensure all employees have what they need to be able to work from home, stay safe and cope in this "new normal". It has not been easy for agile42 and Menlo Innovations, as both Richard and Andrea mentioned, however staying strong together is key.

We had a number of requests to record the webinar, and as usual,  we did :-). If you missed the webinar, or you would like to listen again and share it with your network, you will find the recording below! It is available on YouTube.

 

 

Andrea also discussed the ways of measuring how the organization is performing. Survey fatigue was mentioned plenty of times in the chat. Employees are tired of doing surveys on a regular basis and struggle to see the value. agile42 has created the Organizational Scan, OrgScan for short, which uses the patented SenseMaker® technology. It shows your organizational culture, your main leadership styles and what your organization values by collecting 100% anonymous data from you and your colleagues. Through including micro-narratives and a patented design that cannot be gamed, the OrgScan offers real data, unlike an interview or a questionnaire which is influenced by the personal situation or the mood of the contributor.

If you are interested, please have a look at the Starter Kit, and get in touch! The Starter Kit is a perfect way to get started and experience the value of the OrgScan. The OrgScan is a fun way to describe what you see and feel in the organization, without the feeling of filling in a survey.

 

If you would like to take a look at the books Richard and Andrea have written, you can find the links to these in the original blog post, introducing this webinar.

For more webinars and recordings, please look here!
Hope to see you in the next ones! 

 

Diagnosing and changing organizational culture

/by

One of the main aspects of any agile transformation program is cultural change. During times of working from home it’s even more important than ever. 

Based on the 1st ORGANIC agility principle, “Increase Cultural Awareness and Coherence”, the main challenge is how to understand your organizational culture and how to create coherence based on shared principles without losing diversity.

In this webinar I shared my experiences of using the Competing Values Framework, developed by Robert Quinn and Kim Cameron at the University of Michigan. This framework gives us a model with the purpose to help change agents identify effective ways of diagnosing and changing culture in order to enhance organizational performance.

I am pleased that the topic of the webinar got so much attention. We had people listening from all over the world, and so many questions that unfortunately we ran out of time. We hope that we can continue some discussions with the participants in the future. It was fun and great that the audience was engaged in the topic with comments throughout the session. 

For those who missed the live session, don't panic! Here you can find the recording, and it is also available on YouTube.  Have a look at it and feel welcome to share it around with friends and colleagues. If there is anything we can help you with regarding this topic, feel free to contact us. 

 

 

If you are interested in the Organizational Scan for your organization, feel free to look into our OrgScan Starter Kit. This is a good starting point to understanding the culture of your organization. More details about the OrgScan can be found here. Don’t hesitate to get in touch! 

To learn more about ORGANIC agility, you can have a look at our webpage. We’re continuing to run the Certified ORGANIC Leadership® Foundations (provides CAL1) sessions remotely, so get in touch if you think this would be something for you and your organization.

If you are interested in reading more about ORGANIC agility, you can buy the ORGANIC agility book from Amazon. 

We have more webinars coming up, and the previous ones listed on our website, so please have a look at them here. More webinars!

 

 

Culture is the catalyst

/by

As an agile coach, I always look at everything in my life with my agile glasses. I always follow the agile philosophy. This happens while working professionally in my business life, and it also happens while pursuing family and other affairs in my private life.

I have a six year old daughter. My inspection about her learning journey on new skills and knowledge is that she gets the best results while playing games with her friends or me. Children like playing games all the time and every time they gain new knowledge and enhance their skills in the particular topic. At agile42 we believe that adults and professionals also best learn new concepts and understand them by practicing and by doing simulations in trainings and coaching sessions. Therefore we develop and use a lot of games and simulations while working with professionals.

I like to see how adults and kids act on the same context and environment while playing agile games, so I make some experiments to see how kids play agile games and how they act during the game and if there are any different learning topics out of the games.

I recently facilitated the Marshmallow Challenge in my daughter’s class who are at the age of five and six. I picked this particular game because I also facilitate this in my professional classes. Some colleagues from Canada has also facilitated this game previously with kids and you can find some good blog posts about the concept of this game on our website. The inventor of this game, Tom Wujec, has also a number of related stories on his blog.

My Marshmallow Challenge

Since it is so well described, I am not going to explain the game in this post. However, I want to share the outcomes and my observations about cultural effects and teamwork concept mostly.

My brief notes from the experience of the game are as follows:

  • Children were very excited and interested to play the game.
  • Children have no trouble understanding the game. We helped them to divide into two groups to play the game.
  • The first point to mention is that as soon as I said “go and build” they wanted to start building immediately.
  • Although they understood the rules of the games the most difficult thing for them was to work as a “team”.
  • They really struggled to work as a team, they were acting personally trying the get the materials to build the tower. More active kids obtained the most of the material leaving rest without materials.
  • So I and their class teacher stopped and reminded them to work as a team again.
  • Soon one of the groups realized that if they worked together and collaborated and used the distributed materials together they could reach the goal and they started working as a team.
  • At the end of time box, the group who realized the team concept were able to build the tower. The group who worked individually did not have anything but only wasted material in their hand.

Learning to work as a team

After the game I talked with their class teacher and discussed the fact about how the kids were struggling to work as a team. We agreed that they will not be used to the team concept, if the culture and education system does not encourage team work over individual performance. A natural consequence is that these kids will also be struggling to work as team members when they have grown up.

We all know that the problems we encounter in business are complicated, and the solutions we need to develop are not plug-and-play. It is often not possible to achieve the desired business outcome based solely on the competence of one person and her knowledge of the expertise. Therefore, professionals with different competencies and expertise need to come together as a team to produce solutions, test them quickly, and produce them iteratively.

There is no one-size-fits-all

Finally it was nice to experience the game with kids and results that was relevant to our context. Realizing one more time that culture is also the main catalyst to grow and let the concepts like self-organization, team work, experimentation, etc. live in organizations. As it is a fact that culture is different from country to country, it’s also different in various organizations even different in various parts of the same organization. So agile coaches, we can’t apply the same solutions in every single organization. We need to find solutions and optimize them through retrospection and continuous improvement relevant to the cultural context of the environment. There is not one size solution that fits all. There needs to be real focus and support to grow agile concepts individually in each of the organizations.

Managing Work Without Resource Managers

/by

Recently, my daughter passed her driving test. She’s now legally able to drive on her own on the roads of British Columbia. Experts have ruled that she has the necessary skills; she is able to control a ton or more of steel in a fluid environment filled with other drivers at the wheel of their own ton or more of steel. Mum and dad aren’t so sure. Well, let’s be fair. We are confident in the skills of our daughter. She’s an excellent driver. But letting her drive unsupervised on the roads of BC fills us with trepidation. What if this happens? Or that? How will she cope? Surely she needs more supervision, more lessons, more experience? Letting go is hard.

As a resource manager, the feeling can be the same. Your team is skilled, they know what needs to be done. But what about when this escalation comes in? Or when they need to touch this part of the system? Or they have to collaborate with other experts from other parts of the company? How will they manage? Letting go is hard.

Moving to dedicated, self-organized teams will cause a manager’s role to change substantially. Your skills as a firefighter, jumping to the needs of your business and rapidly deploying the right people at the right place are not as valuable as they once were. In fact, they are a distraction, causing chaos and mayhem where once they created order and satisfaction. Instead, you should focus on three specific areas: 1) creating a safe-to-fail environment, 2) creating a learning path and 3) facilitating collaboration.

Creating a safe-to-fail environment

First, you need to allow teams to work safely. They need to be free to make mistakes without causing disruption to your customers or delivery delays to your stakeholders. You achieve this through collaboration, short iterations and regular delivery of a working increment of software. These are techniques that demonstrably work and validate the decisions made by the team. This means more than simply insisting on short sprints, it means helping teams share what they are working on with other teams dependent on their work. You might use a scrum-of-scrums for this. It means making sure teams don’t use technical or organizational complexity to delay creating a working testable increment. It means working with teams to define what done looks like and wherever possible automating the validation of those done criteria. You want the team to know what “good” looks like and where possible, automatically feedback to the team (and the stakeholders) the achievement of those criteria. Rapid visible feedback provides a safety net for all concerned. Stakeholders can build confidence in what the teams build and development teams get quick feedback that they are on the right track. Critically, your role becomes a monitoring and oversight role, making sure the right things are being done and progress is being made while protecting the integrity of your product.

Creating a Learning Path

Second, you want to create a learning path. This includes both cross-fertilization and individual growth. You must determine how teams build competency in skills or areas of your product they normally aren’t familiar with. Your goal is T-shaped individuals rather than I-shaped individuals. That is, experts in their own fields/domains (I-shaped) plus a working knowledge around their fields/domains (the cross-bars on the T-shape). Encourage pairing. Demand shared code ownership over deep specialization. Facilitate share-backs and technical discussions across teams. You also need to provide a path for growth as well. For example, allowing developers to gain expertise in architectural design. You can use communities of practice (or the ever-present guilds concept) to allow teams to stay connected and learn from one another. As an ex-resource manager, you can now provide direction and inspiration for learning new skills, evolving and growing your group’s understanding and creating a more productive and fine-tuned capability. You can collaborate with your team to create a shared strategic vision for the development of your functional capability and then facilitate your practice or guild meetings to achieve these goals.

Facilitating Collaboration

Encouraging collaboration takes effort. As you can see from the above examples, there are several forums for collaboration, such as  a scrum-of-scrums or a practices meeting. Holding the meetings isn’t enough. Remember, many of your team members may not be used to collaborating. They may not feel safe, they may be unsure what is required, they may just be shy. As Hemingway said: “Never confuse movement with action” — good process and good results are different things. Having a scrum-of-scrums booked doesn’t mean dependencies are identified and discussed. Nothing makes this more transparent than watching what happens when teams need skills outside of their group. You can see this when there is too much work coming into the backlog that is dependent on a single skill set on the team, or the need for an expert in a part of the system that isn’t well understood on the team. In these situations, it is difficult as an ex-resource manager to facilitate and get the team members to solve the problem themselves, it is all too easy for the resource management gene to rear its head again.  Be careful not to backslide into command-and-control. Which teams might be able to help? Bring them together, and then get out of their way. Allow product owners to negotiate moving items from one backlog to another. Or teams to arrange for pairing, cross-learning or temporary secondment of skilled developers from one team to another. Whatever the solution, your role is to facilitate independently, ensure a safe-to-fail environment and help teams learn from their experiences so that the need for cross-team coordination is reduced over time as teams build broader capabilities in their domain.

So is my daughter driving unaccompanied? Of course she is. She is taking longer and longer trips. Pushing the envelope with more miles and more complicated routes. Learning as she goes. We still take every opportunity to ride shotgun, to see how things are going. And we still track progress, arrivals and departures. That’s just good parenting. But we’ve had to let go a lot more than planned. Just to keep us honest to our principles, now she’s asking to go bungee jumping. *sigh* Letting go is hard!

Our visit to the Menlo Innovations factory

/by

“To end human suffering as it relates to technology” – The software industry has done a huge disservice to its users, by assuming that they are not as competent as the people who built these products. The success of “… for Dummies” series of books is proof and unfortunately also acceptance of this belief. The greater purpose that Richard Sheridan and James Goebel are chasing has taken decades for them to practice, in their journey many have joined, left and then some joined again (‘boomerang Menlonians’) at Menlo Innovations. The company is driven by a higher purpose that challenges common assumptions that we have taken for granted and explicitly pursues “joy” for the users that use software products developed at Menlo Innovations. Apple and other companies have proven the value of “experience” and the economic benefit of selling “self-expression”. This attachment of personal expression to the products we use is nothing new; for ages people have used artifacts and trinkets that have served as medium of expression of our identities. Our notions of software systems and their utility is firmly rooted in its efficient functional utility. Perhaps in the days of limited memory and low level programming languages, this may have been the need of the times – to complete account balance transactions for all account holders overnight. We have clearly outgrown our expectations of and from software products. It is no wonder that products that delight are winning our hearts and our money.

agile42 team with Richard Sheridan at Menlo Innovations

This pursuit to end human suffering for users of products developed at Menlo, has extended into “the software factory” that is Menlo Innovations. It is so strange to hear about the physical space where Menlonians work to be described as a Factory. My notions of a factory implants an image of oppressive management and underperforming work force, continuously in a struggle within a de-humanized, mechanical environment. One would expect to see pursuit of ruthless efficiency, but instead there is active pursuit of “joy” in a systematic, methodical manner. During our visit it was obvious, I felt it – the culture. Living, breathing, morphing, taking shape in the form of experiments that are continually attempted here. The high degree of engagement from Menoloians working in pairs, or more like teams made up of pairs, creates this industrial hum. Much like, one does not ever say “lazy bee”, you would never say “disengaged Menlonian”.  Gallup polls have steadily charted employee engagement via surveys, reporting 68.5%  of employees are either “actively disengaged” or “not engaged”. Discovering a factory of engaged people was, well, a joy to watch.

Is there such thing as continual joy? Could one perpetually be in a state of joy? Of course not. The joy is in the fight. A good fight. A fight worth taking on. For Menlonians this is to end human suffering as it relates to technology. In the use of products developed at their software factory. I strongly contend that it is their “Greater Cause” that has given birth to their culture and it is this constancy of purpose over the last 15 years, that has defined and shaped their culture. This “greater cause” is the drive, the fight, that continues to breathe life into what we experienced for a day at Menlo.

It is too simplistic to take a look at Menlo and describe it in terms of its practices such as pair-programming, strict 40-hour work weeks, babies in the workplace and the oft-heard “hey Menlo … ?” questions.  Describing it in term of patterns, such as visual and tactile information radiators, is equally naive. It is similar to having seven blind people feel different parts of the elephant and miss the majestic beauty of the being. There is much at play, more than what any human or any erudite committee of experts can ever comprehend. One would never describe oneself by the clothes (s)he wears, the artifacts (s)he possesses, the house (s)he lives in, the people (s)he befriends. All these are extensions of choices manifested through what is visible. While these practices and patterns give form to what is understandable, there is much that is ephemeral, this effervescent essence escapes recognition, yet it can be felt. Is this what we call culture?

Every body works in pairs. This is the norm at Menlo, when it comes to its development and test teams. While other roles, such as Project Managers & HTA (High Tech Anthropologists)s do not always pair. It is an explicit rule at Menlo that no one can write a single line of production code alone. Only a pair – two people working as one unit – is allowed to write production code. This simple rule, sends a strong message – “You are not alone.” This simple rule explicitly builds “help” into its organizational DNA.

A board at Menlo Innovations factory in Ann Arbor, Michigan

Through their Extreme Interviewing process, Menlo selects people who are good at the Kindergarten skills of being able to share, care and play with others. This self-selection of people with like inclinations strengthens their core culture. Folks that make it through the interviewing process, which includes a group interview (in pairs, of course) followed by both a 1-day trial and a 3-week trial, have been through the experience of being a Menlonian prior to making a long-term commitment. Both parties, the company and candidate-employee are in a dating period, gradually increasing inter-personal involvement. The company has about 20-30 developers that work in pairs. The pairs are assigned by a Project Manager. These pairs float between various client projects. This communal handling of client projects by the entire development staff ensures that there are no cool or dull projects. Everybody gets to work on every project. It also leads to dynamic load management to match cash-flow constraints/capabilities of client projects. And of course, there is almost never a case of dependency on a single person to progress through tasks. The pursuit of bringing “joy” in the use of software products is technology agnostic. Their mission makes technology stacks accomplices towards their greater cause and not the ball and chain that anchors developers to lifetime of java. This fluidity in use of ever changing technology stacks is immensely rewarding for programmers’ personal growth and future career prospects.

The Hi-Tech Anthropology® Group is a dedicated group of professionals that are most directly and visibly connected to their greater cause. It is an established practice to go and observe the end-users in their native context. To abstract personas of their typical users, map user workflows and present low-fidelity paper prototypes as options to users and gauge their engagement/joy in use of their yet-to-be-developed product. As one HTA professional shared, in the beginning, they purposefully isolate themselves from the technical feasibility of their designs and prototypes. This freedom keeps the HTA group focused on the user needs. The user only cares what the product does for them, not how it does what it does. Early convergence forced by technical constraints often does a disservice to the exploration of other options that could meet users’ real need: bringing joy in use of the product. For a product the purpose is stable and long-term. The requirements evolve and morph with time and change in the marketplace. But a person with a problem that needs solving always stays steady. Honing on the person’s needs is the single magical stroke of genius that shapes the rest of the practices.

The HTA, after working out possible solutions presents options to the implementation pairs. These pairs estimate their story cards, which then get scheduled and prioritized by their customer. Through many years of iterative improvements they have a current definition of a story card, that captures essential information of customer value, project code, estimate (cost), and additionally relevant notes. While anyone can recommend new story cards, these must make sense to the customer and the value of implementing the story card must be apparent to the customer. The onus of proving the worth of a story card to their customer lies on the person/pair that authors the story card. The project managers liaise between the customer and the implementation team, and also manage other project management essentials such as billing, burn rates and so on. The PM’s are customer advocates and they represent the voice of the customer. Their main method of engagement with the customer and managing customer needs is through a “planning game”, where, based on hourly estimates of story cards, the customer fills in project cards. These project cards represent 40 pair-hours (80 person hours) of total effort. Given the time it takes to participate in their daily scrum, planning and review meetings the pairs estimate for and plan in 32 hours pair-hours per project card. Depending on the expected burnrates the project manager will schedule in as many project cards (pairs) for the next weekly iteration as required. Simple overloaded interfaces is a sign of mature architecture. The project cards not only provide full control of story card scheduling into their customers hands, but also acts as a pair scheduling system. This overloaded behavior of the “planning game” interface accomplishes in one session, that in many other organizations will involve many soul-sucking meetings.

Menlo has turned their factory into a must-see destination for Industrial Tourists. This is perhaps the wave of our times. Wrestling with complexity that advanced technological improvements have forced on us since the Second World War has triggered an avalanche of challenges that our renaissance mind cannot comprehend. This desire to be able to comprehend, to understand, is the single greatest limitation that hinders exploitation of opportunities that are for the taking. For Rich and James, what started as a way to share their pursuit and resultant factory, has turned into a multi-million dollar business opportunity. People like us pay good money to come see the Menlonians at work. Who would have thunk!. There is a “market” of industrial tourists that want to see it to believe it. There is a market for suckers who want to copy practices and patterns and miss the essence of what it is to be comfortable with uncertainty.

A leadership trait that can be best described as a negative-trait, that is in terms of its absence as opposed to its presence, is that of “seeking to understand”. There is a clear lack of any attempt from Rich and James to take control and understand the mechanics of how the people in the company works. There is however the strongest desire to “control outcomes”. This may seem paradoxical, but that does not mean it is not possible. To say it in other words, James and Rich are extremely curious and have strong preferences for “good” outcomes, however there is a matching lack of interest in directing how the outcomes come about. During the day, I witnessed many people reaching out to James, to bounce their ideas off him. There was also one instance when an employee insisted that she had information about a project that James will be “most” interested in. In many organizations management is starving for real information, let alone to be alerted of new and interesting information. How do Menlonian’s know what their founder would be “most” interested in? Is there a Jedi mind trick at play here? I strongly suspect that consistency of moral and ethical leadership by the pair of founders has engendered a feeling or a knack for ‘knowing’ – between people who have worked together to share information of “most” value to each other.

This description of our (agile42) visit to Menlo is my perception of the events that I witnessed. I am certain that there is a lot that my mental models and filters simply could not perceive. Perhaps it was all just a charade! In knowing my limitations and consistency at being wrong. I know that as days and years pass by I will get progressively less wrong. A new revelation always awaits a learning mind. A constant echo in my poor mind will be the operating mantra at Menlo, the Menlo Way: “Simple, measurable, repeatable and visible, structure and a process that focus on human relationships that feed and nurture human energy”

I am very grateful for this site visit, organized by agile42 as part of their annual International Coach Camp.

 

red and black concrete posts

Phase-Gates: Trapped in Wagile (Part 2 of 4)

/by

In previous article, I outlined three fundamental characteristics of waterfall system. Phase-gates are the most distinguishable characteristic of a waterfall organization.

Recap

 Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential phase is gated to ensure quality of deliverables handed-off between silos. Many decisions are concentrated at gating decision points. The Phase-gate approach provides an illusion of control, delaying feedback on product.

For example:

 Requirements → Design → Implementation → Verification → Maintenance

Gates or gating criterion accompany typical phase-gates. Gates establish GO/NO-GO decision points during the process and are intended to: Assert quality of work during each phase so that errors or mistakes are not propagated to downstream phases. Further funding of next sequence of phases is determined based on business context and organization readiness to move forward.

Expected System Behavior:

Fractal Nature:

At portfolio or organization level:
A phased-gated approach is undertaken where in typically a steering committee evaluates an ‘initiative’ or ‘project’ and goes through a serialized process such as:

Discovery → Research Product Concepts → Business Case → Test product Concepts → Gather Requirements and then so on until Maintenance.

At project implementation level:
Same pattern repeats itself where in:

Business Requirements → System Requirements → High Level Architecture → Detail Design → Implementation → Test → User verification → Release.

At task level:
This pattern is not as formally observed as in cases above. However you have probably experienced scenarios where a Developer is “waiting” on approval from Architect before he can check-in OR a case where a team member refuses to implement a well understood feature until the product owner writes down “detailed” acceptance criteria.

Early phases take longer than anticipated and later phases get squeezed. During each phase, work progresses uni-directionally from one phase station to another.

Uni-directional flow of work requires strong emphasis on getting things right the first time. Changes to requirements or design are never ‘welcome’ and always hard-fought.

Product development experiences unpredictable wait-states. Caused due to schedule slippage of predecessor phase and/or due to lack of readiness of subsequent phase.

People get organized in functional silos. Example, Business Analysts silo, Development silo, Testing silo etc. Each silo is lead by its respective manager who is responsible for meeting quality of phase deliverables and responsible for maintaining “busy-ness” of her people.

Unintended Consequences:

Feature filtering:

Phase Gate governance mechanisms concentrate a lot of decisions at gating points. During the early phases of requirements gathering (scoping) many features get filtered out. This is purportedly to limit scope for a release. In other words, business is allowed to be smart to come up with features in a concentrated period of time marked by requirements or product concept phas. All other times their are needs are considered as no good (stupid). This practice leads to selection and elimination of features with out any end user feedback. And also confines understanding of user needs to that time many months ago when steering committee held their “scope” meeting.

As your business context and user needs evolve, so do requirements from a software product. So an idea that may not be appealing at the start may become relevant later. Feature filtering leads to dominance of guess work in selecting features for future product releases. Guess-work that is trapped in stale understanding of user needs. No wonder a majority of features in a typical products never get used.

Local Optimization:

In waterfall systems movement through phases towards the end of the relay race counts as progress. But this perception of false progress at local phase level results in overall portfolio brittleness. During later phases changes in requirements and/or design requested by dependent project teams are aggressively throttled preventing meaningful progress for dependent initiatives.

Degree of influence of dependent teams is inversely proportional to the “progress” made by co-dependent waterfall team. Such systems lead to global sub-optimization at the cost of local optimization.

Root-cause solutions and Resilience:

Late in the development game, technical changes or changes in product requirements are not encouraged. Often deferring these updates to next scheduled release. Instead short-term fixes are implemented. Mindset of getting-it-right the first time often enforced via governance bodies through exhaustive gating criteria creates disproportionate impact from risk-event when the requirements or design or code was not right. Unfortunately in a waterfall mindset such events trigger needs for stricter gating controls, further perpetuating exponential fall out from errors detected in later phases. There is a fundamental misunderstanding of problem domain, within software system development (big or small, green or brown) and attempts to make error proof phase gates and implementing big-brother governance systems will never work. There are known-unkowns and unkown-unkowns. Software products for the most part are exploring in the unkown-unkonwns space. Resilience to errors is far more important than error proof gating systems.

Hidden loopbacks:

When bugs are discovered in testing phase, typically a bug is reported to developers who then have to apply fix. While officially the project is in testing phase, the testers are waiting on developers to apply fix before they can continue further. This hidden loopback drives false perception that downstream phase is taking longer since revisions/corrections to upstream work product is incorporated in downstream phases. 

This perception of “being stuck” in a downstream phase because of issues in upstream work, creates unwanted pressure on downstream folks (testers). Hidden loopbacks not only mask process bottlenecks but also damage relationships between the silos that are pitted against each other.

Innovation Killers:

Phases are innovation killers. Silos and focused functional work straightjackets creativity and rewards bureaucracy. People confined to interaction within their functional community will never learn to work with other functional disciplines. Cross-domain understanding and multi-learning are essential to process and product innovation. We improve in areas where we practice. Your organization needs exercise and practice in working with each other. People will not auto-magically “collaborate”. They need to practice this often, again and again and again (up and down, up and down, painting the fence) until they learn to navigate constructively through conflict.

Summary:

Phases and gates are explicitly and implicitly pervasive in organization mindsets. A serialized cause and effect mental model is comforting but never reflective of how work really happens when you get down to it.

Following process for processes sake is an example of being stupid on purpose. You would be surprised by how many people feel the organizational straight-jackets that you do. Reach out, collaborate, eliminate unnecessary phases and gates. You can iterate on your organizational systems to find your shortest path to project success.

Proceed to part three (Large Batch hands off) or four (Centralized Control).

Trapped in Wagile

/by

Organizations that are attempting to transition to Agile demonstrate waterfall characteristics – residually or resurgently. Understanding these characteristics and learning to observe manifestation of these tendencies in organization systems will help you uncover impediments to your organizations Agile metamorphosis.

After reading this series of articles, you may realize that your organization is still being waterfall but thinks otherwise i.e., Wagile

In this article series I want to explore deeper into the “waterfall” label and lay bare the fundamental characteristics that make up such a system. And subsequently I will dive deeper into each characteristic to highlight expected systemic behaviors and unintended consequences that frankly should no longer be unexpected.

Any software development shop that practices Waterfall, will demonstrate these three fundamental characteristics:

Phased and Gated Approach

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Bera

Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential phase is gated to ensure quality of deliverables handed-off between silos. Many decisions are concentrated at gating decision points. The Phase-gate approach provides an illusion of control, delaying feedback on product.

Waterfall theory vs practice

In theory it is expected that an idea is sound, that it can be analyzed and designed. The developers and testers have to just engineer this into system which will be launched under warm summer sun. In practice(reality) people are not sure whether their idea will the “winner” that they want it to be, analysts and architects are puzzled and pull together a plausible solution. Developers and testers soon realize that the plausible solution is not really possible. So they work late nights to jimmy in one fix after another until the project gets launched too late and for too much. Phased and gated approaches are guaranteed innovation killers.

Large Batch Hand-offs

Champions of a holistic perspective want a detailed understanding of the project. Such understanding drives planning, enables optimization of labor resources, maximizes utilization, and reduces rework.

This paragraph above is more suited to be about a project that uses machines to punch holes in sheet metal. Not about a project that applies human knowledge and skills.

The real challenge is about controlling runaway batch sizes where, despite best intentions organizations attempting to move towards Agile methods are unable to keep and maintain small batch sizes, as a result accumulate work in large batches.

Centralized Control

Complimentary to Phased and Gated, where decisions are concentrated at ‘gates’, with centralized control, decision making authority is also concentrated within selected groups.

Know-how is not know-when. While a central control body may be able to collect all information about the state of a project or portfolio, by the time they get to make sense of this information the situation on the ground has often shifted. Delays built by default into information flows of centralized control organization systems. Only in hindsight  do decision makers know when they should have applied their know-how.

Command and control style management often manifests in organizations that have Centralized Control characteristics. In such organizations, decisions are always made by a select few. Organizational gossip is the primary means of getting real information and management lacks awareness of real problems on the ground. Project effort, “TPS reports” (bureaucratic paper work that adds no value) and tasks make little sense to people doing the work and managers consistently feel ill-informed despite many daily, weekly and monthly status updates. Most feel like a piece in a chess-game. Some carry the illusion of more power than others, but each are equally at mercy of the organization system complexity that plays them.

All waterfall organizations are not the same:

Waterfall as implemented in one organization is different from waterfall implemented in another organization. Think of these three characteristics as primary colors in RGB Color Model.Organizations differ in their waterfall-ish-ness due to differences in their emphasis on one characteristic over the other.

The same RGB model analogy is applicable to individuals – reflective of their mindsets. When enough people share similar mindset (knowingly or unknowingly) self-similar patterns get repeated over and over again. That is to say that these tendencies manifest themselves at all levels, from project funding to project release level to how organizations are structured. To draw your attention to these self-similar patterns at levels within organization work system, I will use examples and highlight these under sub-section ‘fractal nature’.

Summary:

No two waterfall organizations are the same. The three characteristics: Phase & Gate, Large batch and Centralized Control, are emphasized by each organization differently. The degree of emphasis that your organization places on one or more of these characteristics will determine the challenges that it will have to overcome in their agile transformation. In the next series of articles I will dive deeper into each characteristic highlighting the challenges that you should expect. Conversely if you observe the challenges then you can get closer to understanding the legacy mindsets that are impeding your organization’s transformation.

Proceed to the second part Phase-Gates, or jump to part three (Large Batch hands off) or four (Centralized Control).