Author: admin

Blog

Applying SOHP framework for organizational change

One of the common question raised by beginner Scrum Masters and Agile Coaches is how to structure the interactions with team or organization they are working with. One of the feasible answers to this question I borrowed from medical frameworks.

 

SOAP framework in a part of problem-oriented medical record approach that was suggested by developed by Lawrence Weed, MD in 1970s. It is used during initial assessment or subsequent visits to gather and capture relative information. It contains four components: Subjective, Objective, Assessment and Plan. While gathering data clinician covers this four areas:

  • Subjective data. Clinician gather data on how patient assess his or her own status, history of symptoms, etc. There are seneval mnemonics that help to structure this part of assessment, for example OLDCHARTS, that includes Onset, Location, Duration, Character, Aggravating / Alleviating Factors, Radiation, Timing and Severity.
  • Objective data. This includes information that the healthcare provider observes or measures from the patient’s current presentation, e.g. vital data, instrumental tests (MRI, x-ray etc.) and findings from physical observation etc.
  • Assessment. More and more often this one is replaced with “Hypothesis” (changing mnemonic to SOHP; this was proposed by clinical psychologist Barbara Lichner Ingram), but the main idea is pretty much the same – it is a summary of symptoms and diagnosis (including differential diagnosis and other possible diagnosis) and reasoning behind that diagnosis.
  • Plan. In this section clinician describes treatment plan: follow-up procedures, additional labs etc.

 

This approach has also some downsides. Some critics suppose that it encourages sequential analysis of the problem instead of an integrative approach, and focuses more on data collection than on evaluation and analysis itself. However, this approach has proved to be very successful in providing a structure that helps doctors record their notes about patients, and view those notes subsequently in a manner that quickly gives them a good understanding of that patients history.

 

It is important to notice that SOAP/SOHP describes not the whole process of clinician-patient interactions – it is imbedded in a general session structure that is adjusted for each session. Key thing is to start each action, including data gathering, by providing explanation of what a clinician is going to do, justifications for this particular action and getting consent from patient. Above the informed consent required by law in most countries, this helps to manage expectations and create trust between clinician and patient that usually improves therapy results.

 

With some adaptations this framework can be helpful to work with organizational transformation, especially for initial interview and change planning. I start the session by explaining how our session will be structured (describing SOHP framework and why do I need all this information), ask for consent and then structure out session based on modified SOHP framework:

  • Subjective data. Here I am trying to gather maximum data on how client sees their problem and what they expect from our collaboration. I use an extended version of OLDCHARTS: OLDCHARTERS: Onset, Location, Duration, Character, Aggravating / Alleviating factors, Radiation, Timing, Expectations, Results at success/failure and Severity. To clarify subjective view I use the following questions:
    • What can I do for you? (I use an open question and provide enough space for a client to talk about their problems to get as much information as possible. I can also ask “What else?” to dig deeper.)
    • How long does this problem exist? Have you had any similar problems? If yes, what have you tried to improve the situation? (Onset / Duration)
    • How severe this problem is? Does it disrupts organizational activities? What metaphor would you use to describe this problem? How would you rate a severity of this problem on a scale from 1 to 10? (Severity/Character)
    • Does this problem persist in a specific part of organization or it influences the whole organization? Who problem localization changed over time? (Location/Radiation)
    • What have you tried to do to mitigate this problem? How that influenced the problem? (Aggravating/Alleviating factors)
    • Does this problem gets better, worse or does not change with time? If there are changes, what is the pace of change? (Timing/Duration)
    • Are there any other related problems? (This question helps to identify problems that client think of as a separate problem, but they can be related to main issue).
    • What do you think causes a problem? What do you worry about in relation to this problem? (This questions can help to identify client’s assumptions about the problem and what they believe this problem might lead to).
    • Why now? What have changed compared to how this problem usually reveals itself? (This might reveal that the problem got worse recently, or client’s perception of the problem changed. Latter often happens as a result of a client went to a training of learned about changes happening in other organization).
    • What you expect from me? What are your assumptions on what I would be doing? What are your assumptions about what I would not do?
    • How would you know that the changes will be a success? What would you see in your organization 6 months (year, three years etc.) after today  if we could improve the problem? (This question helps me to identify how client defines success and assess whether client’s expectations are realistic)
    • How would you know that the changes will be a failure? What would you see in your organization 6 months (year, three years etc.) after today if our efforts will lead to failure? (This question helps me to identify how client defines failure and reveal possible scenarios that could worsen the situation)
  • Objective data. Here I gather all available metrics that are relative to the problem. This data can be helpful to assess the effects of the change. Руку I also gather the results of my observations, qualitative and quantitative assessment of organization. Here I also can propose to gather some additional metrics that can be helpful in assessing the effects of our work.
  • Hypothesis. Next step will be to create a hypothesis about problem causes and provide a justification of my view. I also describe how caт I confirm or disprove the hypothesis and what experiments I will run and what results I would expect as confirmation of disprove.
  • Plan. This is where I describe a plan of  organizational change experiments based on the above.

