Tagged: Agile Coaching

Marcus Aurelius on how to implement Scrum

Being an Agile coach I help organizations to improve their way of thinking and working based on Agile mindset, values and principles. Part of that is providing training on Agile and Scrum. I teach participants what Agile values and principles are, what Scrum is and what is is not, so as about Growth mindset, team-based organizations, collaboration, frequent customer feedback and customer value maximization. I usually get the same reaction about Agile and Scrum, especially from people from big companies. Their concerns can be summarized as “it will never work here”:

  • We need a collocated/cross-functional/self-organizing teams so it will not work here
  • We can’t release every Sprint because of regulatory requirements so it will not work here
  • We need a business-person with a lot of decision making power as Product owner but such a person might be a C-level so it will not work here.

It is a pretty common idea that in order to do Scrum (and be agile, broadly speaking) one needs to changes the organization so that it would be a perfectly Agile and its processes 100% compliant with Scrum guide. Who would not like to have all the Agile things in place: co-located team, autonomy and self-organization, continuous deployment, agile budgeting and all the other. The problem with this viewpoint is that it’s often too hard to do so much change at once. So it demotivates and leads to “this will never work here” attitude.

But is it really an all-or-nothing game?

Do we really need to be absolutely, 100% perfect?

I study (and practice) Stoicism, partly because I believe it’s a life philosophy that fits best for me (at least among those that I am aware of). And partly because it is a very practical philosophy, and it helped (and continues to help) me to improve my personal life, family relationships and work. One of the best advice on Scrum adoption (and any changes in general) I got from Marcus Aurelius. He was a Roman Emperor about 2000 years ago and wrote a diary that was later published and became a thought-provoking, guiding and inspiring book for many generations of thinkers. This is what he wrote in book 8 paragraph 32:

You have to assemble your life – action by action. And be satisfied if each one achieves its goal, as far as it can. No one can keep that from happening.
– But there are external obstacles…
Not to behaving with justice, self-control and good sense.
– Well, but perhaps to some more concrete action.
But if you accept the obstacle and work with what you’re given, an alternative will present itself – another piece of what you’re trying to assemble. Action by action.

This is an approach to organizational change that I believe in. You need to know what your vision is. For Scrum, the vision that you are aiming at is described in the Scrum Guide. Once you define your vision, the best is to aim at some possible step toward that vision. You take a step – the one that is possible. Then you observe. Probably you will open some new opportunities for action. Align yourself with your vision, and take the next step – the one that is possible with what you have. Repeat. Over and over. Action by action. Make a change. One step at a time. Inspect and adapt. What is important is to keep moving.

You don’t release every sprint? But you reduced release cycle from 18 month to 4. You don’t have a cross-functional team? But your testers started to talk with developers rather than just sending each other documentation. Your team is not 100% self-organized? But you agreed with your manager on some areas that your team has full authority rather than asking him for every smallest decision. So people say that you are not doing Scrum? The goal is not to “do Scrum” per se but to maximize value. Keep the Scrum guide in mind and keep moving.

You might never get to the ideal, but what is cool in the idea of continuous improvement – there is always something that you can make a bit better. So master the art of possible, and change for good. Action by action.

Remember the ignorance

I recently had a very interesting conversation with Steve Porter from Scrum.org. We discussed a Scrum team where developers are not pulling their work themselves. Instead,  it’s a senior developer who, during the Daily Scrum, selects which Product Backlog items will be worked on that day and who will work on them. This senior developer is a well-respected member of the Development Team. So the question was, should a Scrum Master do anything about it?

On one hand, Scrum guide does not explicitly require members of Development Team to pull their work on their own. Scrum Guide also states “no one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality”. So it looks like Development team is doing Scrum, and there is no need for Scrum master to intervene. However, there could be many possible reasons why this situation may require an intervention from Scrum Master. Here are two: the definition of Development team and Scrum Values.

Firstly, this situation may contradict the definition of Development team in Scrum guide. The Scrum guide does not describe Development Group. Rather Scrum team has a Development Team. I believe that the word “team” was used intentionally and one of the main reasons why Scrum is so effective is that it is based on “a team” rather than “a group”. By definition a team is “a group а people who share a common team purpose and a number of challenging goals; members of the team are mutually committed to the goals and to each other”. In Scrum context, we can consider delivering potentially releasable Increment as Development Team’s purpose, and Sprint Backlog as a set of challenging goals. But it’s hard to be committed to something that you did not take voluntarily. On the contrary, a situation when someone assigns a person work makes this person less committed to accomplishing this work. A commitment is one’s responsibility, but if one does not make a decision, he or she will not take responsibility for that decision. The best you can get in such a situation is an obligation, but not ownership. So by assigning Sprint Backlog items to Development Team members, a senior developer destroy a team’s ability to be a team. This situation might also violate the Development team equality principle: “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person”. But here it might be that “all developers are equal, but some developers are more equal than another”.

