Summarizing my experiment as a Scrum Master

My flight is delayed and a good opportunity to continue my blog. The latest organizational changes kept me a little occupied and I got badly delayed with my writings – deepest apologies to my followers. Anyway, in this post I will summarize my experiment as a Scrum Master and I will also share some findings and observations.

Three months sounds a long time, and on the other hand it went by in a blink of an eye. Based on the feedback I received I was able to make a difference, people saw what a different mindset can do, they got ideas on how to view issues. On the other hand, there have been doubts whether the three-months dose of me was enough to sustain the new spirit and level of energy. Time will tell.

During my time, I have experienced all sorts of feelings: frustration, anger, loneliness,  “all world is on my shoulders” as well as joy, reward by being able to influence others, fun, achievement, good feeling one gets when helping others and when one sees that something is changing to a better direction.

When discussing with management about lean and agile, I hear often that people in R&D are perceived lazy and the manager must push them that something gets done. I wonder where those lazy people are – I met only people which wanted to do a good job, get better at what they do, become a true professional, wanted to learn and last but not least – they would like to have fun at work. Yes, they typically have their own ideas and ways in how to do that. So if a manager thinks this is the way to do this task, I can ensure you that “my way is certainly not the other person’s way” – so much for harmonizing this & that. Keep this in mind and let the people “freely” doing their work.

I was overwhelmed by my findings – so many and of so different kinds. The first one which I found regularly was denial. I got the imagine of the three monkeys in head – don’t see, hear, speak. This brings me back one of my previous posts. Assuming an outside consulting would say “I think, you have a problem” – I got in almost all cases the answer – no I/we don’t. Besides, this confronting consulting style (I mean it really hurt me to see those issues), the denial went basically on all the time. Yes – BUT. Yes, we are drowning in bug reports but it is not sooo bad as it looks. I am ok to hear this once, maybe twice – when I see it most of the time, it’s start to smell. The question is – how to break the denial state at different levels in the organization?

Old habits die hard – I could surely confirm that. One of the biggest challenge in the organization seems to be to unlearn old practices, ways of working which are not supporting the business goals, not supporting a lean and agile way of working. Since typically new improvement things (e.g. learning TDD) was typically put ontop of the existing workload, it was done on a best-effort base. And the fact that people have several roles and try to joggle between those roles did not make the situation any easier. A suggestion would be to consequently and regularly check whether e.g. certain meetings are still needed and if not, remove them consequently and free time for those new study items.

I think I did the biggest impact in changing people’s perception to how they feel about their abilities to influence. Many people felt “down”, they were afraid – they were “victims” – figuratively some persons felt like somebody puts a pistol on their head or holds them down, low on the bottom. I met several persons with a personal conflict. On the one hand they want to get better and then once more I hear “ Yes, but I/we cannot”  … victims of the circumstances. I think that some individuals truly understood what a different viewpoint can do and they changed their attitude by e.g. identifying what they CAN do instead of listing what they cannot do.

The breakthrough finding I had was the following. A typical team had three types of input work (1) New feature development, (2) Bug corrections and (3) Improvement actions.

New features came in via the Product Backlog. The features prioritization was done at several levels, in several rounds by many stakeholders and in the end, they agreed on which feature is more important. These inputs were given to the Product Owner. As the organization was running several parallel releases, the (Product) Area Product Owner needed to joggle a little more and prioritize between those inputs (You certainly noticed the inconsistency here, however that is not the major finding). The APO and team agreed in sprint planning what is done next (as described in Scrum).

The fault correction input stream represented the second kind of input. One reason why this was so important was the fact that the Product Verification was a separate organization and the development and verification folks communicated by using a fault management tool. Not very scrumish - is it? Anyway, I admired the pretty cool way they tried to manage the prioritization between new feature development and fault corrections (or getting the stuff DONE) by using a two-level threshold system which guides the teams whether they should work on new features or fix old stuff. On a side note, it did not really work, and I did not have a chance to dig deeper into this.