During interview with a client I don’t use the exact sequence and wording of the questions described above. Rather I use this as a framework, that guides the emerging discussion with a client. I also adjust the wording to fit a particular client: of example some clients avoid using the term “problem” speaking about what is going on in their organization. for such clients I use “situation” or “specificities”.

Here is an example of SOHP record made after initial interview with a head of IT department (in order to keep confidentiality this example based on a mixture of several real clients)

Context:

A team of 5 (3 developers and 2 testers) working on a new product for a big organization using Scrum framework. Team reports to head of IT department.

Subjective:

Team includes employees from a larger IT project, that had several teams developing a big internal application. Previous project used Scrum framework, but was unable to deliver any working product for a long time, so business lost their interest in it and it was cancelled. New team works on a completely new application that is considered a strategic priority and several C-level executives have stakes in it. Team Scrum Master learnet about Scrum on his own, but noone on the team had a training on Scrum. Scrum Master asked head of IT department to invite an Agile Coach to make sure that the team does not make any significant mistakes applying Scrum that might lead to a troubles with the team of with the product.  I expect you to observe their daily interactions anв Scrum events, review team’s artifacts and provide recommendations on what and how they could improve to increase probability of successful product delivery according to client’s expectations. i will consider coaching a success if Scrum Master and key stakeholder will consider your recommendations helpful to improve their collaboration. Ideally a team will deliver something that stakeholder could use to provide feedback within the following 4 weeks.

Objective:

Team has all elements of Scrum framework in place. Currently team run 2 two-week prints, but have not delivered any working Increment. Product vision is not defined explicitly while team members can describe in general terms the product that they are building. Product Backlog has 12 items in it defined as User Stories, but no item has Acceptance Criteria defined. Product Owner is a representative of a business department, communicating the expectations of the head of the department (key stakeholder). Product Owner can not identify with confidence the most valuable Backlog items. Team is distributed: Development Team and Scrum Master are located in a single room, Product Owner and key stakeholder located in a separate building in another district. Currently no metrics are gathered except team Velocity (in Story Points). During the first two Sprints team delivered about 50% of what was in the Sprint Backlog.

Hypothesis:

Misalignment and poor communications between Development Team and key stakeholder as a result of a dysfunctional Product Owner (“a ferry”) that has no authority nor clear vision. Because of that Product Owner has to approve all his inputs with the key stakeholder so decision making speed is very low. No explicit product vision prevents Development Team from making decisions based on key stakeholder expectations. Sprint Review does not serve it’s main purpose – to gather feedback from stakeholders because the latter are not present. To test this hypothesis I would compare the product vision presented by key stakeholder, and by members of Scrum Team.

Plan:

  • Run a workshop to define product vision and refine Product Backlog with Scrum Team and key stakeholder involved.
  • Recommend to invite key stakeholder on Sprint Reviews.
  • Observe Scrum events and coach Scrum Master on how to improve the events.
  • Personal coaching of Scrum Master.
Blog

Satisfaction from working in Agile and Big five personality traits

