Managing Agile Autonomous Teams : A Paradox ?

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 ?

Why Developers Need T-shaped Skills

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.

Working Agreements, a Must Have for Agile Teams

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 ?

6 Things That Can Ruin Your Retrospective

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.

A Simple Way to Run a Solution Focused Retrospective

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.

Is It Realistic to Manage Closely Several Agile Teams

I have been recently promoted to manage a division in software development department of my company.
Till then I was used to managing one team at a once, not exceeding 10 people in size.
Now I find myself with 8 teams to manage having each a size ranging from 4 to 7 people.

In my previous role I was comfortable with adopting the SCRUM agile framework and quite used to play the role of the scrum master and to participate actively to the product owner role.
Some of the new teams were already trying to follow the agile practices, some were still working with rather a traditional waterfall approach. So naturally I found myself driving the teams to adopt the SCRUM framework. I made sure to share with them my return on experience and to point out the pitfalls and the small details that can make a difference.

Fortunately for me the resistance to change was less than expected.
All the teams were eager to try the new framework and to improve their agile practices.
This is when things start to get a bit more complicated.

Beating the Meeting Run

Just one full week in my new job, that’s what it took me to experience a new kind of sport, the “Meeting Run”.
And as a good friend of mine would say, like everything there are always two sides.
In what I experienced I encountered a good one and a bad one (and no there’s no ugly one, at least not yet).