Secondly, this situation seems to contradict the Scrum values. We’ll start by a quote from Scrum Guide: “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” I have already described above how this approach can destroy the team’s ability for commitment. People do not personally commit to achieving the goals of the Scrum Team. This situation may also be a sign of lack of respect. Scrum guide defines respect such that “Scrum Team members respect each other to be capable, independent people.” But a situation when someone defines what piece of work one should do a given day is far from treating that person as a capable and independent (not to speak about showing respect). This rather may be a demonstration of a lack of trust in one’s capability. Such a situation is very toxic for team morale and performance.

Thinking all that I concluded that that team is not doing Scrum and Scrum Master should intervene by raising team’s awareness of what is going on an how this influences a team. Being pretty confident in my conclusion, I shared that with Steve, and his reply was: “be careful not to make judgments about how a Development Team decide to work. If you see behavior that you don’t understand or feel could be improved, approach the situation from a position of curiosity. Remember, the people closest to the work are in the best position to decide what’s right and wrong.” I thought to myself: “Man, you were the one speaking about beginner’s mind and importance of context, and you’ve run to the very mistake that you were teaching to avoid!” Working for a long time for big companies, I was literally paid to have the answers. At some point in time, I realized that my success was due to asking questions, and helping my team to find the best possible answer, rather than bringing with my solutions. That was the reason why I started to learn about Agile, Scrum, self-organization, team, etc. In general, that is why I do not stop learning things. And that is what I am teaching others. “Remember the ignorance” – that was my advice for my students. And now I failed to live up to my own advice. That was really sobering!

When working with people things are rarely are the way they look at the surface. Every situation, every problem is very context-specific, so you can have different solutions for two (seemingly) similar questions of the same person – because these two questions sit in a different context. So just looking at the surface is not enough even if things look obvious, because there is a good chance that they are not. It is very rewarding to act “like a smart guy” and have a clear answer to any question. Being an expert. As Mike Maddoc writes in Forbes blogpost “As experts, we get paid more, trusted more and sometimes even honored more. Our parents are proud, our partners are proud and sometimes even our kids think we’re cool.” That leads to a very straightforward thinking. We know too much and forget Socrates lesson that we know nothing. And that leads to wrong decisions, sometimes with bad consequences, sometimes with catastrophic ones.

And I do not want to be that kind of person.

I want to avoid an expert trap. I choose to have less confidence in what’s best, choose to be curious, ask questions and be open to learning the answers, and by doing that to be able to co-create a better solution in collaboration with people involved. I will ask myself “What else is there? What am I missing? What could lead me to an opposite conclusion?” So I wrote a mantra on a card that I have now in my wallet, and I re-read it several times a day.

REMEMBER
       THE
         IGNORANCE.

Using Cognitive Conceptualization Diagram in Organizational Transformations

What I want to emphasize before digging deeper is the fact that in order to use tools and techniques form psychology, one must first understand oneself and sort oneself out. As Jordan B. Peterson says, set you house in perfect order before criticizing the word. This will probably require a lot of work and will take time, but it is a necessary precondition to successful usage of those tools. Otherwise there is high probability that instead of looking into person’s psychi you will fight your own dragons. So tools I am going to discuss in that post are not some quick fixes. But I hope those tools can help us move forward in complex situations. After all, as Agile coaches we are aiming to change organizational culture and peoples mindsets, so psychology seems to be a good thing to start with.

We know that one of the possible sources of resistance to change is some unconscious reactions. But how we can deal with them? And, to be more precise, how we can make sense on what is the source of that resistance, so that we could address it more specifically?

In this post I want do discuss some of the tools of Cognitive Behavioral Therapy (CBT). Let’s start with some basics of CBT.

The core concept of CBT is a cognitive model. According to that model a person’s reaction (emotional, behavioral and physical) to a given situation is not a product of that situation as is. Rather the reaction is based on some automatic thoughts that a person have in a given situation. 

