No, I didn’t die, I was just too busy to change more or less…everything in my life.
Long story short: I had to stay one year in London, but when the end of the year came I realized that maybe one year wasn’t enough for a lot of different reasons.
So I changed plan.
In 2030 a massive project were kicked-off in order to colonize new planets.
The name of the project was International Space Program.
A lot of planets had been probed looking for the best candidate of the first mankind settlement in the space.
At the end Mars won and a bunch of settlers were chosen to colonize it.
The main reason for the colonization of space was the research and the harvesting of an important resource missing on Earth: “Whatsoever” (on periodic element table: WH)
What you could achieve using the “Whatsoever” was limitless, so a lot of Companies invested on the International Space Program.
The settlers were sent on Mars in 2032 and an interspace link granted the quick send of designs, prototypes useful to build objects on Mars.
The name of this link was: New Universal Gate for Extraterrestrial Transport or N.U.G.E.T for short.
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”.
When we started 4 years ago using Scrum the PO decided to use PivotalTracker to manage the Backlog and the roadmap.
We also had a physical board for the current sprint, but we found very useful to have the virtual one.
My “wall” in Turin a couple of years ago, before we moved in a newer room.
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
I hate the metrics.
Really, I hate them.
Generally speaking now I hate any file excel in which I should put a lot of numbers.
Because years ago the 99% of the time that I took that metrics I didn’t know what to do with that numbers, I didn’t know when to use it, I didn’t know how to read it in order to be useful.
In my past experiences the metrics that I had taken were never useful to improve a workflow or avoid the same mistake.
Gathering those metrics had been only a colossal loss of time.
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.
User Stories are very central in any Agile methodology and very often are the first cause of a failure (or success) in a software development.
Speaking about User Stories with a colleague in London, I noticed like the topic is every time (no matter the Country nor the person) much more complicated than expected, mostly if you are new on the field.
If you speak about User Stories is quite simple that, at the question “How a User Story should be?”, your answer will probably be an emphatic “INVEST!”
I agree, but I’ve noticed that to apply the INVEST approach is much more hard than expected. The theory is pretty clear, but somehow not so much clear how to put it in a User Story.
I think it is a must in an agile team.
The Definition Of Done is a good starting point for a new team or a new software that a team should begin.
In fact, from my point of view a DOD is not just related to a team, but to a team bound to a specific project.
In theory every agile team should have only a software (or a part of it) to deal with, but my world is not so well compartmentalized and it happened that my team had to work on multiple software even if, luckily, not often at the same time.
In any case the point is: hardly a DOD used for a software was good enough for another software.
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.