In the last year, I have been reflecting a lot on the decisions making process.
Not specifically how I make a decision but how people are making decisions in general.

The question that often bubbles in my mind is WHY, why I made that decision, why my colleague took that decision instead of the other one, why that person is approaching that problem from that angle.
Sometimes I really struggle to understand certain decisions made by people and this is not necessarily a bad thing but it made me wonder.

I started giving an answer to the following questions:
Why don’t I understand that decision?
Why my decision would differ so much from another person?


Context, yes… context.

The definition of “context” provided by Google is

“the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.”

I think the keywords for understanding the meaning of context are circumstances and fully understood.

Let me share a story with you.

A few months ago I was in a meeting where some colleagues were proposing an idea for solving a governance challenge that from my point of view wasn’t fitting the purpose.
I listened, elaborate in my head and I asked a few questions but I didn’t share my opinion at all.
I spent the following hours rethinking that conversation, every single word was echoing in my mind trying to find a sense of the solution proposed during that meeting.

After a day or two, I replayed again in my head the entire conversation several times and I tried to explain how I would have solved that problem from my perspective for seeing overlaps between the two solutions.
During this mental exercise, what I realized was that from my colleagues perspective, in their own mental model the solution was absolute fine, my point of view was different from theirs, not necessarily better or worse.
I realised I was analysing the problem adding different dimensions and information that allowed me to find an angle not explored by the others due to the lack of context on how the architecture, the implementation and the governance would have worked all together.
The circumstances weren’t fully understood, more than that, the circumstances weren’t shared, we weren’t thinking about the same solution because we had a different context.

Context is everything.
Think about it.

In software architecture, a successful architecture may be replicated in another organization with a completely different outcome (positive or negative).
Have you ever asked yourself why?
Because the context is different, the players are different, the interactions, communications, environment, the governance are all different.

In an Architecture Decision Record (ADR) we usually capture a decision made along with its context and consequences. Often these decisions are revised in the following months because the business evolves and therefore the architecture has to evolve alongside the business.
What we decided six months may be obsolete right now.
This doesn’t mean we took the wrong decision at that time, but with the ADR we are trying to capture WHY we took that decision in a specific moment in time, drawing metaphorically what was the context of the architecture, the forces and the solutions evaluated for being able to reassess them on a later stage and bring everyone inside the organization up to speed on the what reasoning process we applied behind a specific decision.

I don’t think we can change the fact that context can dramatically modify the outcome of specific actions for better or worse.
There is although one thing we can definitely do, learn more about the context we work for providing the right solutions and take the correct direction. More we know, better we can think about the possible consequences.
Moreover, we need to invest time creating a common context in our company, despite we work in a large or small organization, often the context where an architect or a developer operate is completely different from the one of another colleague in the marketing team.
It doesn’t matter if we work in the same organization, the reality is the context for people in a different department, even different teams, may differ substantially.

A thing I learnt in the past few years is not stopping in front of a decision made but challenge or be challenged in a genuine way.
When I design a new architecture, I usually socialize with developers, with the principal engineers and the other architects.
What I’m looking for is feedback and validation of an idea, but more often than not I gather the point of view of different people, how they would solve the same problem from their perspective, with their experience and expertise.

It shouldn’t be a problem changing your mind after gathering more context, people may judge you because of that, the reality is they have just collaborated on enriching your knowledge, augmenting your context and making the solution you are working on better than before.

Therefore engage with your peers in a meaningful way, especially the ones outside your teams, engage with product people, senior management, stakeholders, architects, other developers, other departments even.
Don’t be afraid to leave your bubble but explore outside it. I know it sounds easier than what it is, but remember…

More context we are able to gather, better decisions we are going to make!

Don’t be afraid to ask WHY, to understand the value behind a decision, to understand the train of thoughts a person holds, because all of these actions provide you with more context enabling you, in the long run, to make better decisions or understand better the point of view of another person.

Tech people often research online, study books, watch videos, listen to podcasts, dream about the implementations made by other organizations, and I’m one of them.

However, the next step after a research is contextualizing the learnings in our own environment.

Contextualizing… context again.

Replicating 1 to 1 what we have learnt, may or may not provide the same outcome inside our organization.

