Thursday, June 7, 2012

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 ~