Along this year in London I’m learning how the projects are managed here, how teams are formed and dismissed, how to deal with the day-to-day activities, how to create roadmaps for projects…and a lot of other things.
Needless to say that the environment in the London office is more fluid and working with Projects is very very different from working with the Products.
I’m attending a few business classes focused on Communication and Management, nothing specifically Agile related, but very focused on the Business and the Company.
An important concept that I Iearned in these months and I’m using to re-analyze how I did before is “be sure to set and clarify the expectations”.
Let me set the scene
…at the end the Great day came, you would have had to go live in a couple of hours and the tension and the excitement were tangible. Then…something went wrong. Badly. What happened after it is not so easy to recall, the servers stopped to work and some people started to shout orders, other people started to type on the keyboard frantically or talk at the phone, someone was reporting about an accident in the server’s room, something maybe went on fire.
You were in the room, paralyzed, with the corner of your eye you were sure that someone was climbing over the window and someone else was ready to set himself on fire in the middle of the room before the End.
A terrible silence came upon the room and everyone in the room looked at that Guy.
The Guy slowly bent over one desk and pointing at the screen said
«It’s me…or there is missing a bit of padding in that label?»
What’s happened next? Well… Continue reading
Prologue (suggested theme music for this post here)
At the end of June I moved to begin a secondment for one year in our London office. One of the purpose of the secondment is to help to implement a software developed by my team in Turin.
So I temporarily dropped my Scrum Master role and I became Tech Leader of a new project in UK that had to use the new software: we went live at the end of July, but a lot of things happened even if the launch has been a success.
As working as a Scrum Master is quite possible you have to manage a lot of problems of different nature.
Your team calls them “impediments”, other teams call them “you misunderstood what I said”, other people call them “a work that takes only 5 minutes”, but in your own world they are just another problem to manage.
When I begun, 3 years ago, I was very focused on problem solving and I felt very frustrated when I wasn’t able to solve them in the best way.
Day after day I understood that sometimes my real problem was not to find the solution, but to understand the problem.
Let me explain.