Let’s consider an example, when Agile coach proposes to use Kanban to visualize and manage workflow, there might be different reactions:

  • Developer A thinks that it would be cool to draw a Kanban and use it to collaborate with others, so he says “Cool! Let’s do this”.
  • Developer B might think that they have already tried to do Kanban, nobody was actually updating Kanban board, and they ended up having a board showing a months-old picture so that they eventually abandoned it, so he says that it will be a waste of time.
  • Developer C might think that everyone will see how little work he is doing, so he becomes defensive and says that he will not do it, cause it’s too much unnecessary work – writing tasks down and moving those cards and etc.

In the latter case, it is not necessary that Developer B is an underperformer – he could possibly be a top performer of the team, but his perception is that he does less than he should do. That is quite a common case that is called “the impostor syndrome”. So we have the same situation, but different reactions.

The extended cognitive model has three additional layers: core beliefs, intermediate beliefs (latter can take form of assumptions, rules or attitudes) and coping strategies. In our example, developer С might have a core belief “I am incompetent”, and have attitude “It’s terrible to look incompetent”. He has assumption “if no one knows what I am doing, no one will know that I am incompetent”. And he might have a rule like “If I will hide my real amount of work, everyone will think that I am smart, If i will disclose real amount of work, everyone will think that I am incompetent”.

It could be the case that one automatic thought or emotional or physical reaction triggers another automatic thought, creating a cascade of cognitive processes and reactions. For our purposes we will use this simplified model.

By understanding a cognitive model, one can analyze person’s cognitions and work towards changing those parts of cognitive model that are dysfunctional. People often unaware of their core and intermediate beliefs, while they might know some of their automatic thought – it depends on situation and a person’s self-awareness. Key point here is that these thoughts are usually taken by a person without any doubts.

In CBT a therapist can help both in conceptualizing that model and help in finding ways to improve that model by changing dysfunctional cognitions to more functional or at least neutral.

An Agile coach might also use that cognitive model to help a person accept changes. In the example above a coach might help developer to discover that he is actually a top performer, and by visualizing his work he could help himself (so as other team members) see his actual impact on team’s performance. But how a coach might learn how a particular person’s cognitive model works? Here comes a Cognitive Conceptualization Diagram (CCD).

As you can see CCD has two parts. Bottom one is about specific situations, automatic thoughts and reactions – we might consider this an outer layer, and top is about deeper layers – previous experiences, core beliefs and intermediate beliefs. We could use this diagram to hypothesize about one’s cognitive model, so that we could plan experiments to test our hypothesis.

First, you observe the situation-reaction patterns and fill in the bottom part. It is a good idea to look for different situations, e.g. interactions with team members in formal meetings, interactions with other colleagues during informal conversations, etc. It is important to make sure that those behavioral patterns are common for that person. By doing this you fill in boxes 1, 2 and 3. You hypothesize on automatic thoughts that can cause such a reaction to a given situation, filling box 4. After gathering at least three situations, you can create hypothesis about meaning of automatic thoughts (box 5). Based on that you may hypothesize what core beliefs (6) could lead to assumptions (7) and coping/compensatory strategies (8) that create such automatic thoughts. During a therapy process, a therapist would probably also look at childhood experiences that could create such assumptions, but as organizational change agents we probably will not dig so deep.

It is important to mention that in order to fill this diagram a coach have to spend some time with that person observing his behavior and looking for some patterns.

Having a (partially) filled CCD, therapist might try to validate the hypotheses it is based upon. He can do it by asking questions, and by observing some behavioral and thought patterns. Here comes a tricky part: In therapy, if he will try to discuss his ideas on core beliefs and intermediate beliefs too fast, when a client is not ready, client might resist and this could potentially destroy therapeutic relationships. As people do not expect any therapy from Agile coach, trying to discuss core beliefs will highly probably destroy coaching relationships. However, Agile coach don’t need to go that deep. He can focus on automatic thoughts and in many cases changing (or even making a person aware of) automatic thoughts is enough to start some changes. We could work deeper (if we have both expertize and client’s willingness to do so) – such interventions are outside of this discussion post.

In case of Developer С this diagram might look like this.

 

Black text represents overt things and blue – hypotheses.

Now a coach can make predictions and run some behavioral experiments based on this model to assess if these hypotheses are true or false (and update this model based on experiments results).

