Friday, December 30, 2011

My first intermediate sprint retro

I do not like sprints which are longer then 2 weeks and here is why. One of the ideas of time-boxed iterations is to create an environment in which people can get frequent and regular feedback on their work and their way of working. The retro is a tool which reserves time and space for the team e.g., to reflect on their way of working, to reflect on how work is progressing, to understand the big picture in their work (meaning e.g., a longer period of time instead of only daily activities).
Do YOU remember what happened four weeks ago or even three weeks ago? To me, such a time-span feels like ages ago (sometimes like a dream) and I really have hard times to remember details. If this is the case for many, how can you do a meaningful sprint retro covering the entire time span of four weeks? Therefore, I proposed to the team to have an intermediate sprint retro in the middle of the sprint (even though it would be more beneficial for the teams to work in shorter sprints, four weeks seem to be carved in stone).
And so we had. The team created a time-line, listing those positive and negative events which the team members regarded as meaningful. We moved all in front of the time-line chart and the team members shared what they see in the chart, what they think about this “bigger picture” and to some limited extend how they feel about it.
We were able to identify several issues/ facts/ problems/ challenges as well as some ideas for solutions. I found this an important step as the team realized by themselves that (right now) plenty of time and energy is spend on faults and furthermore the team acknowledged that there is room for improvement on what they can do.
And me? I got work for many many weeks to resolve those impediments and I think the team members got a glimpse of what they could do to improve the situation. As the team's “normal” scrum master was also present, the two of us discussed later about the findings and he said, that basically most of those issues are known in the organization (and why is nothing happening in resolving those items???). I still give credit to many people for trying to solve the issues, sometimes, it might not be in a lean and agile “spirit”, which might be the problem why some changes do not stick (this needs certainly deeper digging).

We also reflected a little on our daily scrums and yet again, great ideas came up by the team to improve the information flow in the daily scrum. Lets see how it will go in the future.

A delicate issue

Today, we had SM CoP and I was faced with a small however delicate issue.
On the one hand, the team and me “know” each other for barely two weeks. I do trust the team, they are really great people eager to do a good job and become true experts in their field. At the same time, I am not sure to which extend the team members trust me (yet?). So, I would say, we are in the beginning of building the relationship.
On the other hand, other Scrum Masters want to learn and see how I am doing my work. This exchange of info did already happen through discussions and I saw some others join during daily scrum. Now, one SM wanted to join in upcoming workshops, the next one being my first intermediate sprint retro (more about that soon). I tried to explain that even though I am happy that somebody is interested to join, I felt that it was a bit too early for that, and that the my relationship with the team is just building up thus maybe not mature enough.
My worry was whether the team members will be as open with “strangers” in the workshop as they would be without. In the end, there might be relationships in the organization which I am not aware of at this point.
In my quick opportunity and risk analysis, I saw little opportunity (having an observer present) and medium risk (workshop will not bring value to the team members) and decided to facilitate the workshop alone.

Two issues about the continuation: (A) the team and me already agreed to have more workshops and there will be space in the future for other Scrum Masters to join and learn and (B) I propose learning by doing i.e., by co-facilitating workshops, and not just observing. I think that this approach in combination with reflection (of the facilitation etc.) would be more suitable.

(on the blog itself: ok – I got it – many people do not like white on black, and as I write my blog and not read it from the web, I decided to change the layout to black on light background – I hope reading is now easier)

Wednesday, December 28, 2011

Darkness & Silence