Last (2018) year I published a questionnaire in several Agile-related Facebook-groups (Scrum Russia, Enterprise Agile Russia, Large-Scale Scrum (LeSS): на русском, Agile вне IT / Business Agility Russia и Kanban.club (Scrum-friendly)) I wanted to see how personality traits (Big five) relate to personal satisfaction from working in Agile team.
My hypothesis was that satisfaction with Agile will correlate positively with two traits: conscientiousness and openness. The data that I collected (N=99) shows no correlation between satisfaction with Agile and any Big five trait. To be precise there is a slight correlation, but it is not statistically significant. There was only one trait that had some statistical significance, while too small to claim that I found “an elixir of happy Agile team”). It is conscientiousness. But even for that trait both correlation and significance are very low. By the way this is a trait that servers as a best predictor (together with IQ) of overall job performance.
What conclusions could I make with existing data?
Firstly, correlation is not causation. Maybe people high in conscientiousness can better perform in Agile team while seeing the results and the impact that they make. Maybe having highly conscientious people makes Agile “special” so it makes team members more satisfied. Or maybe there is some other factor that relates both on conscientiousness and satisfaction with Agile. Or it is just come randomness of the data that I have.
 And secondly, even though my hypothesis was not confirmed, I believe it is a good news. Even taking into account that I have a distorted data (all participants were interested in Agile as members of Agile-related groups). It is a good news because the data demonstrates that you don not need to have some special trait or set of traits in order to be satisfied working in Agile environment. This does not mean that there is no combination of traits that will inevitably make you unhappy in Agile. But it shows that you do not need to look for some special combination of traits – there are no “Agile people” and “non-Agile people”. This makes Agile very inclusive. 🙂
Blog

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.

Blog

On zero refinement in Scrum

My friend Steve Porter recently twitted on Product Backlog refinement:  “Refinement isn’t an event in Scrum. It’s a concept. It’s not mandatory and there are no hard and fast rules for when and how much. Zero refinement is acceptable, as is spending a majority of your Sprint on it. Figure out what works for you.” My first reaction was a feeling of doubt, but Steve is one of few people who really understand what Scrum is (he is a Professional Scrum Trainer and a team member at Scrum.org – a home of Scrum).  So I decided to think that through and try to figure out what I think of that.
We need to clearly define what we are talking about, so I would like to start from a quote from Scrum Guide, that defines what Product Backlog refinement is:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Then I wanted to figure out the things we agree upon. Scrum Guide does not define Product Backlog refinement as an event. Rather it is an ongoing process. So we are in agreement on that. The same thing with acceptability of “spending a majority of your Sprint on it”; refinement “usually consumes no more than 10% of the capacity of the Development Team” and that does not mean that it should consume exactly or no more than 10%. So it looks to me as if we are in agreement on “there are no hard and fast rules for when and how much”
But when it comes to “zero refinement is acceptable”, I have a different opinion. Yes, Scrum is a framework that is used in complex environments, and complexity implies that everything is extremely context-dependent, and nothing is “one-size-fits-all”. One should approach things with curiosity and open mind, and try to help the team figure out what works best in their particular situation (and don’t forget to review the decisions, because things are changing, and solutions should adapt respectively). And yes, Scrum Guide does not require explicitly that a Scrum team should do Product Backlog refinement. What makes me disagree here is the very definition of refinement as “the act of adding detail, estimates, and order to items in the Product Backlog”.
If we define refinement in such a way, then “zero refinement” will mean that our Product backlog is set once and for all. We do not add any detail, nor estimates, nor change its order. And that contradicts the very idea of a Product Backlog as a dynamic entity that “evolves as the product and the environment in which it will be used evolves”. Moreover, theу idea that a Product Backlog can be fixed once and for all violates the definition of Product Backlog. Let we quote Scrum Guide once again:
The Product Backlog is an ordered list of everything that is known to be needed in the product.
[…]
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
[…]
Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
So if one’s Product Backlog is not changing, then it is not a Scrum Product Backlog and therefore one does not do Scrum because “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”
I can imagine environments where such a backlog is possible, and that is probably something in a simple domain, and in that domain one probably don’t need Scrum (because one doesn’t need to inspect and adapt). Or it’s possible that a team just ignores changes or does not get feedback that could allow them to see that changes. Rephrasing an old joke. “If you don’t see any changes, you are right: you don’t see the changes.”
As Steve pointed out in our later discussion, there are (at least) two options to consider:
a) Some people suggest that refinement is specifically the act of the Product Owner and the Development Team working together on the Product Backlog. If a Product Owner updates Product Backlog items on their own, that’s not technically refinement.
b) There may be cases where a Product Backlog is very small and very loosely defined. It’s just a list of goals or experiments to run. In this case, the only work needed on the Product Backlog is adding new items or discarding unneeded items.
Regarding Option A Steve is not sure if he agrees with that view of refinement, but, as he says, “just because I don’t agree with it doesn’t make it wrong”. I would agree with him, taking into account definition of refinement in Scrum Guide: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog”. I would also say that this notion of refinement, when mixed with “zero refinement” idea, may add a lot of complexity. If Product Owner updates Product Backlog on his or her own, and Product Owner and the Development Team are not working together on the Product Backlog, this could mean that the only way Product Owner and the Development Team communicate about Backlog items is through Product Backlog itself. This might lead to all sorts of misunderstandings. I can imagine how that might work well, but such a way of communication lead to so many troubles that it is now among Principles behind Agile Manifesto (The most efficient and effective method of conveying information to and within a development team is face-to-face conversation).
Option B might potentially work, but also may bring a bunch of product troubles (miscommunication due to too vague Product Backlog items is just one of them, another possibility is a problem with fitting  Product Backlog items into a Sprint to have a potentially releasable Increment done by the end of each Sprint).
To summarize all of the above in three takeaways:
  • if your team does zero refinement, I would suggest reviewing team’s definition of refinement and team’s feedback mechanisms (including communications within Scrum Team) – there is a reasonable probability that one of those is not functioning the way it should be;
  • if a team’s feedback mechanisms are functional and the team has zero “ScrumGuide-ish” refinement (i.e. not adding detail, estimates, and order to items in the Product Backlog) – and it works well for that particular team – all good to them! As Steve says, “it’s possible and I don’t want people not trying it because of something they read in the Scrum Guide.” And,
  • before changing Scrum make sure that you are not changing it to hide the problems, but to solve them.