I will dig deeper onto behavioral experiments in one of my next posts. Here I would like to discuss what should we start with. Firstly, we need to master an unconditional positive regard an unconditional acceptance. Whatever a person thinks – it’s OK. We can disagree with that, but we accept it as it people without judgement. Why it is important? As I already stated in my previous post, if a person will see a signs of disapproval, that mere fact might (and almost surely will) switch him to a defensive mode. This will worsen our relationship, probably cause an aggression and make a person blind to whatever we want to offer.

Secondly, after we accepted person as is we can bring awareness to whatever there are. Such non-judgmental mirroring will raise person’s awareness of his thoughts, and it’s a necessary step towards changing them.

As soon as a person becomes aware of his or her thoughts, we can move to the next step – help him to rationally analyze those thoughts, their probable outcomes (both positive and negative), and helping a person design some behavioral experiments that could test the assumptions about outcomes. This could be done using socrative questioning, or other techniques. I will dig deeper into that in one of my next posts.

In the end of this post, I would like to focus once again on the importance of self-awareness and self-acceptance of a coach. Strait yourself out before trying to change others. And before any king of intervention remember the Hippocrates imperative: primum non nocere.

Firstly, do no harm.

 

When Shadow covers Agile

In my previous post I described how personal Shadow of a manager can inhibit Agile transformation in organization (though I didn’t use the word “Shadow”). Here I would like to discuss Shadow in organizational context and explore how it influences outcomes of Agile transformation. In one of my next posts, I will focus on particular tools and techniques to work with Shadow and assimilate it.
Introduced by C.G. Jung, the idea of Shadow includes a constellation of personal traits repressed and superseded into unconscious as undesirable or unacceptable to one’s conscientiousness. Shadow is a hidden energy that have a great influence on person’s behavior. On the one hand, repression of emotion, feeling or aspiration requires a huge amount of energy, thus, as Jolande Jacobi writes in “The psychology of C. J. Jung”: “spiritual and moral tower [person] live in is not a natural growth but an artificial scaffolding erected and sustained by force, hence in danger of collapsing under the slightest weight”. This can take a form of a sudden and inexplicable rage of someone who consider herself reasonable and calm. On the other hand, Shadow express itself in projections of our unconscious images on others; by doing this we morally whitewash ourselves, but this affects our relationship with others.
Shadow exists not only on individual level, but also on collective level, so we have not only personal Shadow, but also Collective Shadow, that plays role in interpersonal and inter-group relationships. R. B. Denhardt in his book “In the Shadow of Organization” used the Shadow concept to describe problems of the same kind as described above, that we can see on organizational level. As a result of the fact that management shows preferences toward particular values, managerial practices and attitudes, the Organization Shadow emerges, manifesting itself on the way organization perceives others and itself.
Emergence of a Shadow itself is inevitable byproduct of the formation of an individual or organization. In order to act one have to decide on the course of actions, so some actions become preferable and others are not; we do this under influence our goals, values and the constraints set up by others (family, friends, and society). In an organization, managers create a Shadow by preferring specific values, practices and energies. That Shadow manifests itself in how the work is organized, how the business strategy is defined, and in structure of an organization itself.
For example, an organization that supersedes its desire to suppress dissent creates Organization Shadow that will manifest itself in two ways. First, by projection of this desire on other organizations and individuals (with or without any evidence supporting this). Second, by unreasonable and unpredictable outbreaks of dictatorship within organization. We can see such example in a story of ITT corporation described by Antony Sampson in “The sovereign state: the secret history of International Telephone and Telegraph”. A company, that was a conglomerate of omnipotent control, where everyone was obsessed by creating profits, used “freedom is dying everywhere” rhetoric to justify its unethical behavior, from bribery to undermining of democratically elected government in Chile (in tandem with the CIA). A company that suppressed freedom both inside itself and in countries where it worked positioned itself as a freedom fighter.
Organization Shadow is created in entangled interplay of all its members. To see how it can work let’s take an example of manager – subordinate relationships. Imagine a manager that craves power, but suppresses this desire as unethical, superseding it in his Personal Shadow. Then he can project weakness and immaturity on his subordinates, and by doing so, he justifies his authoritarian actions. Subordinates, carrying this projection, can become dependent and unenterprising (Pygmalion effect), superseding their desire for autonomy in their personal Shadow. In this manner, Organization Shadow emerges, nourished by all its members.
Shadow cannot be removed without destruction of personality (or organization), but it can be explored and assimilated. Assimilation of the Shadow makes an individual more psychologically balanced. It allows a person to control assimilated aspects of his or her Shadow (or prepare countermeasures in case this aspects will go out of control). One can also deliberately chose to reveal such Shadow aspects in situations that require this kind of behavior. Shadow assimilation requires hard work, and often is a painful process. It is complicated by the fact that Shadow is a part of unconscious, so person is unaware of it by definition. One can focus on manifestations of a Shadow (e.g. projections), but it is often not clear what part of the Shadow creates this manifestations.
Assimilation of Organization Shadow is even more complicated, because it can be done only on individual level; an individual have to take responsibility for both Personal Shadow and Collective Shadow. This requires a lot of reflection, and that can be especially difficult in an organization that is focused on action. It also requires courage, because assimilation of shadow solves problems, but create new problems of a different kind. C. G. Jung in “The structure and dynamics of the psyche” writes: “If you imagine someone who is brave enough to withdraw all these projections then you get an individual who is conscious of a considerable Shadow. Such a man has saddled himself with new problems and conflicts. He has become a serious problem to himself, as he is unable to say that they do this, or that they are wrong and they must be fought against…. Such a man knows that whatever is wrong in the world is in himself and if he only learns to deal with his own Shadow, he has done something real for the world. He has succeeded in shouldering at least an infinitesimal part of the gigantic, unsolved social problems of our day.”
As assimilation of a Personal Shadow requires restructuring of one’s personality, assimilation of Organization Shadow will require restructuring of an organization; that can lead to resistance from those who are influenced by these changes. It’s also the case that members of organization that are not ready to assimilate Organization Shadow (and their Personal Shadow) will resist and suffer from this new view on themselves and their organization.
However, this assimilation is beneficial to organization. First, we can be sure that any organizational changes will work to rectify real inadequacies rather than are focused on projections. Second, as with Personal Shadow, as soon as we are aware of all aspects of organization “personality” we can control of plan countermeasures for those aspects that are destructive or impede organization from reaching its goals. Alternatively, we can use those aspects in situations that demand such behavior. Third, it will create uncontroversial (or at least less controversial) culture, so members of organization will less suffer from stress caused by inconsistency between what is stated and what is acted out.
So what all of these has to do with Agile? Agile transformations (as any organizational change) are aimed to solve some problems. But if organization and its managers are blind to themselves, any attempt to solve those problems is neither valid nor carries any possibility so solve this problem. If you are aiming to change an illusion, you will get an illusion of change. In best case, it could change some parts of a problem, but create a dozen of new ones. (I am not talking about rare cases in which organization already is “almost Agile”. In such cases Agile transformation obviously work perfectly well.) This puts a responsibility to confront Shadow on managers as people who define organizational actions. (This puts even higher responsibility to confront and assimilate Personal Shadow on people who will lead such transformation, e.g. Agile Coaches.)
To inform organization of its Shadow side one could employ metaphors, rituals and stories. A number of researchers point to metaphorical analysis as an important tool for revealing the social reality of organizational life, allowing to see organization form different perspectives. This however has some limitations; M. Bowles in his paper “Recognizing deep structures in organizations” states that “… metaphorical analysis, whilst a potentially powerful tool for assisting managers in explaining deep structures, requires a maturity often not realized.” To overcome such limitations managers can refer for help to Agile Coach (assuming that someone claiming to be an Agile Coach is mature enough and successfully worked to assimilate his or her Personal Shadow).
Confronting a Shadow is a first step towards self-knowledge both on individual and organizational levels. Next step is accepting the Shadow, and this step is even more demanding. Even on an individual level, facing the Shadow can be painful enough to force individual to retreat back to the shelter of illusions. Integration of an Organization Shadow can be infinitely more difficult job. But without doing so any organizational change is focused on illusions rather than reality, so it will not reach its goals. Therefore moving towards assimilation of Organization Shadow becomes crucial part on Agile transformation for managers and for organization as a whole.

