As I have seen Scrum fail in many different ways – and have learned a lot about Agile and Lean methodology – I came to the understanding of Gerald Weinberg’s 2nd Law of Consulting: “No matter how it looks at first, it’s always a people problem.”
It is also true that software development is a very young business and as such is still finding mastery in its execution. This connects to the everlasting journey of mankind to find a way to build successful teams with certainty.
Managers and consultants often are stuck with Tuckman’s 4 stages of team development. The best strategy to build successful teams? Mix, shake and pray. And talk about culture a lot. Then get to the understanding that culture eats strategy for breakfast.
Personally, I don’t want to base my professional life on hope. Thus, I developed coaching skills which I understand as the art and mastery of combining communication with psychological skills. The art in this is understanding how every individual is unique and the mastery is to create unique questions that lead to value creation by enabling the client to grow internally.
This blog post shows how we can derive value with certainty in a dysfunctional Scrum setup using modern, advanced coaching methods.
This is the next practice that logically concludes the Agile journey. This type of coaching is different to Agile coaching, as it is not about upskilling in a particular area of expertise but direct enablement of the person in front of you to connect his inert human potential with a given situation.
The content is a drill-down from the most abstract (theoretical) to the most concrete (practical) level of value creation and can be read just like that.
Table of Contents
–Layers of the Scrum
–Behavior in the Scrum
If you know how Scrum works you can jump to the main part right away.
–Mastering the Scrum
–Accessing a Creative Source
Please leave any questions or insights in the commentary section.
A working Scrum has several layers through which information stream. As a result of the collaboration of Scrum Team members on this information stream, a Product Increment gets created.
Apart from the technical side of developing the Product Increment, which can consist of system architecture and software craftsmanship, this work is knowledge work.
The different participants working on the Product Increment, including everyone in the Scrum Team as well as it’s Stakeholders contribute to the shared information with the specific knowledge those individuals own.
Thus the strict separation of concern based on the specific domain of a stakeholder or Scrum Team member creates layers of responsibility. This enables constructive collaboration as each party controls the decision making of their area of expertise.
These separating layers encapsulate, just like onion peels, the core of the work-in-progress of the Scrum.
We have the outside shell where stakeholder collaborates with the Scrum Team at the Sprint Review, or where stakeholders hand over their requests that they have for the product being built to the Product Owner.
Inside the onion the information stream from the Product Backlog through the Sprint Planning into the Sprint Backlog. During the Sprint Planning the responsibility for working on the available information, in the form of Product Backlog Items, shifts between stage 1 creating a Sprint Goal and stage 2 creating Tasks, from the Product Owner on the Development Team.
During the Sprint the Development Team collaborates during the Daily Scrum on which Tasks they have finished, which are impeded and what they aim to do next, and thus share responsibility between them for each day.
In front of the computer the Agile Developer is using Test-Driven-Development, and in a mature team pair-programming, to create a test case before the actual code. Here is the next layer of the onion where we separate the responsibility for evaluating the correct function of the code from writing the code.
At the same time, this is the first layer in which the responsibility for these both complementary parts of Agile development lies within one person.
Behavior in the Scrum
The Scrum Guide describes a framework for product development in a definite yet open manner. It is definite as every important aspect of organizing the work is precisely described and it is open as it solely describes capsules in which the Scrum Team can put in their own way of working.
The Scrum Values – Openness, Courage, Commitment, Respect, and Focus – supposedly lead to the specific behavior which enables constructive teamwork.
The Scrum Events – namely Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective – are time boxes in which the team can embrace their unique behavior which is oriented towards the goal of the specific event.
The Scrum Artifacts – such as Product Backlog, Sprint Backlog, Product Increment – are encapsulating the product-specific information, respectively work, of the team.
We can put on the onion-glasses here as well and see the above-described layers in inter-action.
E.g. No1. the Sprint Backlog is being used in the Daily Scrum to embraces the Scrum Value of Respect that results in the behavior of listening
E.g. No2. the Product Increment is being shared with the Stakeholder in the Sprint Review by the Development Team which embraces the value of openness with the behavior of describing the successful implementations and the shortcomings of the last Sprint.
Thus the Scrum Guide delivers a complete framework in which teams can gain hyper-productivity if they adapt it whole.
Yet many Scrum Teams fail to do so. They do not display the behavior necessary for a fully complete Agile collaboration. And it is upon the Scrum Master to change this.
In the examples given above I talked about occasions in which behavior leads to certain activities, which are necessary for a healthy Scrum to create a Product Increment each Sprint.
When a behavior is not displayed the activities fail to be effective and thus the Scrum becomes dysfunctional at a point.
What is happening there?
I am lending from this article as a basis for how to proceed in given situations.
Following I will dismantle the patterns, that lead to such dysfunctions. Starting with:
“Dysfunction 1: Daily Scrum as the status update meeting.”
Several reasons might lead to this:
a) Scrum Team members are not committed to doing Scrum, working as a team, or reaching the Sprint goal.
b) Scrum Team members are not embracing openness, in talking about their work.
c) Scrum Team members do not respect the Scrum Master, who tries to instill the Daily Scrum (there might be a commitment to do Scrum, but a lack of respect for the Scrum Master on a personal level leads to them acting dysfunctional).
d) Scrum Team members lack focus, as they are irritated by other work/projects/demands on them.
e) Scrum Team members simply don’t have the courage to speak up for themselves.
For this blog post I will only use case a) for providing an example that leads from a dysfunctional Scrum to the place at which a coach creates value.
a) Why are Scrum Team members not committed?
Case i) Scrum has been put on them by management.
Case ii) They have not been properly trained by the Scrum Master.
Case iii) They have been trained but lack the social skills to commit to something at all.
Case iv) Some want to commit, others don’t, the team is split and not able to act as a unit, thus deteriorating any efforts to build up a functioning Scrum.
So we are talking in general about the Scrum Value of Commitment being in question, and I’ve put up four cases that can lead to this(i – iv). What do to when those cases apply?
The Scrum Master should strive for a clarification of terms with his/her boss. Thus we seek to find an imbalance of expectation/reality in the relationship of boss/team.
Scrum Master: ‘Hey Boss, the team displayed dysfunctional behavior in regards to doing Agile correctly. I am afraid we are lacking buy-in of them for this way of organizing our software development.’
Boss: ‘Well, maybe I should fire you if you can’t make them work in a Scrum.’
At this point it is clear that the boss is not trained well in Agile himself. So we do this ad hoc.
Scrum Master: ‘You can, of course, do that, but let me speak freely about this one, to see whether there is a chance to turn this situation into a win for all participants.‘
Boss: ‘Okay, go on.‘
Scrum Master: ‘Agile development is about building projects around motivated individuals, and the motivation needs to be intrinsic for this to work. That is actually THE big differentiator from Agile to traditional ways of building software, we get a hyper-productive team ONLY when we get our employees on board with this method from the inside-out. Humans are naturally more creative, collaborative and productive if they take over responsibility by themselves, over being pushed to do something by contract.‘
You can see how we ourselves are using the collaboration over contract negotiation principle, by embracing the Scrum value of openness (and thus transparent) about what is happening.
Boss: ‘Mh, that actually makes a lot of sense. I do want to leverage the productivity of my team and we clearly lack collaboration across departments. So what do you suggest should be done now?‘
Scrum Master: ‘With your permission, I would put up a workshop with the team to find out what they do value in working here, and what would motivate them to take over more responsibility.‘
Well, in this case, we do a workshop on Scrum. We probably should have done that from the beginning. If the Scrum training doesn’t suffice to eliminate the dysfunction you will have to check the dynamics making out the team.
Check whether the working agreement exists. Check whether the team has an awareness of being a team, otherwise do a session on motivators and values (e.g. moving motivators for them to get to know each other, or high-performance tree for working on values.)
If people resist doing such things we might land at scenarios such as in i) or we make out individuals who are resisting particularly, which leads to …
If you have individuals resisting and the team is unable to sort this out by itself, you can go to the boss, or you can go into a one-on-one coaching situation. One-on-One coaching will be very diverse and exceeds the capability of a Scrum Master training. We might picture us being a Scrum Master who has invested in modern coaching skills for this scenario. If you go there you can get any response from ‘I hate working here’, to no response at all.
Remember: you may have a mandate from the boss to instill a functional Scrum, with which you can get that individual into a room with you, but you can’t make them talk if they don’t want to.
Let’s say you have to work with nothing:
Scrum Master: ‘Okay, you clearly don’t want to talk to me.‘
Scrum Team Member: ‘…‘
Scrum Master: ‘Well, here’s whats going to happen, either we find a way together to get a step forward in this situation, or I will have to leave the room and tell our boss that you refused to talk to the Scrum Master about our current Scrum dysfunction.‘
Scrum Team Member: ‘Okay, but I really don’t see why I am the one having to have this conversation with you.‘
Scrum Master: ‘Well, how do you like seeing yourself being in this situation.‘
Scrum Team Member: ‘I find it awful, I would rather be outside.‘
Scrum Master: ‘Okay, that makes two of us, but tell me, what is awful about it?‘,
Scrum Team Member looking at you … : ‘That I know there is a reason for our Scrum dysfunction, and I am being called out for it.‘
Note: the team member might feel cornered. So a better approach would be to build up resilience BEFORE going into what makes the situation awful, which will lead to the internalized reason the team member displayed dysfunctional behavior for.
Build resilience with a question such as ‘Okay, so what is it that enables you to judge this situation as being awful?‘ which leads into the presence, expect an answer after a few seconds such as … ‘Well, I am myself, and I can clearly say what I like and don’t like.‘
Let’s go on and include the resilience in our scene:
Scrum Master: ‘Okay, how is it right now to know that, whatever is happening around you, you can clearly say what you like and don’t like.’
This leads the team member into experiencing his inert strength.
Scrum Team Member: ‘Mh, I know that I am myself and that whatever decision I do for myself, I am responsible for it.‘
Scrum Master: ‘Okay, then let’s say that we two together find a solution that we both can decide for. – How do you like that idea?‘
Scrum Team Member: ‘Well, it’s good of course.‘
Scrum Master: ‘So how would working in our environment be better, if we find a solution that you can decide for, too?‘
Scrum Team Member: ‘Well, we would have a functioning Scrum I guess.‘
From here on we can drive downhill into the place where the coach is creating value for the team. We have a focus on the topic (‘awful’), we activated resilience (‘I know myself’), and we instilled a picture of a future with the issue being resolved (‘would have a functioning Scrum’).
The coaching approach being used in this example is lent from (Emergent Essence Dynamics). All of the questions being used from the coach’s side switch the focus of the client between awareness of something and consequently its experience. It is like ping-ponging him between intellectually understanding and emotionally processing, thereby leading deeper to the root of what is happening. (Hint: after getting used to how the Emergent Essence Model works it is simply an alternative way to communicate, as opposed to solely sticking to an intellectual/analytical way of communication we incorporate the emotions combined with the thing that evokes the emotion.)
We are still in the coaching scenario, the team member has opened up and we are ready to finish this blog post.
In our example, we have a dysfunctional Daily Scrum, because of a lack of commitment which we traced back to an individual team member resisting and hereby pulling apart the team commitment in total.
We also ruled out that the team can fix this by itself and we chose one-on-one coaching over a team coaching approach. In real life this might be the case when we have a strong developer, who made himself indispensable, thereby making the other team members dependent on him, and thus has enough power to make the whole Agile approach a failure.
We are potentially dealing with feelings of insignificance of the team member which he faces when he is accepting the Agile methodology to take root. Agile methods rely on the shared responsibility of the team, elimination of bus factors and collaborative working. These feelings of insignificance can surface in an individual that got his professional validation, throughout his career, by excelling above his peers.
What we call a polarity describes the two zones this individual can be in, one of which he is avoiding at all costs. His psychological condition is separated in 1) one place where he feels valued and 2) a second place where he feels insignificant.
Place 1) is the place where this strong developer can show off his skills, he likes the others to look up to him, he demonstrates repeatedly that he creates the most value during an iteration of work, he teaches the others who depend on him as he knows the system/code in the best way – here he is indispensable.
Place 1) is thus the reason why he makes the rest of the team dependent, he may teach them, but he would never let anyone get as good in working this system/code the way he can, he may create the most value, but he will not allow the team as a whole to excel as he needs to make sure to be the one who creates the most of value.
This place was the Status Quo before Scrum was introduced.
Now there is place 2), where he is standing in the Daily Scrum and clearly is on eye-level with the others, here the whole team is supposed to create tasks in the Sprint Planning 2 that any developer can get done in one day, here the whole team is evaluated based on the success of the Sprint Goal – thus status of individual developers disappears.
Good for us that we have this person in a coaching situation. Our goal is to enable him to psychologically collapse those two places into one, as such as that he is able to fully support the team’s success through the usage of the Agile methodology while still feeling indispensable and valued.
Accessing a Creative Source
Scrum Master: ‘So, what awful thing is hindering us to be at that solution already?‘
Scrum Team Member: ‘Well, it is that the Team is not performing according to management, and you are here to change us.‘
Scrum Master: ‘Okay, so how do you feel about not performing well in regards to management perspective?‘
Scrum Team Member: ‘It’s actually not true! We are and have been doing great, it’s just since they put this Scrum thing on us those difficulties arose.‘
Scrum Master: ‘So, how can management get to such misperception?‘
Scrum Team Member: ‘They only see what’s coming across each iteration, and not the daily struggles we face.‘
Scrum Master: ‘How is it to be in this daily struggle and not being acknowledged for it?’
Scrum Team Member: ‘Well, it’s fucked up. Excuse my terminology, but really they don’t know how hard it is to build software. And we have to work overtime for getting things done in the end.‘
Scrum Master: ‘Well, management decided for an approach that is based on transparency and open collaboration, which is meant to shed light on the daily struggle and making the whole process and involved pain more visible to everyone. Which actually means at this moment I am the one having to work overtime to get us guys out of that misery.‘
After opening the polarity with the first question. He took his preferred place 1). With my last statement I took this place myself, which pushes him on the other side of the fence, place 2).
Scrum Team Member: ‘Well, come on, obviously, we can not do everything just magically as management wishes.‘
Scrum Master: ‘So where does that leave you guys, not performing well in the eyes of management, and then having to change magically?‘
Scrum Team Member: ‘It can’t work, we need more time to sort things out.‘
Scrum Master: ‘Okay, so on one hand, you have to work hard and overtime to get things done, on the other hand, you need more time to adopt a more transparent work style to sort those things out. How does that fit together?‘
He looks at me while his brain is trying to process both places at once, and he feels the ambiguity of the whole situation. He physically relaxes a bit and breathes out. Then continues: ‘It doesn’t fit together, and it can’t work like that.‘
Scrum Master: ‘What is it that you would really want to change for yourself right now?‘
Scrum Team Member: ‘Being able to work in a more calm fashion. And not feel pushed and pulled between work and organizational change.‘
Scrum Master: ‘What is in it for you when you can work in a more calm fashion?‘
Scrum Team Member: ‘I guess a more healthy work-life balance!‘ He laughs.
Scrum Master: ‘Okay, so, how’s that for a change.‘ I smile at him and proceed: ‘With having a more healthy work-life balance, how would working at this place feel better?‘
Scrum Team Member: ‘I’d more relaxed and I bet the team, too.‘
Scrum Master: ‘What is it that can relax you?‘
After collapsing the polarity we have now a clear view of the quality that was entangled in the struggle between the two opposite places: a more peaceful way of working.
Scrum Team Member: ‘Doing my best, and knowing that my work is acknowledged. And, of course, having a nice atmosphere in the team and a good relationship to management.‘
Scrum Master: ‘How do you see my role in this, now?‘
He smiles at me: ‘I see, now, that you want to do your best, too, and contribute to the success of the team and establish a good relationship between all people involved.‘
In the coaching practice it is not usual that a first collapse of a polarity, and subsequent drop into a creative source, can be anchored in an instant. But each time the client experiences that what actually is beneath the struggle, he builds more acceptance and resilience for the whole situation. It might also be that there are more chapters to such “game”, but each drop unveils the next layer of resistance and is thereby a direct creation of value by enabling the client to grow internally.
On the outside the attitude and behavior of the client changes, which means that the way other team members relate to this character “strong developer” will change immediately.
This makes free the way to a more balanced and healthy Scrum Team, as the strong developer no longer has the need to get validation by working the hardest and getting the most work done.
In our scenario it means that the whole Scrum Team is now enabled to commit to the Sprint Goal as a whole.