Funny enough a few days ago, I was listening to a podcast episode on Domain-Driven Design (DDD), the speaker was sharing his experience of implementing DDD in two different companies.
The first time was a complete failure, they made several mistakes due to lack of experience in applying DDD breaking the services in very small units and ending up with a “distributed monolith”. The company closed a few years later.
In the second company although, the same person gained experience, reviewed his mistakes and applied with his new colleagues a similar approach avoiding the pitfalls he learnt from the previous experience.
It was a complete success, he learnt from his mistakes, he capitalized his experience and, with a different context, DDD was successfully implemented.

There are plenty of stories like this one out there of achievements and defeats, two sides of the same coin.

Every time we write a line of code, every time we design a new architecture, every time we introduce a piece of infrastructure, we should be able to answer the simple question WHY we are doing this.
I learnt by experience this answer is not always easy to provide.
Maybe we want to try a new approach or tool, maybe we thought that specific approach would make more sense over another, and there isn’t any problem on this but let’s spell it out, explain why we do things in a certain way and if we don’t have a specific reason, try to find it because it will help yourself and the people you are working with to follow your idea better and rationalize the decision in your heads.
Don’t be afraid of sharing your reasoning, the worst-case scenario is that you learn a bit more about the context you operate.
Having an idea turned down is not a defeat, instead, it’s a great win because it means next time you will be able to add a new dimension on your ideas that would make them more contextual for the environment you work with.

Context means also that there isn’t always right or wrong, black and white, right and left. There isn’t the absolute truth!
Often I see developers stack with their position because an “influential person said that” or “John Doe tweeted about it, so if he said that…”.
However, it may be applicable only to certain contexts. We should challenge ourselves and our beliefs from time to time, looking for different opinions and different point of views to have a better picture of how people may approach the same challenge differently from us. Embrace a different perspective and don’t push it back up front.

Next time you are in a discussion with a colleague or a friend, try to move a step forward finding the reason behind a particular decision or behaviour.
And then try again, and again.
Interacting with people, asking questions, sharing your thoughts or reasonings, will expose yourself and maybe sometimes put you outside your comfort zone, however, it will add to your personal growth an enormous value and more food for thought to reason about.

Context is not immutable, many people when they join a new company have a lack of context but that doesn’t mean they will not have it unless they are not looking for it.
I truly believe human beings are curious by nature, our passions drive our curiosity pushing the boundaries when we really and deeply love what we are doing.
In these cases, these people are going to look for creating quickly the context for making what they love valuable again.

I personally started to see the world with different eyes, I am trying to understand more the context where a specific architecture, implementation, decision or feature would be applied more than solutionize upfront.

I don’t believe there is always a solution that fits them all. And “the standard” is not applicable in every context.

I decided to believe in accepting failures for improving an empiric world called software development, in learning from failures and successes, in human interactions, in growing without limits, in understanding better the context before providing a solution, in a wrong decision made for lack of context, in listening and providing context, in challenging and being challenged, in starting with the WHY more than the HOW, in looking for the context no matter where I’ll find it.

It took me a while to gather my train of thoughts and decide to share them, it may be valuable for some of you or not.
Hopefully, you will find some interesting angle in these few words.

Thank you.


Leading Lean Software Development: book review

It’s a long time that I don’t share thoughts regarding a book that I’ve read, but this time it’s totally worth the effort to write down this blog post.
I used to read between 15 to 20 books per year during my commuting time and I really enjoy the different points of views of the authors and it’s fascinating how the same topic can be treated in so many ways.

Leading Lean Software Development

The book that caught my attention is called Leading Lean Software Development from Addison Wesley.
I read many books on Lean and Agile topics but this one, I’ve to say, it’s one of the best for people like me that works in software development with these methodologies.
I strongly believe that there isn’t a framework that could rule them all, so I love learn and try different approaches like Scrum, Kanban, Kaizen, Grows and many others outside there and catch the essence in order to use the best technique when I need it.

This book does exactly that, it’s not only emphasising the importance of Lean methodologies but it’s mixing Lean methodologies with software engineering practices and give many example how these techniques helped to succeed not only in the software industry but also in the “real world”.

The most stunning example is regarding how the Empire State Building was created in less than a year and how it’s possible to have the same efficiency in the software development!