I have never experienced an involuntary electric cut of this length. The hour meter counts 66+hours without electricity, this also means 66+hours without running water. All sorts of Scrum problems start to look a little smaller in this moment. Lucky me, all our trees are still standing and nobody of my family got injured during that worst storm of the decade. For all those electric & water problems, I found solutions. And now back to Scrum Managing – sorry Mastering ;)
Today I started my series of interviews about goals (targets) – extremely interesting. Just ask which problem you want to hear about, and most likely I can give you an example. Goal conflicts and all sorts of other mismatches confirm the picture I draw already. Hey – I am an Agile Coach, working as a Scrum Master – what a GREAT coaching opportunity this is! More about this topic in a few weeks.
And I seem to do something right as, today for the first time, I got pulled aside from one of my Scrum Master colleagues as she was in the search of answers to his questions. She asked about to extend the daily scrum so that he can exchange important (in his mind) information to the team. I acknowledge that the information appears important, yet I questioned whether this is the job of the SM (please note that a typical SM in this organization does have multiple roles). It comes back to my previous post about the different POVs. There is a problem and the SM has her own POV and thus promotes a solution in alignment with her POV (i.e., to extend the daily scrum). This is one out of many solutions, often not the best one and most likely not one which will lead to commitment – it rather leads to compliance. We agreed that sticky change i.e., coming from commitment is what would be better.
We continued the discussion about motivation for oneself and what drives people. And I recommended to read Dan Pink's book DRIVE related to motivation – this might be an eye opener also for your private life. In short, Dan created a ”motivation 3.0” model in which he suggests that people are motivated by three factors: Purpose, Mastery and Autonomy. Check it out at and you will find two video clips (one animated and one from TED talks) and much more.

Thursday, December 22, 2011

Stuck in operative work and no time left for reflection

Finally I welcome my team members. Howdy folks :)

What is this now – no time for reflection? Well, honestly – my days at work have been really busy. Today I spend at least one hour on IT tools – totally frustrating and still only one out of three problems is fixed, so I am looking into wasting more of my time with tools next week. The preparation of the workshop, the workshop itself, daily scrum & discussions afterwards, xmas get together with glögi, lunch, doing the agreed tasks and discussion with people – all this takes time. Stop whining - what is the issue? Well, it REALLY takes time to reflect on observations and especially on ”how did I feel at that time”. This is not done quickly between two meetings. At least for me, I also require a stimulating environment and no disturbance. This blog helps me to reflect and I feel more confident that writing a blog is a good thing. I think, this blog is primarily for me not for you – sorry my dear reader :) in case you can take something from that, even better – and if we start to have a dialogue – well that would be superb.
Today I had to restain me from not being to pushy or jumpy. It was hard. I got the feeling that there is this surrounding ”thing” in the organization (is it organizational culture???) which seems impenetrable. Almost comparable to the attempt of trying to win a dispute, where the one side argues logically and the other side emotionally. Emotion wins. The managers argueing emotionally and me, the coach, the scrum master logically. BTW, I could have sold a few of my ”help” buttons (see earlier post) today when I discussed with managers in the ”glögi” event. OK, I guess this makes no sense to anybody – even I do not understand what is happening. This needs clearly more digging. Now I am re-reading this blog and its still bugging me: Why are people not listening? They want to do Agile (is this the issue – people want to do agile instead of being agile?), they want to do Scrum – I have the feeling that managers welcome me and at the next moment start regretting it.
Two things from the team side. Since I have the next two days off, I asked if there is anybody in the team who would like to be my substitute and within seconds I had a volunteer. Great. Of course I could have just asked the old scrum master to do the job, and then what – where is the learning for the team members?
Another thing we started today was to have a ”team info wall”. I had seen such one somewhere before, and I think its pretty handy. A team member can leave a note if s/he is e.g., in a training, in holidays, working remotely etc. Strangely enough, a team member is also asked to fill in a wikipage when s/he is in vacation (and I think our HR also wants to know that by using a seperate tool and I am not sure of they guys actually need to report their hours into another tool – have to ask next week). I feel this impenetrable thing closing in again …. This is my last post before xmas as I take a little time-out (nono not because it is soo hard to be a SM – this trip was booked long before this SM idea came up). I would appreciate some feedback, comments, critics, suggestions etc.
Merry Christmas to you all and have a relaxing time.

Getting to know the team