The third kind of input was improvements and – boy hey – there were many J … Typically all the managers had ideas on how the teams can improve, the SM had ideas and suggestions, the team members had ideas and so on and so on. I would claim that those improvement items were not prioritized properly. They were a big number of things to improve and I got the feeling that many things were started and nothing really pulled throughout the entire organization. Some of the improvement ideas made it to the incentive system, others were hosted in some other cross-organizational level plans and team items were occasionally visible in impediment/improvement backlogs.

Now - The BIG findings was that I was not able to find any sort of priorities between those three types!

And this means, that the decision whether new feature shall be developed, a fault should be corrected or an improvement item shall be done next was very much up to the individual team member. On the other hand, my impression was that due to lack of relevant business information e.g. value of feature vs. fault correction vs. improvement item – the decision became a rather intuitive one. This way of making decision seemed to lead again to more frustration and giving the people the feeling they try to “survive” instead of thriving and flourishing.

This experiment has been a huge learning for me, I had plenty of fun and I got wiser. I do not regret conducting this experiment and I can only recommend to coaches to do this for the sake of getting the experience (I think also the counterpart can learn, however this is up to them not to you).  On a personal note, I realized, that being a Scrum Master is not for me. I enjoy much more to work with several teams, across the organization, to have time to study when working remotely. I think this is not compatible to my role definition of a Scrum Master.

There are still one or two items I wanted to document from this experiment. Stay tuned for those. I hope you enjoyed the blog and maybe could use some of the items I listed here, thoughts I wrote down.

~ Life in every breath in every cup of tea – that is Bushido ~

What is the problem in problem solving

This is clearly one of my favorite topics. During this experiment, I had the chance to give a couple of lectures on systematic problem solving. I learned a lot about the topic myself since I needed to be able to teach others about. There is not really anything special (aka rocket science) about that topic. Many famous authors in the lean and agile community have provided us with plenty of material and ideas to solve problems systematically.

I like to use A3 method in the course. Even though A3 is coming from Lean manufacturing, in which you try to eliminate variability, I think it can be used in Lean product development. During the course, I typically do an exercise in which the audience is asked to make an A3 on the topic: “What is the problem in problem solving?”.

Interestingly, some of the feedback (also from earlier trainings) has been that the people want to have a “real example”! Come on folks – you are here in this course to discuss why you cannot solve problems in a systematic manner. Ok - like what are your real problems which you cannot solve? Quality problems? Problems with your salary? I admit, my theme is touching problem solving on a meta level.

The idea in this course is that people start to learn how to solve problems NOT to actually solve a particular problem. Why not? Typically someone in the group is to attached. Since the people had trouble to let go in the past to tackle the issue, what would have changed NOW so that they could solve the issue DURING this course???

And I think this issue reveals a lot to me. If I mention a real life problem, the first solutions come to me even before I have finished speaking!
My observations contain the following typical behavior:

• no common understanding of the problem
  
• no common understanding/agreement on the direction/desired state
  
• no common understanding of the current state (i.e. how it is REALLY in the organization and e.g. not how managers think what the problems are) (sorry managers, I address you as managers because you manage instead of leading – HUGE difference)
  
• at least one solution per person (and this is of course the only one possible) which is by no means proven to be solving the problem
  
• no measures in place to verify that the experiment/potential solution is progressing and especially no measures in place to verify that the experiment/potential solution is bringing you closer to the desired state.
  
• Weak to no real ownership and follow-up of the agreed actions
  
• Manifesting what is working as well as eliminating/stopping what is not working.
  

It does not matter what method you use. May it be A3, GROW/GLOW, a research-oriented approach (Poppendieck), ideas from Complex Adaptive Systems – I see recurring set of underling principles:

• Gain common understanding of the problem (what, why, for whom, when)
  
• Agree commonly on the ultimate goal (what, why, for whom, when)
  
• Agree on utilizing experiment to figure out what works and what does not
  
• Gain common understanding what is in your way to get one step closer to your goal
  
• Measure your experiments and your progress towards the goal
  
• Be humble and open minded – its a long journey.
  

Do Scrum or be Scrum – remembering Scrum Values and other aspects in Scrum

When you discuss with people in an organization which claims they do Scrum, what do you observe? Typically, I see a lot of Scrum “process” mindset. Yes, there is sprint planning, sprint review and daily scrum. And yet, once I look closer, it appears to me rather “hollow”, superficial.

