Playing with software architecture in a Space Opera

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.
Continue reading

Advertisements

Clarifying the expectations.

sherlockAlong 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”.

Continue reading

The padding’s attitude

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.
And suddenly…«GUYS!».
Everyone stopped.
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

Matter of Metrics and Improvements (how it started!)

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.
Why?
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.

Continue reading

A London-Turin retrospective

sherlock 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.

Continue reading

About User Stories

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.
Continue reading

Definition of Done

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.

Continue reading

No problems means Problems

Deal every day with problems is tiresome, sometimes frustrating (click here to have a taste of it!), but for me the real problems start when I don’t have any problem.
The sprint retrospective is a perfect time and place to deal with problems, but what if the sprint went well and no one has to complain?
Or what if more sprints went well in a row?

Well, when a new team starts there are a lot of problems, but after few months it is not so strange to have a period where everything goes in the right way: your software is growing well, your Stakeholder are enough satisfied and the team found the right rhythm.

If you have this kind of period there’s a chance that your retrospective become useless, boring and, like it happened to me, you begin to ask to yourself: and now? Continue reading

LKSE 2014 meeting: thoughts the day after (…almost)

The May 30 I participated at the Lean Kanban Southern Europe meeting in Bologna. The experience was great, very inspiring and when I came home I was tempted to change the schedule of my blog and to post a report of it instead of the post on “pawns and tiles”.

At the end I preferred not to rush and take my time to metabolize what I learned.
I have to warn you that this post probably won’t come to some resolution, it’s mostly free thoughts I like to share.

LKSE2014 banner

Continue reading