The team itself is relatively new, and of course I am new in the team. I decided to do two small exercises this morning with the team. The one is what I call “Team barometer” and the other is what I know under the name “shield”. I started to develop the team barometer many years back and I cannot remember what kind of inputs I had – there were many. At that time, I knew nothing about Agile and Scrum and so I needed to modify the questions to adress some of the Agile & Scrum aspects for today. Here are the eighteen questions which I printed beforehand. Each team member needed to answer individually each question on a scale of 1..6 (1=Strongly Disagree; 2=Disagree; 3=Somewhat Disagree; 4=Somewhat Agree; 5=Agree; 6=Strongly Agree) (I know this is mean, and purposefully I push people into an either agree or disagreeing zone instead of allowing them to hang in the void area of a typically five or seven point Likert scale)
  1. I know and understand the product vision.
  2. I think the current release goals are realistic.
  3. Our team has a commonly shared sprint goal.
  4. I am confident that this team will meet the sprint goal.
  5. Our team is performing smoothly.
  6. My work gives me a feeling of personal achievement.
  7. I have had feedback from APO/LM in the past 60 days.
  8. I feel I am being treated with fairness and respect by the people I work with.
  9. I feel I am being treated with fairness and respect by my manager.
  10. My work schedule allows sufficient flexibility to meet my personal/family needs.
  11. Our team spirit is very strong and we have an open and constructive atmosphere.
  12. Information within my team is sufficient and the flow of information between our team and other groups is sufficient.
  13. The co-operation between my team and other groups works well.
  14. As a whole, I am very satisfied with working in this team.
  15. Our team is exploring different ways to do our work.
  16. We have clear boundaries on what we can decide in the team and what not.
  17. Management is supporting us by listening and removing impediments.
  18. If I could change one thing about my current work environment, (eg. computer workstation, meeting rooms, facilities, project setup, working practices, etc.") , it would be ….

Now the idea is not to start fancy statistical analysis. From a snapshot you might see the differences between individuals and you might see the problem areas of individuals and/or the entire team. If e.g., all except one person answer question #17 with a ”6” and the other person with a ”1” - its an individual case, if all team members answer this question with ”1”s and ”2”s, then the entire team is facing a problem – excellent starting ground for discussion for a ScrumMaster (remember the SYSTEMATIC problem solving approach!!!). More important then the snapshot are the trends, which means that the answering of the questionnaire need to happen regularly e.g., in combination with a retro?
The other exercise was to create a ”shield”. I am not sure if the idea is copyrighted by one of the Agile ”gurus”, if so, I hope its ok to mention the idea here and the author please may step forward to claim the ownership. Anyway, the shield looks like this: on the top you put your name, you divide the shield into four parts describing your (A) gifts, strengths (B), (C) Learning objectives and (D) ”Later”, ”Dreams”. On the bottom of your shield, you write ”the way you live by”. Typically, all this is written on a flip-chart paper maybe put nicely by using different colors. Then each person puts the shield on the wall and one by one each person presents his/her own shield. There are also other methods to achieve the same effect. Later (during the Glögi-Session) some of the team members commented that this was ”different” and they found it valuable. I did not wanted to start digging more, as it might have ruined the glögi and also the big boss wanted to give his xmas speech.

Wednesday, December 21, 2011

And the APO says ”we have a quality problem”

Yesterday was my first daily scrum and I think it went pretty good. As I am incompetent to comment on any of the work items or faults, the team members were talking to each other and not to me – excellent (I think there is far too much SCRUM MANAGING going on). After the daily scrum we discussed a little about the fault situation and how to make the work visible. Since the team preferres (for some reasons which are beyond my understanding – more clarification and digging is needed here) to use some kind of electronic way to control their work we also agreed that team members update this table in the wiki page before the daily scrum, so that the team can see how the burndown looks like. Yes – small improvements indeed – however they are coming from the team / the importance is acknowledged by the team and its not coming from ”upper management”.
I had some coffee table discussion with other scrum masters and one thing became obvious: the organization is learning and improving. The problem seems to me that it does not happen systematically (enough) neither is the improvment not always in line of thought with Lean, Agile and Scrum values and principles. I drew an illustratation to explain my point:

So, I see two main issues: (A) the underlying assumptions change and the solution does not change and (B) during the solution creation process, there seems to be little if no reflection on whether this proposed solution is in the spirit of Lean and Agile values and principles or not. To tackle point (A): in an ideal solution, the decision making – which typically happens after the thinking period – would require from the decision maker to state all the assumptions expressed in the decision making process. By doing so, those assumptions would be visible and recognized. It requires a certain discipline from the decison maker to maintain a high quality of documentation. On the other hand, it will be relatively easy to spot the change in those underlying assunmptions and thus the decided solution can be questioned more easily and also people can put their arguments based on facts i.e., the document assumptions. (this is nothing new for anybody who has read basic literature on decision making theory, however it seems that organization often do not have time to document those assumptions. So I simply assume that people do not know about that and somebody needs to tell them and then we see what happens). Item (B) is more tricky. It comes down to the question: How do you know that you do not know? (bounded rationality is one of the topics in organizational theory and is part of Transaction Cost Economics Theory). Also in this meeting with the APO I recognize this trap has once more closed. Hey – wait a moment. How am I to say that I obviously know better then the others??? Well, lets put it this way. This is not the first group I observe. Because of the public nature of this blog, I am also not willing to reveal more details on what exactly happened. The issue is that time is pressing and I hear statements like: ”we need to push on”, ”we do not have time now to think this more”, ”we must make a fast decision” (see more later what happened to me personally). A group of 16 people will have at least 17 opinions – each individual plus the group's opinion ( as a whole). Most likely there are several sub-groups which have an opinion as well. Sam Kaner illustrates this nicely in his book ”Facilitator's Guide to Participatory Decision-Making”. His first chapter can be copied (with some limitations of usage), so I recommend to get a book, copy, spread and start reading the first chapter. The group was simply too big to make any meaningful sensible results (IMHO!!!), neither was the discussion using a systematic problem solving method (such as A3). Dividing the team into smaller groups and applying a systematic problem solving method might do good. Give it a try!
I try to illustrate the issue with problem solving from a different angle. Every person looking at a problem has her own view. As a result of that every person creates a different solution going into different direction. Person A does not understand why person B is proposing such a solution (i.e., solution B) and thus, person A might not only ignore solution B but even boycot it (maybe more maybe less actively).

IMO a common understanding of the problem is missing, a common decision on the one solution to try out. This does not mean that the solution will work! Neither should anybody mix this with consensus. There was a sense-making explanation of those concepts in Patrick Lencioni's ”The Five Dysfunctions of a Team: A Leadership Fable”.
And this is how I try to illustrate the common understanding incl. the common solution (maybe shared point of view and shared solution would be alternative terms).

I think this is also one of the key elements in A3 – by doing the GEMBA, the author and the counterparts will get a common understanding of the problem, its root causes, the goals and as well as the proposed solutions to fix the root causes.
Anyway, this was the first meeting of its kind and I will meet the APO next week – so lets hope we find the time to discuss some of that and get a common understanding on what is problem with the quality-problem-solving. I got some really good feedback from the problem solving workshops which I had two weeks in China. Obviously I like the topic ;)
Stay tuned for me ...