The other/softer areas such as a scrum team is cross-functional, self-organization and scrum values are often ignored, yet essential in order to achieve the desired business goals. And it is those business goals which you try to achieve by means of doing and being scrum.

A scrum team is supposed to be cross-functional i.e. the people in the team have competence in architecture, design, coding and testing – do you see all of those in a single team? The worst case I have seen is a dedicated “scrum” team for architects, developers and tester. This is not scrum.

Self-organization is often another area of confusion. What does it mean to be self-organized? How to get there? Those are big questions, they deal with how much responsibility one is willing to take and how much managers are willing to let go. Nevertheless of the difficulties, self-organization is key for a team to become a high-performing team.


Did you remember that Scrum contains also values? Those Scrum values are:

FOCUS

COURAGE

OPENESS

COMMITMENT

RESPECT

Often, people are not aware of them. And if, then the interpretations on what they mean differ from person to person. Similar to a previous post on Agile manifesto and principles, I suggest that you discuss those values in your organization and figure out what they mean for you – better even if you can invite an Agile Coach from the outside, to get a out-of-the-box view compared to your own.

When looking at various Scrum training materials I have been missing those values – they are simply ignored. And then, I just tried to check them from scrumalliance.org and … nada – nothing there either (ok, maybe I might have not spend enough time for searching, however it seems that all the certificates are more important then the scrum values).

What can I do to help this? In future scrum courses, I will put more focus on those other/soft aspects.



p.s. I just saw a job add for a “Scrum of Scrums Master” - OMG!

Area Product Owner – more negotiator and less entrepreneur?

I've been giving a fair amount of Product Owner trainings and mostly to people in organizations which are BIG. BIG here means 10+ ... 30+ Scrum teams or even 80+ Scrum teams.
Ok, they are not always “real” Scrum teams, based on the definition. Sometimes they are more component team and sometimes, those teams can do a piece of end-to-end functionality.


The typically audience in those trainings consists of all-sorts-of-architects, assigned Area Product Owners, project managers (not THE project manager – more kind of sub-project manager) and others who have a word in saying what others should or should not do. Occasionally, I see THE Product Owner.

In those trainings (more or less following the ideas of the Certified Product Owner trainings from e.g. the Scrum Alliance), the people often feel that what I talk about is too theoretical (nice to know and irrelevant). This is due to the fact that the participants don't e.g.,

• create the product vision
  
• define business models
  
• cooperate with customers
  
• estimate value of backlog items
  
• decide about scope/schedule priorities
  
• decide issues related to the product life cycle
  

What do they do then?
I differentiate two main cases: (A) The Area PO (APO) serves a single PO and (B) the Area PO serves several stakeholders e.g. several PO's, PO and Program Manager, PO and LMs (e.g. acting as fault coordinator). I will focus on case (B) as this was the setup which I faced in my experiment (and in many trainings). Case (A) is a subset of case (B) and the reader is free to pick what fits and ignore the rest.

Reality check: The higher level dependencies as well as higher level flow (e.g. to System Verification) are “managed” by somebody else then APO. The APO typically is not discussing with customers – only with development internal stakeholders. The requirements are broken down by somebody (often an architect at a higher level) before they reach the APO (and this reduces the importance of discussing User Stories in my trainings).

In the end , the APO is responsible for the “area backlog” (often a separated backlog instead of having ONE product backlog with sections for the different product areas) which might still contain end-to-end product features and functionalities as well as requirements with dependencies to other areas. The remaining real work with the backlog is to make the different stakeholders understand that the sum of all their needs (wishes, demands) is far too much compared to what the teams can handle.

Thus the key role of the APO is to bring the facts on the table and to facilitate the negotiation between the various stakeholders. The APO does not prioritize the items, the stakeholders need to do that part. Those facts – made visible by APO - are based on real velocity/throughput data, team estimates, identified risks, dependencies within the product area, new functionality vs. improvement actions etc.

How to train people to become a professional APO in such an environment?

My experiment ended and this blog will go on

My experiment of being a Scrum Master ended last Friday with the Sprint review and retro. I still have plenty of “undigested” observations and findings which I want to share here, so the blog will still continue for a couple of weeks from now.

