Beauty & Dignity

Beauty: what pleases the senses, what enlightens the mind, what is righteous, what is just, what is truthful, what is good.

Dignity: the idea that each and every human being without distinction of any kind, by the mere fact of being born into this world, has innate equal rights such as the right to freedom and to the pursuit of happiness, and is worthy of honour, esteem, consideration and respect.


Lean-Agile Coach self-assessment radars

These slides show 3 self-assessment radars for Lean-Agile Coaches.

The first slide is based on the Agile-Coach Competency Framework by Michael K. Spayd and Lyssa Adkins.
The second and third slide come from a blog post by Esther Derby.

Feels free to comment and to question the skills, the traits, and the levels.

“Don't bring me problems,bring me solutions." Really?!?!

“The thought that disaster is impossible often leads to an unthinkable disaster.”
Gerald M. Weinberg

Modern leadership is servant, modern managers are like hosts that receive and entertain guests.
Team members have ownership and autonomy in the way, in the ‘how’, they pursue the value they are asked to create.

When team members face difficulties, they raise obstacles to management attention. And managers act on the obstacles that bubble up from the team. This follows the principle of transparency and feedback.

Are managers ready to hear about all these problems?   Continue...

Planning ÷ reacting: finding the balance

Life is what happens to you while you're busy making other plans - John Lennon, Beautiful Boy

The are things that can be planned and others that cannot be. The conundrum is, which is which?

What happens when someone

This is why it is important to find out in every moment the balance between the two, to know

Someone says that Agile is the art of finding the balance between anticipation (as e.g. panning) and adaptation (as e.g. reacting).  

An interesting final reflection: what values, principle and practices help to find a good balance, and how ?


Agile Diversity, theme of XP2014 Rome

Transcript of the lightning talk at XP2014 about:
Agile Diversity, theme of XP2014 - 15th International Conference on Agile Software Development May 26-30, 2014, Rome, Italy

Who are you?
Who am I?
What defines yourself, your identity?

 Each one of us is unique, is a distinct individual, and is different.
Without diversity there is no identity, without diversity we would be just an army of clones.

 For the only fact that we exist, we have the right to our identity, we have the right to diversity.
This is true from a personal point of view, and it's
also true in the workplace.

The company I work for, ThoughtWorks, for example actively encourage a divers
e range of people in all parts of the company, in terms of such things as gender, religion, race, sexual orientation, and the like.

Everybody has the right to love the person they love, without distinction of gender, religion or race.
You have that right. I have it too.

In Italy we know it very well, without diversity and dissent there is fascism.
That’s why it is important both critical thinking and independent judgment, otherwise we become victims of an ideology.
When someone tells you “Do TDD because I know better than you”, this is ideology. I prefer to have the right to ask why, to try and experiment, to make my own decisions.

 Diversity also means pluralism, the idea that there are several principle and value systems that may be in conflict with each other and still are useful and fundamentally correct.
Without pluralism we get trapped into tribal fights, as for example Scrum vs Kanban, Lean vs Agile, or TDD vs BDD.
With pluralism instead you can be a Lean and Agile polyglot, you can find contextual fitness for purpose instead of being limited to a 1-size-fits-all solution.

So make yourself, your dears, and those around you who you care about, a gift: recognize and accept diversity, give yourself the possibility to choose among a large rainbow of many different colors and options, and the right to change idea when you feel like it.

You’ll be a better Lean & Agile professional, a better community member, and a better person too.

Embrace change. Embrace diversity.

The nature of software quality, the complexity of the intangible

In my everyday life, here and there, I perceive humour and kindness, discipline and grace, personality and competence, easily and clearly. But when my colleague Matthew asked me to measure them, I realised that’s a whole different story.

When you ask to 10 experienced software engineers, users and entrepreneurs what bad quality is in software, they will provide you plenty of examples. Then when you ask them to define good software quality and how to measure it, you’ll easily get 10 different answers. This is because nowadays we still don't have a rigorous definition for it, and we don't even know if it exists at all.

It is not a simple problem for sure, it took about 27 years to Tom De Marco to realise the nature of this complexity.
It was 1982 when Tom De Marco wrote in Controlling Software Projects the famous quote “You can't control what you can't measure”. In 2009 Tom De Marco wrote the article Software Engineering: An Idea Whose Time Has Come and Gone? for the IEEE Software journal, and there he wrote  "do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.”

So why is so difficult just to define and measure software quality?
Maybe because
- quality perception is subjective
- quality is in part in the eye of the beholders and in the eyes of engeneers
- quality can be relative, for example can be superior or inferior to a competitor’s product
- quality is contextual, it is fitness-for-pourpose, depend on the context and on the person that judge it

In the end the problem of defining and measuring software quality can be like the problem of predicting the future: when software engineers create new and unprecedented software applications and are asked to figure out how do it right at the first time, without exactly knowing what ‘right’ will mean.

Now that you know the nature of software quality, how do you deal efficiently with that ?

One suggestion from Jim Highsmith: do not focus on what is easily measurable and than ignore important characteristics that are harder to quantify !

Self-organisation without self-regulation, a recipe for chaos

This post is from the series of posts on Self-Organisation.

First time I experienced an Agile lego game it was playing the Leadership game: we had been asked to form 3 teams and then we had been given a goal to pursue. We worked in time-boxed iterations, and at the end of each iteration we reflected how to become more effective, even with the freedom to move to another team if that could be more useful.

In other words we had been asked to Self-Regulate: team members have early and frequent feedback in order to perceive the connection between actions and the consequences and based on that react and adapt their behaviour and their actions as needed to reach the desired goal.