Oh boy – am I in trouble with my blog or what? The vicious cycle of large batches and delays!

What the heck has happened? This guy writes only 5 posts and claims to be in trouble already? What a looser! - or?
Here is the deal. Yesterday happened many many things. In fact, the day had been so busy that I was not even able to capture all observations properly. I only took some quick notes. Then I started to write the blog. I want to write a high quality blog, with meaningful insights from a learning point of view … from a scrum master's life point of view, as few typos as possible, no missing words. The post which I planned to published yesterday grew bigger and bigger. I wanted to include some illustrations (some which I did in courses by hand but never put into electronic format). As a consequence, I was not able to finish the blog yesterday evening. So I started to be late. Well, I thought no problem, I do right away today morning. And what happened today? In the morning I wanted to do more preparation for my first workshop with the team. There are a few other items I need to care of because of the end of the fiscal year i.e. I want to get some money back from the company. So, again I had no time to write the post. We had the workshop (more about it later) and more observations – more illustrations came (read in product development: more features!). Instead of publishing my unfinished post (I do not want to sacrifice the quality of writing – oh yeah, it could get much worse then this ;) ), I decided to wait and I can add the new observations in an even bigger post. We had our daily scrum and after that there was a short discussion on some practical stuff. I regarded it as my job to take care of those actions, so I had no time to think about the post and the post got delayed again. The afternoon went by and more impressions occured and now?? Help – I AM STUCK IN OPERATIONAL WORK and have NO TIME TO REFLECT on what is happening around me anymore (more about this later). I am in a vicious circle. Big batches lead to delays. Delays lead to bigger batches. Bigger batches lead to even more delays. Read any basic book about batch size, queues and this starts to sound familiar - or? What will I do now? I will produce smaller batches i.e., smaller posts and most likely this means, I will release more often. Wow – what an experience! Since this takes extra effort – I will do some overtime tonite, take a glass of German ”Glühwein” and start typing.