What Agile Coach Can Learn from Psychologist

I’ve been recently thinking about popular Agile frameworks and approaches to Agile transformation. It seems to me that they are too mechanistic, and this seems to me one of the reasons why many of transformations fail. In my previous post I wrote about situations when changes cause too much pain in organiation, and this lead to rejection of new processes (or mutation of them into some cargo cult).

A successful Agile transformation implies changing of culture, mindset and behavioral patterns. Psychology addressed the same problem (with a different goals and conditions) for quite long time, so it probably has some things that we could adapt for transformational purposes.

In his book “Counseling and Psychotherapy: Newer Concepts in Practice”, Carl Rogers (on of the most influential psychologists of 20th century) provides a set of questions that a counselor should consider working with client that play key role in selection of appropriate treatment. With a slight adaptation this questions can be used in context of Agile transformation to determine approach to change.

Is client under stress?
“One of the first observations which the wise clinician will make is the extent to which the client is in a state of tension or stress.” – Rogers writes,- “Counseling can be of help only when there is a certain amount of psychological distress arising out of a condition of disequilibrium.”

Dose this applicable for transformation? Definitely yes. If people in organization are satisfied with the way things are, change perceived as some undesirable disturbance. This will create a very strong resistance to change, making it almost impossible. But if people feel that things are not as they want then to be, if they feel that something has to be done differently – such king of stress can provide enough pain that will justify stress from change itself. “Basically the most accurate statement of this situation would seem to be that, before counseling can be effective, the tensions created by these conflicting desires and demands must be more painful to the individual than the pain and stress of finding a solution to the conflict.” That is why management scholars and smart executives emphasize importance of cultivation of sense of urgency and dissatisfaction when starting a change. Dissatisfaction and urgency create stress needed to justify (of even make desirable) pain of change.