The last two weeks have been rather busy with all sorts of workshops, trainings and individual discussions. Maybe because the people around me realized that my experiment comes to its end or simply others realized that I might provide meaningful comments, feedback and suggestions.


Stay tuned for more …

Am I pushing change here or what?

Recently, I had a dialogue which went like this ...

I say: From my point of view you have a problem.

Answer: No, we don’t.

I say: I think, you do.

Answer: No, we don’t.

I say - Why do you want me here, if you deny the problem once I think there is one?

There was no question asked like – “what is the problem you think we have?” or “what do you mean by that?”. I am fully aware that the opening was rather provocative, however, IMO this was already the sugar-coated version. I am aware that this is a kind of “fixing on a position” and typically it is not leading anywhere. On the other side, this was not the first discussion, oh boy NO - we are now at a stage where people in the organization want to hear my observations, findings and thoughts – or at least I thought so ...

Right now I feel like like I am pushing an entire organization to become agile!

This is rather frustrating and I get a headache. I remember what Paul said about headache, its not your problem and this is true here as well. I need to go back to my purpose why I am conducting this experiment and why I want to be in this organization. My goal is to learn (whether I solve some problems along the way is pure coincidence – a side effect).

So, what do I learn here: I see a big junk of denial of reality and a “It's not so bad after all” - attitude. This is complemented with a crunchy “ I can't do” and “this is impossible to change” attitude. I face reactions like “Wolfi – now you really lost all your marbles – go away I am busy – stop annoying me you crazy external coach”. This amount of resistance is too much to handle for a single person (even for a big guy like me) by maintaining a healthy mind at the same time.

If you feel to be in a similar situation, the question for you might be what can you do? Here comes an idea: Find alleys, people who think in the same line of principles, others who are stamped to have lost all their screws. And you might be surprised where you find those people … team members in the next room, people working in support function e.g. building CI-system .

Persons who are titled Scrum Master or Agile Coach are not automatically fit for this community. I have seen so called Scrum Masters where I would say that a mouse impresses me more. I have met so called Agile coaches which think that “Agile is a process” and thus they favor “management by metrics”. Those kind of people are the ones which need to be influenced not the ones which influence others in the spirit of Lean, Agile and Scrum.

Stop bugging me with those Agile values and principles

As part of a workshop preparation a few months back, I have been warned – better said the host had urged me to avoid to talk about Agile manifesto and principles. Confusing to me – why would anyone NOT like to talk about Agile manifesto and principles. To me, those are the closest kind of a description of management support & guideline, Agile offers you. In Lean Product Development, management support is more in-build and e.g. documented as the foundation of the Lean House.

It seems that besides the struggle of this organization (in which I currently work as a Scrum Master), I find evidence from within this company as well as other companies, that there is a struggle with realization (or better saying implementation or mental models) of the Agile values and principles. People seem to be hasty, and not taking the time to discuss those values and principles, trying to understand them, reflecting what this means to them in their environment. So, what is the solution: make people come together and let them discuss.

Working for us ??? NO!!!

What happened? We tried so hard! What is missing?

I realized that a group of people, who have about the same (I say light; or superficial) understanding of Agile values and principles discuss e.g. one principle in ten minutes. They reach a conclusion and go to the next principle. Give them credit for trying, and remember: those people simple might not know any better. The content of two-day training which they received months or even years back with the 200+ slides, is long forgotten (if the Agile values and principles were even discussed deeply in the first place).

Once more (see previous post “Why an organization needs an (external) agile coach”), I see a clear benefit to have somebody from outside of this organization (might be from within or outside the company) with deeper understanding of the meaning of those Agile values and principles. Then by e.g. asking questions, this coach can guide the discussion into a direction so that the participants get this deeper understanding.

In the current group of (only) six people, a single principle requires a 30min – 1h discussion to get a deeper understanding of what is means to behave, act, “live” the Agile values and principles. How could anybody think that participating e.g. a two-day CSM course gives sufficient time to gain such understanding?

This is only a first step. The next steps would include to understand the current state of thinking, followed by ideas which potentially get the organization to the desired state.