Monday, December 19, 2011

Zero day – what a fantastic start...

Its Monday and today was my first official day as a scrum master. I had great fun! In the morning I had my first encounter with different people from management around the coffee area. My problem with management discussions in the past has been that whenever the discussions come to (what-I-call) difficult subjects, people run away to urgent meetings etc. Some of my colleagues suggested to write an application for the mobile phone so that once you push the “help” button, the phone will ring – simulating a phone call – the person answers and has official permission to “go away” because of this important phone call. Is it then so difficult for people to say e.g. sorry this discussion bores me or I do not care??? Ok, I can see the problem here. Those kind of answers would put even more petrol in the fire and give me a chance to dig even more… I am learning. So once my discussion partner indicated that she becomes “irritated” I thought it’s better to slow down, so that there remains an opportunity for future discussions. Anyway, today was sprint planning day. Sprint planning part I started, the Area Product Owner presenting the work items and the teams confirming which items they take in as a candidate for planning. So far ok and now … what happened to sprint planning – part II? Strangely enough there was no official sprint planning – part II for my team. I am truly puzzled! What is the team’s sprint goal? How does the team know what it can forecast in this sprint? How does the team handle the balance between new feature development and maintenance work? OK, I took a deep breath and suggested to the team – how about if we spend a little more time on planning the work items, so that the team could give a better forecast on what can be done in this sprint. So, we went into a room and looked more deeply at the items, discuss them a little further and clarified also what other work the team will face during this sprint. The team is in its current composition only 2 months old (did the team ever receive basic scrum training? Did the management ever inform people WHY Scrum is followed?) and rather heterogeneous from e.g. competence and personality point of view. A true challenge for me and I hope I can teach the team to take advantage of their diversities. In the end, the team was able to agree on the content of this sprint and the planning meeting was concluded.  
The issue that hit me most today is the people’s ignorance to the power of visualization (and this happens in several different incidents). Once you have seen the power of a Scrum board (incl. burn-down chart), how could you go back to excels and wikis etc. hidden in some file server or similar system. However, in this endeavour, I am already facing a fair amount of resistance and consequently the accompanying “band-aid” solutions. I think I will be busy during this journey :)

Saturday, December 17, 2011

D-Day -1 and counting

