Please don’t call it Agile

Please don’t call it “Agile”! Really!

I can’t stand anymore listening to the word “Agile” and seeing the main principles neither understood nor respected.
I can’t stand anymore seeing agile transformations where the only goal is the transformation itself as a new process to put in place.
I can’t stand anymore arguing with people who think to have understood “Agile” because they use some sticky notes and do some daily meetings.

For many people who do agile or want to do agile, the agile manifesto is often a piece of paper without real meaning.

I don’t have the agile manifesto attached in my room and the point here it’s not to be a “purist” of all agile principles. I don’t care. I do care about people: respecting people, giving people autonomy, motivating people, trusting people, collaborating and improving with people. I care about the human side of business: business done by people who wants to satisfy and delight customers, business done by people as it is their own private business. I always considered Agile as an enabler for all of this, as opposite of other ways to developing software where people are like “cogs in the machinery“.  Agile is “people oriented”. This is the most important thing to understand.

Agile for me is tightly linked to new Management principles and practices (ex: Management 3.0) and to the organisational structure and values. I believe that you cannot have Agile without changing or adapting the others points, unless they are already “people oriented”. I believe in “Guiding Structure“: the structure of your environment is the largest determinant of your behaviour. So if you want to have Agile ensure that all your guiding structures are “people oriented” too (management, organizational structure, values, rewards, etc.).

We should save Scrum from Scrum

It seems a paradox but it isn’t. I start to think that we should save Scrum from Scrum: from the weight of his popularity that could transform it in something different.

More and more often I see Scrum not well understood and applied in organizations. This concerns different aspects: Scrum roles, collaboration of people, estimation, etc. We have already a name for such situations: it’s the well known “ScrumBut”. The real problem is when the “But” part is much more bigger than the “Scrum” part and what is kept it’s just an iterative framework with people playing the Scrum roles and doing some ceremonies with the fundamental agile principles negatively impacted or no more present. You can see development managers playing the Product Owner role instead of someone with business knowledge, ScrumMaster with a subordinate hierarchical link with the PO, Scrum Masters who assign the tasks to people, estimation done by the team with in reality a Gantt Chart already done to tell how things should go… I’m sure you have already seen such situations and many others.

I think it’s time for reflection to understand where “Scrum” is no more “Scrum” and when it’s not bringing anymore the benefits it was developed for and why we have such common situations. Read more of this post

Agile misconception – fixed scope and fixed deadline

agileMisconception

Drive: What Motivates Us

The philosopher Ludwig Feuerbach said “man is what he eats”. I would say that a man is also the books he reads and Drive, the book of Daniel H.Pink about motivation is one of those books that can influence you and change the way you think, inspiring you to act. An amazing book.

Drive of Daniel H. Pink

Drive of Daniel H. Pink

Drive teaches us that, when it comes to motivation, there’s a gap between what the science knows and what business does. “The current system of motivation put in place in organizations often doesn’t work and often does harm. If we want to build better organizations, elevate our lives and improve the world a new approach is needed”.

In the introduction Pink explains that human beings behaviour is driven by what is known as the biological drive that comes from within and includes hunger, thirst and sex (Motivation 1.0). Then a second drive that comes from without is to respond to rewards and punishments in our environment (Motivation 2.0). In the middle of the last century however few scientists began to discover that there was a third drive that they called intrinsic motivation, our innate need to direct our own lives, to learn and to create new things, and to do better by ourselves and our world (Motivation 3.0). Read more of this post

Impediments to agile

Just reading an article on things that impede agile… I share two points here (extracted from the original article):

  • Technical Practices

” …you cannot scale agile on crappy code, without collective code ownership and continuous integration – period, no debate!”

  • PMO

“The mother-ship of all agile impediments – actually not my quote!

A bit harsh? Well it depends.

A PMO that is steeped in governance that adds no value then absolutely! Gated controls are great provided they add value – have the requirements been signed by the Business, has the design been signed by the CTO, have you produced your weekly report, have you correctly RAG your Risks and issues. Mother-ship!

But a PMO that has made both the cultural and mindset shift to agile can be a huge enabler.”

People is more important than everything

I’m more and more convinced about this: “people is more important than everything”. For many years in the software industry we tought to have found the good method for successfull software development, always searching for processes, practices, framework… but did these practices and methods provide the expected results? Today the risk is that agile will be another of such methods that didn’t bring the expected results if we don’t understand what “agile” is.

I see a situation in which many people wants to use “agile” and start to do it, but what I see in reality is the fall of agile: “fragile”, “wagile”, “srum-buts”… so the question is:  what “agile” really means?
My passion for agile comes from the idea that the interactions between people are more important than processes, that people are the key factor in the software success. Attendind people’s need and the close collaboration among people can bring back the enjoyment to developing successful software. The agile manifesto defines what agile is, we can find in it the same idea:

indivuals and interactions between process and tools”
“customer collaboration over contract negotiation”
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile is not doing it but “being agile”… for that we should start focusing more on people.

Scrum Gathering Paris – “Shu Ha Ri” and Spiral Dynamics

The first day of the Scrum Gathering in Paris is finished. It has been really a great day. The sessions I have attended were mostly about the same theme: “Expanding an Agile Culture in a Complex World”. This theme aims to define cultural tools (patterns, management practices, methods, etc) helping to install in a sustainable way an Agile culture within organizations. Below the sessions I liked most and my main takeaways:

“Cuture > Process” – Henrik Kniberg
The opeining keynote from Henrik Kniberg showed what “agile culture” really means and how this is achieved in Spotify the company where he actually works.
My Takeaways:
Shu-ha-ri  (Follow the rules, adapt the rules, Ignore the rules)
“People > *”  (People are more important than everything else)

Agile à la mode? The long-Term Viability of an Agile Culture in France – Petra Skapa and Mack Adams
This session showed how it’s difficult to have an agile culture in French organizations: the French values are not in lines with the agile ones.
My Takeaway:
The transformation to agile in France is more difficult than in other Countries. Agile is a mindset and it’s adoption and success is directly influenced by the Country’s culture.

Changing Cultural DNA with Spiral dynamics to become thouroughly Agile – Dajo Breddels
Interesting session on how the humans interact and behave according to the spiral dynamics theory and how this theory can help on the cultural change needed for agile transformation.
My takeaway:
Spiral Dynamics theory can be helpful for the agile cultural shift.

Transformation to Agile is not easy

I had the opportunity to meet Peter Measey as trainer of my Certified Scrum Product Owner course and since then I started to read his blog. Some time ago I read an article about how the transformation to agile can be difficult and he made me think about it. I know that the transformation to agile is not easy for large organizations that worked many years with a waterfall methodology. It requires time and it requires a change in all the level of the organization and after all these changes it can happen that the organization is still far to be really agile.  One important aspect of the transition is overcoming the individual resistance and it’s not easy because human being are involved. From Peter Measey’s blog:

“If you think that transforming an IT system from one technical platform to another is challenging, try doing a technical transformation where the platforms have a mind of their own and may not want to change, or even have the ability to change!”

Working in a large organization that wants to go towards agile and knowing that the transformation is complex I always had one question in my mind:

Can a large organization, alone, be successful in the transformation to agile?

When I say “alone” I mean without asking for help from external agile transformation experts.
Maybe the transformation is possible but more painful and longer because you cannot rely on lessons learned or common patterns among different organizations or maybe it will end, as Peter says, to what is known as “FRAgile” or “WAgile” where organizations are not really agile even if they think to be. I don’t have my personal answer to this question right now… In the meanwhile I’m still thinking on Peter’s questions:

“Would you try to write a software system without employing expert software developers ? So why would you think that something much harder (such as transforming an organisation of human beings) can be done by people who don’t understand transformation?

Change your Organization: it’s about trust.

Some days ago a colleague suggested me an interesting blog of James Shore about changing the organization. How an organization can become more agile? How an organization can improve their processes?
Successful organizational changes cannot be fully top-down or bottom-up, but is there really a difference between the two? James Shore thinks they are essentially the same thing: “Both are extremely difficult. Both require that people want to change.” So how can you introduce new ideas and help the change to happen? The central point is trust. James says “It’s as simple as that. When people trust me, I’ve been successful. It hasn’t even been hard. And when people don’t trust me, no amount of cajoling, persuading, beating with sticks, etc., will make a difference.” The way to change something in the organization is no-change. The approach is more to show people ideas, seeing what they think, talking about alternatives, listening to experiences, etc.

“#1: the Way to Change is No-Change. I’ve seen how hard organizational change can be, and so I no longer attempt it. I just share ideas, lead by example, and have fun doing it. If things change, great! It’s a much easier approach to life… and you know what? I think it’s made me more effective as a consultant, and as a change agent, too.”

I like this thought and I think James is right: at the end change is about trust and respect to earn this trust.

“We must be the change we wish to see.” – Ghandi.

Software engineers shouldn’t be like “cogs in the machinery”

Even with the agile “revolution” taking place in these few last years in the software development industry it’s still common to find companies developing software where the importance is more focused on the processes than on people working every day to develop the software. Even when companies declare that people are important they don’t really perceive the situation in which many software engineers work today. This situation is however well described in the literature and used also as motivation for a transition to agile.

Unfortunately I find the metaphor of software engineers like “cogs in the machinery” of Mike Cohn in “Agile Estimating and Planning” well describing the reality here:

“Agile teams value individuals and interactions over processes and tools because they know that a well-functioning team of great individuals with mediocre tools will always outperform a dysfunctional team of mediocre individuals with great tools and processes. Great software is made by great individuals, and as an industry we have tried too long with too little success to define a development process that relegates individuals to replaceable cogs in the machinery. Agile processes acknowledge the unique strengths (and weaknesses) of individuals and capitalize on these rather than attempting to make everyone homogeneous.”

I agree also when David J.Anderson in “Kanban. Successful Evolutionary Change for Your Technology Business” tells that like Ford assembly-line workers in the second decade of the twentieth century no one cared about the monotony of the work or the well-being of the workers. Again “It’s hard to imagine the emergence of organized labor in knowledge-work fields like software development, mainly because it’s hard to imagine anyone addressing the root causes of the physical and psychological ills developers routinely experience”

A further step in considering individuals and interactions over processes and tools is to have people acting as a team. This is a completely different thing than having a group of people together for administrative convenience.  As Douglas McGregor told:  Most teams aren’t teams at all but merely collection of individual relationships with the boss.  Each individual vying with the others for power, prestige and position”.

For a software engineer the feeling to be part of a real team is exactly the opposite as feeling to be a “cog in the machinery”, this is what software engineers should search to feel more motivation and appeasement in their daily work. Managers should consider the problem.

Hope this can help reflection