There so many take aways inside Leading Lean Software Development book that it’s hard to share all of them, but I think it’s a great collection of my believes in the Lean and software development world.
For the first time I could say that I’m represented by a book!
It’s a MUST read book in my opinion and the most interesting part is that there is another book written by the same authors way more practical that I can’t wait to read: Implementing Lean Software Development.

I hope you’ll find the time to read them and if you want to share other books with great value just leave a comment

Git Flow vs Github Flow

Recently I’ve spent time to study a good way to manage a software projects with GIT.
I really read a lots of blog post to check different points of view and to find out which is the best technique to use in different situations.

The principals ways to manage a software in GIT are: the Git Flow and the Github Flow.
These 2 methods can really help you to manage your project and optimise your workflow in the team.
Let’s see the differences between them.

Git Flow

git flow
git flow

Git flow works with different branches to manage easily each phase of the software development, it’s suggested to be used when your software has the concept of “release” because, as you can see in the scheme above, it’s not the best decision when you work in Continuous Delivery or Continuos Deployment environment where this concept is missing.
Another good point of this flow is that fits perfectly when you work in team and one or more developers have to collaborate to the same feature.
But let’s take a look closer to this model.

The main branches in this flow are:

  • master
  • develop
  • features
  • hotfix
  • release

When you clone a GIT repository in your local folder you have immediately to create a branch from the master called develop, this branch will be the main branch for the development and where all the developers in a team will work to implement new features or bug fixing before the release.
Every time a developer needs to add a new feature he will create a new branch from develop that allow him to work properly in that feature without compromise the code for the other people in the team in the develop branch.
When the feature will be ready and tested it could be rebased inside the develop branch, our goal is to have always a stable version of develop branch because we merge the code only when the new feature is completed and it’s working.
When all the features related to a new release are implemented in the develop branch it’s time to branch the code to the release branch where there you’ll start to test properly before the final deployment.
When you branch your code from develop to release you should avoid to add new features but you should only fix bugs inside the release branch code until to you create a stable release branch.
At the end, when you are ready to push live deploy live your project, you will tag the version inside the master branch so there you can have all the different versions that you release week by week.
Apparently it could seem to much steps but it’s for sure quite safe and helps you to avoid mistakes or problem when you release, obviously to accomplish all this tasks you can find online a lots of scripts that could help you to work with Git flow in the command line or if you prefer you can use visual tools like SourceTree by Atlassian that make the dirty work for you, so you have to follow only the instructions inside the software to manage all the branches, for this reason I’ve also prepared a short video to see how use this flow with SourceTree

You can go more in deep about this flow reading these 2 interesting articles: nvie blog or datasift documentation.

Github Flow

Screen Shot 2014-03-08 at 23.07.36

So now, do you think that Github is working with Git Flow? Of course no! (Honestly I was really surprised when I read that!)
In fact they are working with a continuos deployment environment where there isn’t the concept of “release” because every time they finish to prepare a new feature they push live immediately (after the whole automation chain created in the environment).
The main concepts behind the Github flow are:

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie:new-oauth2-scopes)
  • Commit to that branch locally and regularly push your work to the same named branch on the server
  • When you need feedback or help, or you think the branch is ready for merging, open a pull request
  • After someone else has reviewed and signed off on the feature, you can merge it into master
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately

I found an amazing interactive page where you can deepen the knowledge of this method, but I see it’s very common when you work in QA teams, small teams or you are working as freelance because it’s true that is a lightweight flow to manage a project but it’s also quite clear and secure when you want to merge your code in the master branch.
Another good resource about Github Flow is the blog post made by the Github evangelist Scott Chacon.
I recorded also a video on how to use Github flow with SourceTree:

If you have any other method to manage your project in GIT feel free to share because I’m quite interesting to see how you usually work with GIT and if there are better ways to work with and if you have any other feedback or question I’m here for you!

Product Owner, Scrum Master and Team: this is Scrum!

As you read in my previous post “Approaching Scrum”, in the short description of this Agile technique, I talked about  3 main roles that composed the Scrum team.

The main 3 roles are:

  • Product Owner
  • Scrum Master
  • Development Team

There are also other people that partecipate in a Scrum team and I’ll talk about them in a bit.
I’d like to share a brief introduction to each role before talk, in another post, about the Scrum process in details.

Where is the project manager ?