I met the team last Thursday and we had a very quick introduction – the eight team members, the current scrum master and the line manager of the team were present. I got to see their team area, the backlog, my future place and where a few of the managers are sitting. Yesterday, I already participated in the sprint review and retro just to observe what is happening and to see what are the practices and unwritten rules. I also met the head of the program managers and the head of the R&D – both known colleagues for many years. Both said that they were happy to see me here and they look forward to here suggestions and comments from me. Even my cynical comment “are you sure?” could not shock them, so lets see what will happen. The doors are open. There was supposed to be an announcement that I am coming, partly because I know quite many managers in that organization and I hope to get them curious and willing to contact me – otherwise I will need to “hunt” them – well, might be also fun to see how that goes. Impressions and observations from those two days …. Oh boy …. WOW – I have not even started yet and I already filled my first A5 page with issues which would need some attention (I like to term issue – its maybe more positive then problem  – got that from Kanban material). Here are some examples: (a) the distance between team working area and team space (here is the e.g. backlog) is 75 steps (those high quality steps as teached by Bas & others in the CSM course!) or the shortcut is 35 steps through a door and through an office area which looks like a storage place (this space is reserved for consultants).  (b) The sprint review is basically only the demo and (c) the sprint retro lasts 30min (how can 30min be a enough for a team of eight to do a meaningful retro ???). (D) a so called “user-story” starts with “as a user”; so it’s not a user-story after all as the user is not determined. (E) Multiple stakeholders seemed to interrupt the team/individuals during the sprint. And more items which I do not fully understand yet what is the issue behind. I also did not see any Issue/Impediment backlog – and unless I find one next week, I will create one. So folks – stay tuned – on Monday is Sprint planning :)

A personal challenge

Learning is great and it might be a little spooky as well. I have been some kind of trainer/coach/consultant for the past eight years. I enjoyed a very independent work style – I mean who cares whether I prepare my training in the day time or nite time? So I am used to a huge flexibility which allowed me to take care of personal needs easily and e.g. meeting colleagues from other parts of the organization  or other companies was relatively easy. When I wanted to get some work down (read being creative) I typically did that at home or somewhere else in an inspiring environment and not in our cost-efficient Flexispace-office. I live in country-side and thus I have a relative long way to the office. So far I was able to time meetings and work in such a way, that I could be back at home when my wife needed the car (yep – we managed so far with one). And now? Well, as scrum master, it does not do very well to call the daily scrum via remote, neither will problems get solved from the distance – consequence: I need to go everyday to work and tease myself through the morning and afternoon rush-hour. There is a possibility to go by bus – takes at least double the time with changing bus 2 times and enough of walking. Why am I telling this to you? I thought this change in work-style is truly significant and thus its worth sharing with you. Well, I am no victim of my new environment – so I am prepared to ride my motorbike with sidecar in case there is a conflict with the vehicle ;)

Thursday, November 24, 2011

Preparing for the new job

Even though I have been giving many trainings in lean, agile and scrum - its a different story to actually become a SM. Anyway, team members might wonder what a SM is doing the whole day and JIT, Ismo tweeted this link: 
42 tasks for a scrum master
a good start for me :)

Strangely the default seems to be that a SM is not a full-time job and I witnessed various set-ups and consulted some organizations: I found the following combinations with pros and cons:
PO = Product Owner, LM = Line Manager

Monday, November 21, 2011

My experiment to be a Scrum Master - taking the red pill ....

I coached a group of scrum masters the other day and I felt like I am on a different planet. Somehow it appeared there was a huge gap between the theory on how it should be and the reality of those scrum masters. So what is wrong here? This has really bugged me so I asked my boss whether it would be ok to be a scrum master for a limited amount of time. She was all for it and saw it as a great learning experience. Then I asked the line manager of the scrum masters and he also got all excited about my proposal. Well, it looks like the team, their scrum master and the corresponding line manager gave their GO. I am really looking forward to this. BTW, thanx Ismo for inviting me some long time ago and trying to make me take the red pill already earlier ;)
In the next weeks I will give my already agreed trainings and fulfil other commitments and then its time to get real :)

Stay tuned for more ....