Is the Client Able to Cope with His Situation?
“It is sometimes forgotten that any type of psychotherapy depends for its results on the assumption that if the individual is helped to reorient himself, to reorganize his attitudes in new patterns, he can meet his life adjustments more normally and with less strain, and can find healthy satisfactions in a socially approved manner.”

This question is very important for to Agile transformation. If the organization you’re helping to transform is unable to cope with new ways of working, it cannot transform. Imagine a team that customizes software developed by large company. 98% of their customizations depend on some updates from company. Software manufacturer deliver this updates twice a year in large batches. So the team spends most of their time in idle state, awaiting for new update. Cat this team get benefits from implementing small batch release policy with 2 weeks iterations? Maybe, but most of iterations will be idle (with zero releases). So such a changes will lead to frustration of team members, and will not create any benefits nor for the team, neither for a customer. Other example could be a component team working in a plan-driven environment doing Scrum. Of course they could get some benefits from improved collaboration and frequent planning. but this benefits will be limited by the fact that they have too much external dependencies to deliver every Sprint. In this case Scrum will probably bring too much overhead compared to benefits.

Can the Client Take Help?
“Another basic question which the counselor must ask is frequently phrased, “Does the individual want help?” 

Consider a situation when a top management decides that “we all need to be more Agile”, and prescribes all departments to implement Scrum ASAP. You are invited to help with this transformation within a department. But that department fells no need to change. They are fine with how things are and do not want to change anything. Or, feeling threatened by the change, team members do not want to talk about their problems. This issue, if not addressed properly, could lead to all sorts of dysfunctions and eventually failure of transformation.

Is the Client Independent of Family Control?
“Still another question which the counselor will need to consider in planning the focus of therapeutic work, particularly with the child or adolescent, is the nature of the client’s tie to his family.”

According to Rogers, “effective psychotherapy with a youngster usually involves treatment of the parent also, in order that the parent and child may jointly make those changes which will improve adjustment.” This may look odd, but replace “family” with “management” – and it will makeу sense. There are a lot of similarities between child-parent and employee-manager relationships. Consider a manager, inviting Agile Coach so that he “change all his teams to be more self-organized” and bringing exact step-by-step plan of how they should self-organize. “Change them, I am OK” is a wide spread attitude among command-and-control managers trying to increase organization’s agility. This question is to be considered regarding CEO-investor relationships – I have seen a company whose CEO was trying to make company more focused, reducing WIP projects to a handful, but the investor brought new “do-it-now-it’s-urgent” projects every couple of months, making CEOs efforts meaningless.

Is the Client of Suitable Age, Intelligence, and Stability?
“Although our information is meager, there is reason to suppose that counseling is a more appropriate and successful procedure with certain age levels and certain intelligence levels than with others.”

Information on correlation between this factors and Agile transformations of even more meager, nevertheless this question should be considered. While intelligence is (hopefully) not a problem in corporate environment, stability and age can play their role. If a team of some team members are overstressed to the point of emotional instability, they can react to change in unpredictable way, so they probably will need additional attention form Agile Coach. Same with the age – it can be challenging for a person with several decades of (relatively) successful waterfall delivery to adopt Agile Mindset.