That’s a good question, as you can see above in the list of the main roles, the project manager role is not mentioned.
Basically what the project manager represents in the traditional software development where basically manage the communication between clients and the company, manage the team’s tasks and so on, in Scrum we are dividing those functions trough the members of the Scrum team (product owner, scrum master and development team) giving more responsibilities to them.
This thing will have a positive impact with the whole team that is more involved in each part of the project (planning, decision and development) and they can drive the risk using Scrum to achieve the best business value so the best result for their customers.
Another important aspect to take in consideration, when you are working with Scrum, is that we don’t have the concept of “project” anymore, but we’ll work on features and improvements with a continuos delivery instead of a “big bang delivery” at the end of the project.
This will ensure that we’ll focus more in the business value instead of waste time in something that is not important for that project and that couldn’t have the right value for our stakeholders.
For my perspective a natural evolution for a project manager could be the product owner, or if he has got a technical background could be Scrum Master; for sure the most important thing is that he has to change the way to approach any development and he has to think in a collaborative instead of a hierarchical way.

Product Owner

This role is very important inside a Scrum team, in fact the product owner is the “voice” of stakeholders and customers or users.
He is also the person that has the product vision, that is in charge to take the right business decisions during the development of a new or existing product and he has to help the team, if it’s possible everyday, answering on questions related to the product.
He is in charge to create and maintain the Product Backlog and to share the product vision with the whole Scrum team.
The most important thing is that the Product Owner is always available for the team because he is part of the team and his role is essential to accomplish all the business aims of a project.
In fact he is in charge to order the activities to do in the Product Backlog and to update them (this process is called grooming) following the customer’s perspective.
Usually the Product Owner is someone that have familiarity to talk with customers or internal management as well and he is quite technical to talk with the Development Team.

Scrum Master

The perfect definition of a Scrum Master is: “Mr. Wolf” !
The Scrum Master is the person that try to facilitate the use of  Scrum inside the team, he has to remove impediments to the Scrum team, facilitate Scrum introduction in a new team,  avoid any external distraction to the Development team and so on.
The key concept for any person that is approaching this role is that you are not a chief of someboy, you are coaching Scrum to people not imposing something to them!
In fact another good definition of Scrum Master is the servant leader.
Usually the Scrum Master is a Lead Developer or a QA person anyway it should be someone that has got enough technical knowledge to understand and solve the problem of the Team and to discuss with the Product Owner and guide him to create good artifacts for the Scrum team.
This activity required more or less the 50% of the time for a person so usually the Scrum Master is often member of the Development Team as well.

Development Team

When Scrum talks about Development Team it doesn’t mean only developers but a group of people that work actively to the product.
So inside the development team we can find: analysts, designers, testers, UX team, developers and so on.
In Scrum the team has cross-functional skills that allow them to deliver feature every Sprint.
Another important thing is that the team is self organised so nobody (nor the Scrum Master neither the Product Owner) can add activities to their daily job or impose the timeframe to finish a task.
At the beginning it could be so strange but in this case people in a team assume more responsibility and the project will be done in the best way ever.
In the old way to manage a team where the project manager imposed his role to have the feature that he wants when he wants, the team was only executive people without any relation with the project and often without any reward if the project will be well done.
In Scrum the team is in charge to estimate the project, to choose the task to accomplish during a Sprint deciding them with the Product Owner and, last but not least the team has to develop more features as possible with an high quality of code (tested, documented and so on).
We’ll talk more in deep about estimates and about the “definition of done” in next posts for now what you need to know is that the team is not passive anymore but they play an active and important role to achieve the goals of each product.

Other actors

In Scrum the main roles are what you have read above but there are many other people that partecipate to the good delivery of a product, in particular when you start to scalate Scrum to many teams.
In fact Scrum is a framework to manage 1 or 2 teams but not more, there are many other Agile frameworks that help you in this activity like SAFe (Scaled Agile Framework).
Other people that partecipate to the delivery of a project are for sure the stakeholders.
Stakeholders can be internal or external, when we refer to internal stakeholders we have to think to our management that share with the team their needs and how their point of view to improve or change the product developed by the team.
The external stakeholders are our customers or users, yes you read well, our customers or users are very important in the Scrum process because they are the ones that decide if the project is going in the right direction or is failing.
Personally I think is the biggest challenge involve our customers inside the Scrum process but for sure it will be very useful for the team and the product because they can constantly give us feedback on the right direction to take with the product.