Blog

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.
Blog

Why Product Owner needs courage

I had a conversation with Steve Porter from scrum.org on dysfunctional interactions between Product Owner and Development Team in Scrum. This discussion reminded me of an idea that I learned from Jordan B. Peterson that real trust is an act of courage. In this post I am trying to unfold this idea applied to Scrum team.
A newly trained Product Owner usually is inspired by ideas of self-organization believes that a Scrum is a best way to solve complex problems, and that self-organizing Development Team is a best way to do right things right (and fast). He acts as Agile evangelist, working to promote Agile as much as he can. Based on this beliefs and inspiration he trusts Development Team to do what is needed to deliver Sprint Backlog and reach Sprint Goal. You probably have seen such a person. Many will say that having such an inspired Product Owner is critical for Scrum success.
What inevitably happens next? Development team fails. Sooner or later it happens to each and every development team (even if they are extremely undercommiting and overperforming 🙂 So this failure raises some questions for Product Owner. Why did they fail? Did I trusted them enough? Or maybe I trusted too much? Why are they destroying my trust? There is a good chance that Product Owner had some commitments regarding product, and his stakeholders are truly unhappy. Product owner feels bitter (and maybe resentment).
Did he really trust his Development Team?
If that trust was based on naive view that a team will be able to do anything if trusted, can we consider that a trust. Or it’s just a naivety? Trust is a necessary precondition for a team to reach peak performance and engagement, but it does not guarantee success. We are living in a complex world, and working to deliver value solving complex problems. There is always something we don’t know. There is always a change. There is always something missing. And this mean that sometimes we inevitably fail.
Next step for Product Owner is to think of what to do next. He might think “How can I prevent this from happening again”? He wants bad news early, so that he could get prepared (and prepare his stakeholders). He might decide to check Development Team regularly on how are they doing and if they are doing what he expects them to do.
Do they work on most valuable backlog item?
Are they still within their estimates of efforts?
Do they solve a problem in a way it should be solved?
This creates micromanagement habit, and eventually such checks become a daily (or hourly) status meeting.
What will happen to Development Team? First, such questions, even if they look innocent from Product Owner perspective, probably perceived by Development Team not as questions, but as requests. Product Owner’s role is associated with power and authority, and people have tendency to listen to everything said by empowered figure as if it is a demand, not a question. Next, Development Team will feel that they are not trusted, and this feeling will result in more and more disengaged team. Moreover, team loses it’s ability to self-organize: developers stop making their own decisions because Product Owner will decide anyway. In such a way, Product Owner becomes a bottleneck. And while he takes more and more decisions, team has less power, so he sees that he has to decide more. Less trust leads to fewer decisions that leads to worse decisions, which leads to less trust. And so it goes.
Some Product Owner will stay stuck on that level. “They can’t be trusted – they are too immature” view is wrong! They cannot mature because they don’t have opportunity to fail and learn. It is not the team. A Product Owner is the one who is immature.
What is an antidote for that? The answer is courage. It is one of five Scrum values, and I would say that it’s perhaps the most important one. If Product Owner has courage, he might think something like “OK. If I will trust them to do the work on their own, they will sometimes fail. This will be painful for me (and probably for Development Team also). But we need trust to move faster, to deliver more value, to deliver best possible solutions”. So he decides to be courageous enough to trust Development Team knowing that they will sometimes fail.
This is what a real trust is. It is a trust that is based on wisdom, not just some naive expectation that people succeed if trusted. Yes, if I will trust them, there is a risk. But I am taking this risk as necessary precondition for success. This is  a courage that a Product Owner should cultivate. And one of the key things that Scrum Master could do to server a Scrum Team – help everyone in a team to nurture enough courage for such kind of trust. Feeling vulnerable, but having enough courage to trust each other. This is a trust that makes Scrum so effective in dealing with complexity and allows Scrum Teams to thrive.
Blog

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.

 

Blog

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.

Blog

When a Manager is not Agile (but thinks he is)

Imagine you are an external Agile consultant invited to improve Scrum in a team. A product owner is a head of this department. Let’s call him Alex. Alex says a lot about self-organization and business agility and then during Sprint planning you observe this guy suppressing team’s initiatives, micromanaging, and in an aggressive manner avoiding team’s questions about business value of Sprint backlog items. It looks like Alex believes that he is Agile but enacts opposite – highly command-and-control behavior. So what should you do?

Ok, let’s talk and explain him what he’s doing wrong. Some people will start next meeting with Alex proposing some improvements. “Alex, you should be more transparent on business value of backlog items, let the team decide on “how” and focus on “why” and “what” and providing clear business objectives for each element in backlog.” They will expect Alex to open his eyes and change his behavior, or at least give it a try for a short time. But Alex gets angry, and claims that you are incompetent – he already had several agile consultants in his department, and all of them recommend the same things – the things that does not work. “All those advices could work if I had a more mature team”, Alex says – “but my team is not mature nor motivated to develop themselves. And I was hoping that you will be the one who will finally suggest something that will improve team’s self-organization.“ Someone could try to be not so direct and use “more coaching approach”. Try to ask Alex some questions that will lead him to realizing that he should change. But as soon as an inquirer has preferred answer in mind, it’s easy to get where he is arу aiming at. Alex will notice that (consciously or not), and you have the same results: anger and denial.

I have met couple of such Alexes (as many of us probably did) and spent some time thinking what can be done here. I came to the conclusion that the process-driven approach “do this, and it will make you change” will not work in situations like this – when a person at the top does not see himself as the one who needs to change. Even if you could set up some agile process, for example Scrum, you will get exactly what you can see in the example above: Alex is constantly sabotaging Scrum by micromanagement and lack of openness and trust. By the end of the day it’s all about changing a mindset, rather than just process adjustments. I have already stated in my previous post that we could (and even should) look at a science deals with such kind of changes – psychology. One possible idea of how to deal with such kind of clients I got from Carl Rogers. In “Counseling and Psychotherapy: Newer Concepts in Practice” he describes a new counseling approach. This approach has certain characteristics that are critical to a successful counseling. Rogers writes: “First is a warmth and responsiveness on the part of the counselor which makes rapport possible, and which gradually develops into a deeper emotional relationship… It expresses itself in a genuine interest in the client and an acceptance of him as a person…. He does not pretend to be superhuman and above the possibility of such involvement… The second quality of the counseling relationship is its permissiveness in regard to expression of feeling. By the counselor’s acceptance of his statements, by the complete lack of any moralistic or judgmental attitude, by the understanding attitude which pervades the counseling interview, the client comes to recognize that all feelings and attitudes may be expressed. No attitude is too aggressive, no feeling too guilty or shameful, to bring into the relationship. Hatred for a father, feelings of conflict over sexual urges, remorse over past acts, dislike of coming for help, antagonism and resentment toward the therapist, all may be expressed…. [Another] characteristic of the counseling relationship is its freedom from any type of pressure or coercion. The skillful counselor refrains from intruding his own wishes, his own reactions or biases, into the therapeutic situations…. Advice, suggestion, pressure to follow one course of action rather than another these are out of place in therapy.” By applying this traits among with some constraints a counselor allows client to express his feeling and intents openly, and by doing this a client opens his true feelings and attitudes to himself, thus being able to become aware of them. Having this awareness a client can decide what he or she is going to do about it. There is one more aspect of this approach that is crucial for success. First, a counselor does not force this awareness. He does not push client – just reflects on his feelings. This is a critical element – because bringing attention to a feeling that client is not ready to accept leads to defensive denial of that feeling and weakens (of even completely destroys) the rapport, thus inhibiting further improvements.

“OK” – you might think, “what all this has to do with Agile? We are not here to deal with clients family relationships or sexual urges!” I completely agree. But before disposing that approach (and this post) I would like to point on one additional fact. Many agileists that I’ve met have a strongly negative attitude towards command-and-control management style. We can’t hide contempt when someone says “resources”, “assigning tasks”, “status reports” and other “traditional management stuff”. Now let’s get back to the story that I described at the beginning of this article and try to connect the dots.

Alex believes that he is a nice guy, a modern manager and agileist. He probably thinks that it’s the right way of doing things, so given that he considers himself “a good manager” he suppresses command-and-control part of his personality. But one cannot just suppress part of the psyche – it will inevitably manifest itself one way or another in one’s actions. So Alex lives in a constant stress and self-deception, enacting his true set of beliefs while suppressing those beliefs. That leads him to frustration due to cognitive dissonance so he rationalizes his actions by externalizing and flipping his true attitude (thus “I am a command-and-control obsessed person” becomes “They are unable to self-organize, so I have to micromanage”). If you try to push him to acceptance of his command-and-control part, such a push creates a risk for his self-identification as a “good guy”, thus creating frustration. He is not ready to accept that part of his, so his sub-conscious part externalizing this frustration by masking it as anger towards coach. Bang! And given the described attitude toward command-and-control management one sometimes doesn’t need to say anything – this contempt is vividly displayed on his face during each interaction.
The situation that I described here is probably the worst case for any consultant: “I invited you to change them” (meaning “I am not the one who needs to change. Change the team”). Most of agileists I have spoken about such kind of situation agree that chances of success here are close to zero. You cannot force a person to change. But what if we are using a wrong tactics, pushing too far and too fast? The undirected approach to counseling described by Rogers “is characterized by a preponderance of client activity, the client doing most of the talking about his problems. The counselor’s primary techniques are those which help the client more clearly to recognize and understand his feelings, attitudes, and reaction patterns, and which encourage the client to talk about them. One half of the counselor items fall into these categories. The counselor may further achieve this aim by restating or clarifying the subject content of the client’s conversation. Not infrequently he gives the client opportunity to express his feelings on specified topics. Less frequently he asks specific questions of an information-getting sort. Occasionally he gives information or explanations related to the client’s situation. Although not the type of technique which could be used frequently, there is considerable redefinition of the interviewing situation as being primarily the client’s situation, to use for his own.” By doing this patiently enough, without pushing client too fast, counselor helps a client to recognize and accept client’s feelings, attitudes and beliefs at a client’s pace. And as soon as client accepts new facts about himself, he can start do deal with them. In order to do this a counselor must be patient, humble, and have enough compassion and self-awareness to not become judgmental about client’s beliefs. This can be hard to learn, but it is a skill, so in can be learned.

This approach has one side effect that we must be aware of. Because counceling can only be successful when it is undirective and based on total acceptance of the client, you can be confronted with a difficult choice after client’s gain insight on his beliefs and convictions. In the above example there are at least two options. A client can decide to change himself so that he will facilitate, rather than inhibit agile mindset and practices within his team. Or he can decide to accept the fact that he wants more control, and throws away the whole idea of becoming agile. This will probably have some positive effect on his organization as churn rate will probably drop as soon as manager’s declared values and actions will match (though some of current employees will leave the team). So in this scenario you can feel as if you facilitated “anti-agile transformation” of an organization. In my opinion both outcomes are rather positive. Even though the second scenario does not make that organization agile, it, at least stops feeding a myth that Scrum is just a set of rituals that do no difference. I see it as a positive change anyway.
How to implement this approach of non-directed client-centered counselling to agile consultancy? As my friend Roland Flemm says, first you need to get educated properly. But assuming you have knowledge and skills needed, what’s next? That’s an open question for me. I see that there are several constraints for this. First, this should not become a psychological treatment. This can be achieved by being constantly aware (at least by the counselor) of the fact that there is a limited set of topics that can be discussed during such conversations. Luckily enough this method does not require digging deep into psychological experiences that created this beliefs – just accepting them seems to be enough for successful counseling. Second constraint is the actual way of doing such kind of counselling. It should not be performed as an attempt to delve into the mind of a person. A possible way of achieving this is by paying attention and being truly curious about client’s feelings and beliefs. Third – you will need to have enough time for genuine conversations, so that you could build trust and help a client to reflect on his deep beliefs about how work should be done and how to manage people. You can probably agree on that upfront (while keeping in mind second constraint), so that client will be ready to spend time talking with you. Last but not least is setting clients expectations so that he will not expect (or insist on) you to give advice and guide him on what to do. A client will have to decide what to do by himself, while you may help him create a plan of how to do it.

Maybe you have used such approach running agile transformations? Please share your experience on Medium.

Blog

V for Vendetta (and A for Agile)

This post in some ways extends Why Scrum does not work (and what can we do about it).

Today I was thinking on why do I feel discouraged by many of Agile transformation stories, and a speech by Slavoj Žižek “How To Rebel” came to my mind. In this speech he asks very important question: “What happens AFTER the populist ecstatic movement takes over from the élite?” He is talking about revolutions and says that “…the measure of a successful… social change… is how will ordinary people feel the change morning after, when things return to normal.” He discusses the famous movie “V for Vendetta”:

“Do you remember the final scene? Thousands of unarmed Londoners, they all wear the famous Guy Fawkes masks, march towards parliament. And without orders the military allows the crowd to pass. The people takes over. OK. A nice ecstatic moment. And then the film ends. But, to put it in brutal terms… I would be ready to sell my mother into slavery to see V for Vendetta part 2. What happens then? You know, it’s easy for the people to win. What happens then? … How to break out of this cycle where revolt, or whatever we call it, rebellion, is just this momentary transgression, happy moment, carnival, and then things return to normal… The true problem is daily life. That’s the really difficult to change. The ordinary daily life.”

This description is very similar to what I see in many of Agile stories. We bring something new: iterations, gamification, planning poker, all kind of inspirational talks on self-organization, and everybody feels as if it is a beautiful carnival. People are energized (at least some of them), and see it as if this is a new beginning. But then the “next morning” comes (and a that point Agile Coach usually leaves for next client). And the ordinary life still the same, nothing has changed and things get back to ordinary (while some new terms and role’s names can preserve). Repeat this process for several times and nobody would believe that change is even possible. “We have already tried Agile, and it just does not work here” attitude is a blocker for any transformation.

So the question is “What should we do instead?” For now I don’t see any answer other than “Be patient and move slow”. Stop telling those “‘A’ for Agile” stories about revolutionary change, and focus on sustainable transformations. This can look boring (and sometimes it is boring), and they probably do not sound like a good selling story. But if we aim at making this world a bit better by helping organizations to adopt Agile, we should live by Agile values before teaching others how to do this. This (among other things) mean being open and build trust. Telling truth – even if the truth is “you will need a lot of work to become Agile, not just 2-day training and a certificate” will lead to losing a contract.

What do you think about the problem of “new ordinary life”?

Sergey Makarkin
@SergeyMakarkin