Self-Regulation is a required element for a well functioning self-organisation. Indeed one of the principles of the Agile Manifesto state:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Lean principle Amplify learning suggests to increase feedback via short feedback sessions to support the continuous improvement, to better understand customers and project's needs, to learn how to better satisfy those needs and so adjust efforts for future improvements accordingly. Kanban is a Lean tool that helps here in many ways.

Why it’s  important to reflect, as individual and as team, at regular intervals?
This is because when our actions have consequences beyond our learning horizon, it becomes impossible to learn from direct experience.

What it means to become more effective?
For a team it means for example getting better in 
  • Completing team projects (i.e. quantity, rate and quality of the outcomes)
  • Fulfilling member needs (i.e. rewardingness from membership or from a member, commitment from members and to members)
  • Processing information and generating meaning (i.e. contribution of information from members, proportion of information held in common or uniquely by single member, proportion of information relevant to the tasks or socio-emotional)
  • Managing conflict and developing consensus (i.e. distribution between task and procedure and interpersonal conflict, expressed versus unexpressed conflict, escalation and de-escalation dynamic, level of implicit and explicit consensus)
  • Maintaining the structure and integrity of the team as a system (i.e. team social and task cohesiveness, patterns of interaction, of influence, of participation and of affect)
  • Motivating, regulating and coordinating member behavior (i.e. behavioral coordination about team norms and about errors and its speed/delay of the feedback)

Managing without impeding self-organisation

From the series of posts on Self-Organisation.

I used to play football and basketball with friends every now and then in the afternoons after school. We formed 2 teams with the
same size and with players filling the basic roles required for the game.

We were free to self-organise guided and constrained by the teams size and roles. Teams size and roles defined our 
boundaries/barriers. In a self-organising team there are many boundaries/barriers that can be set and tweaked.

This excerpt from Joseph Pelrine training material describes 

They define the edges of the system, who is in and who is out. By changing the barriers of the system, who is included and who is not, you change the dynamics in the system. In a sense, a boundary is the opposite of an attractor – people will shy away from it. “Barriers” is a more appropriate term than “boundaries”

Boundaries and barriers can be rigid or elastic, and the elastic ones are more resilient.  They are useful when:
1) They are good, beneficial, fit for purpose
2) The team is capable to benefit from them

Boundaries and barriers can be set by an agile manager or a coach. And also originate from external factors such as company strategic direction, company policies, budget, technology, partners, clients, and project goals and priorities. An agile manager and a coach can set and tweak and visualize boundaries and barriers to guide and safeguard the team:

to direct and influence the emergence of behaviors toward positive directions, 
to amplify the emergence of beneficial behaviors and to reduce or revert the non beneficial ones.

So managers can influence the outcomes without micro-managing and without impeding self-organisation.

Let people self-organise

From the series of posts on Self-Organisation.

When you have attended a workshop, training or other events that involve group activities you probably have heard something like:

now form two groups/teams and then ...

In this sentence there is the 1st prerequisite to self-organisation: let people do it.
It start with a purpose: some work that needs to be done.

A principle of the Agile Manifesto states:

The best architectures, requirements, and designs emerge from self-organizing teams.

Another principle from the same manifesto states:

Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.

While it seems easy to let people do it, in some organisations and for some managers that can be a challenge.

The traditional organisation of work put a clear distinction between who is responsible and who is accountable. It require a distinction between who designs the solution, who implements it and who tests it. Some managers are expected to plan, assign and monitor the execution of  every single task. 
This approach let those who implement the solution without authority, with limited information and with limited possibilities of cross-functional collaboration. These are obstacles for self-organisation.
Scientific studies and experiments [1] show that for complex challenges a different organisation of work, where self-organisation can happen, is more effective.  

Some managers assume that workers dislike work and will avoid it when possible, and prefer to be directed to avoid responsibilities
In some cases this can be the result of poor recruiting. In other cases this is just a preconceived perception [2].  

To conclude, let people do it means that
  • the organisation is dealing with challenges that benefit from a different organisation of work where self-organisation can happen
  • recruiting select individuals that like their careers and are willing to take part in responsibilities
  • managers have ways to manage the team and influence the outcome without impeding self-organisation
The last point will be developed in the next post about boundaries and barriers.
[1] The Agility Advantage, David S. Alberts.
[2] Theory X and Theory Y.

Motivations and prerequisites for self-organisation

During this 
information age some projects can face higher levels of inherent complexity. 
As ambiguity, uncertainties and unknowns increase, our ability to predict is diminished, no matter how good you are and how hard you work.
Change can be faster and sometimes viral, levels of interdependence can be higher and available information can be incomplete and fragmented.

Working practices, people skills and expertise, tools and work organisation must all adapt to and fit specific project needs. Cross-functional 
self-organising crews and teams that work together from "concept to cash" have a higher capability to absorb and deal with more complexity, can respond to change faster and better, are more resilient to failure and misfortune, can organically grow and scale and naturally encourage shared commitment and cooperation of motivated individuals toward a common purpose.

It is common to see teams that are not allowed to self-organise at all, while other teams self-organize in total anarchy. 
The challenge is a self-organisation that works. And that requires the discipline of well-functioning self-regulation and useful barriers.

The following points are 
3 fundamental prerequisites for a team's self-organisation:

1 - Empowerment: Let people do it
2 - Boundaries and barriers
3 - Discipline of Self-Regulation

I will go into more details in the next posts on these prerequisites.

See Also:

- On Understanding Software Agility - A Social Complexity Point Of View by Joseph Pelrine, Europe’s leading expert on Agile software development. 
- Adaptive Software Development: A Collaborative Approach to Managing Complex Systems by Jim Highsmith, executive consultant at ThoughtWorks and coauthor of the Agile Manifesto.