Graphics are always something that catch my eye and make communicating ideas more compelling to my mind. Whether decorating a text or completely illustrating a concept with an image, I think it strengthens the impact of the underlying message.
One of my favorite demonstration of the increased impact drawing ideas can have is the RSA animation of Dan Pink’s Drive talk. I’ve also seen the impact in brainstorming sessions when graphic facilitation techniques are used by the group.
As well as I was convinced of the graphic facilitation power as a tool, I was also convinced, alas, that it’s not something I could do and get the benefits.

I came across the Coursera’s Learning How To Lean MOOC while checking the list of the 50 most popular Moocs of alltime. On that list, Oakley’s MOOC was at the number one position. I was a bit surprised at first to see this kind of MOOC being the most popular, but after a second thought my surprise vanished. After all, isn’t the audience attending MOOCs supposed to be genuinely interested in learning? In some way that was a confirmation.

Beside the fact that it caught my attention, the title intrigued me. For the past years, I’ve never stopped learning new things every day, and my interest in learning has only grown more with time. I believe life to be a journey full of an infinite amount of learning, and the challenge reside in learning the right thing, in the right way. The MOOC seemed to unlock the secret on becoming an effective learner, and that was more than enough for me to enroll.

On the 16th of October 2017 took place the O’Reilly Software Architecture Conference in London. During the first two days, I attended to keynotes and talks where the speakers shared their learning and thoughts on software architecture, architects roles, architecture documentation, developers skills both technical and soft.

If you’re in the enterprise software development space, you’re probably aware that two types of categories of businesses exist out there, the ones that have a micro-services architecture and are practicing continuous deployment, and the others struggling to get there, dealing with their fat old monolithic application. Clearly, the monolithic architecture is still heavily present in the industry and the move towards modularity is still a case by case challenge.

What I heard in the talks and during my discussions with the experts, surprised me and reassured me at the same time. When it comes to breaking down the monolith, all seemed to agree on a common approach, a pragmatic approach.

It started in the key notes, with Mark Richards using the Steeplechase metaphor to explain how companies should move towards micro-services.

When deploying lean and agility a lot of recommendation exist on how to take care of your collaborators during this change process.
In the literature, agile experts insist a lot on the necessity to pay attention in giving the right level of empowerment to teams and individuals. Teams are encouraged to self-organize, to take things in hand and work actively on improving their deliverable and their process.
Moreover, management is asked to provide a safe environment that foster experimentation and give the team the right to learn from its failures.
The manager role is banished in all agile frameworks, and rather replaced by team supporting roles, such as Scrum Master and Product Owner in the SCRUM framework. These new roles are rather focused on helping the team reach its goals in a servant-leader manner.
All this looks great, self-organization, empowerment, decentralized decision making … teamwork sounds great in an agile world, but unfortunately there’s a caveat.

In his book, Turn The Ship Around!, L. David Marquet tells us how he transformed the culture of a united states submarine from a leader-follower culture to a leader-leader culture.
Moreover, he proves the benefits of this cultural change that made the submarine crew improve from the least to the most effective one.
While reading this book, thing that I enjoyed and recommend, I couldn’t help but projecting the ideas explained in the book against my experience with agile software development teams and more specifically the SCRUM framework usage. The book made me see the different practices and principles used in SCRUM under a new and interesting perspective.
I’ll try to share this with you in this blog-post.

Agile teams are known to be autonomous and self-organizing.
When I started fostering agility and encouraging autonomy and self-organization for the teams I work with, It was only normal to to face a situation where teams decided to do things their way, under the name of autonomy and self-organization.
The problem was that the direction they were heading in was not going to lead to the collective success of the enterprise.
My role was to help them succeed, thus I had the challenge of directing them while helping them improve their agility and thus their autonomy and self organization.
Is that an impossible equation to solve ?

T-shaped skills or persons is a metaphor for the depth and breadth that an individual has in their skills.
It was first introduced by Tim Brown in 1991 as a method to build a workforce of interdisciplinary individuals for creative processes.

The vertical bar on the ‘T’ represents the depth of related skills and expertise in a single field, whereas the horizontal bar represents a breadth of skills and the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own.

If you’re reading this you probably have good understanding of agile teams characteristics. So you know that agile teams are not just a group of individuals working each one alone, on their individual goals or within their area of expertise.
And that Agile team members share common goals, work together, and support each other in achieving their commitments, in a all the team succeed or all the team fail spirit.
Finally, Agile teams are self-organized and their day to day activity involve increased communication and collaboration.

But you might be wondering what make agile teams reach top performance and effectiveness. Interested to know ?

Continuous improvement is one of the necessary pillars when it comes to Agile.
Failing to improve your process won’t let you unlock its full potential nor reach the benefits promised by Agile.
But whether you’re practicing agile or not, I’m bet that you do care about improving what your doing.
Identifying things to improve can be done by conducting a retrospective session.
Retrospective is a special meeting that takes place at the end of an iteration or a project.
It is a dedicated moment where the team take time to inspect the work done and try to spot opportunities for improvement.
Planning and conducting retrospectives is not hard, but some pitfalls might prevent you from getting out the desired outcome. Read on to know what are the 6 things that could ruin your retrospectives.

While attending to a 2-day course on Management 3.0, on of the new things I discovered was the “solution focus” approach to improving things. Googling on the matter I learned that this technique come from the “Solution focused brief therapy”.

In a solution focused brief therapy (SFBT) the patient is asked to focus on solution-building rather than problem-solving. This can be achieved by exploring current resources and future hopes rather than present problems and past causes.
First thing that popped to my mind when discovering SFBT, is its similarity to an agile retrospective.
Retrospective main aim is to spot improvement opportunities and come up with actions to make things better in the future.

I’ve been conducting and participating to retrospectives for several years now, but unlike SFBT, we were often digging to identify the root-cause of problems and then trying to figure out solutions.
SFBT opened a new perspective for me. Finding the root-cause in a retrospective is putting the effort in looking into the past. Applying SFBT to a retrospective implied not putting the effort on analyzing what happened but rather putting it in finding an action that can lead to a better future.

How can you do that? Here’s the simple recipe I used.