(At least) increase you chances for success

Although none of this factors seems to be an insurmountable obstacle for Agile transformation, they all can have strong impact of effectiveness of a given transformational approach. Paying attention to those factors does not guarantee successful transformation (while inattention probably guarantees failure) but will increase the probability for success.

Why Scrum does not work (and what can we do about it)

Scrum is the most popular agile framework. Period. If we look at VersionOne 11th State of Agile report, Scrum is praciced by 58% of respondents (68% if we summ up Scrum and Scrum/XP hybrid). Among scaling frameworks Scrum although dominate: while Scrum-of-Scrums has 27% (1% less than Scaled Agile Framework), Scrum-of-Scrums, LeSS and Nexus combined have 31%. I believe that there are two main reasons for such popularity. First, Scrum is simple to understand and comes with a clear recipe – Scrum Guide. Second – it works by helping team to succeed in value-driven agile delivery.

So it looks like within a first paragraph I have reached the conclusion that contradicts my initial claim made in post heading. Well, no. Scrum really works – but only if you succeed in its adoption. I do believe that Scrum is extremely powerful, and its power emerges out of tight interconnection of Scrum roles, artifacts and practices. Its holistic nature emphasized in Scrum Guide itself: “Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.” This means that the one and only way of getting full benefits of Scrum is literally follow the Scrum Guide. This does not mean that you cannot get at least some benefits from using part of Scrum (often referred as “Scrum, But”), but a) one should not call this thing “Scrum, and b) actual results are highly unpredictable.

Why would you want to implement ScrumBut? Well, assuming that you are not ignorant, the main reason would be “It contradicts our organizations culture.” Among main challenges of Agile adoption “Company philosophy or culture at odds with core agile values” is at the top (and rising) for at least 6 years with 63% last year. So in Agile (and Scrum) adoption key question is “How can we change organizational culture so that it will embrace (or at least will not contradict) Agile values and principles.” One possible answer to that question is known as  Larman’s 5th Law of Organizational Behavior: “Culture follows structure.” If you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. Make people act differently, they will adapt their mindset so that this new way of doing things will be aligned with their way of thinking about their actions. This is what Scrum does (when fully implemented) – it creates a structure that forces organization to become Agile.

I believe that Scrum works exactly like that – not only changing the way of doing, but changing mindset and belief system of people involved. But (and it’s a big butt!) putting people in new environment with new rules is painful1, so as changing one’s mindset. And when choosing is between two painful paths, people tend to pick the one that associated will less pain. Or at least the one that they think will bring less pain. 2.

This leads us to understanding a key reason for Scrum failure: it just requires too much change (and too much pain) to do the Scrum. If an organization’s culture is close enough to Agile, implementng Scrum works is like magic: it will add necessary tension that will force cultural changes, leading to success of Scrum adoption and Agile transformation. But as soon as the distance between organizational culture and Agile becomes too big, enforcement of Scrum framework does the opposite. Now it’s not just structure vs culture, it’s structure vs culture and pain aversion combined. And we all know how much energy people can direct on pain aversion. So Scrum is doomed to fail, and there are basically two ways how events can unfold after that. One is stepping back to what is, claimimg that “Scrum (and Agile) does not fit our company”. The other is changing Scrum so that it won’t bring so much tension (and pain). The latter leads to all sorts of “ScrumBut”s and Cargo Cults, and in best case will lead to frustration, irritation and unproductive behavior (and in worst case it can lead organization to total disaster).

So Scrum does not work when forced on organization with poorly compatible culture. Does this imply that Scrum is bad? No. But what it does imply is that literally following Scrum Guide is not suitable for every organization, and Scrum Master has to carefully think out a way of Implementing Scrum. This could possibly mean that we do not do Scrum from the very beginning, and trying to gradually approximate our structure to Scrum, and avoiding “get it right from the first time” attitude.

This is a first of a series of posts on my perception Agile coaching, it’s challenges and faults. By no means I’m claiming that I have all the answers. Rather, I hope that by writing this (and by reflecting on your feedback) I could think through this and maybe find some plausible answer on the main question of agile coach: How to help an organization make it’s way through successfull Agile tansformation. In next post I will consider some of the questions that a Change Leader should consider designing a plan for Agile transformation.