Demystifying Agile

 

Hello World! 

Recently, I got the opportunity to listen to someone, that proposed to "Demystify Agile"... and I feel it's a cool idea... now I'm writing about it... 

So let's go! 

...how can we demystify Agile? mmmm 

Ok, I think first we need to define what is something "mystic". In this context I would assume that it refers to "pseudoscience". Or also what in the streets is called: 

Pseudoscience: Agile Smoke 

 

In the market, it is easy to find a lot of "consultants" selling "smoke" about agility. And when someone is selling something, it's only because some others are buying it. 

During the last 10 years, the market was flooded with "fake agilists". Some of them are selling "agile" without having the "agile mindset", or just selling the word as a "buzzword". Some of them were selling a "cosmetic agility", what is to "look like agile", let's say "using post-its everywhere", having a lot of "team meetings", showing that we have a "relaxed working space"... etc... 

Suddenly, almost everyone wanted to be "agile", but very few knew "why". 

And the common answer to the "why" question, used to be: "everyone is doing that". 

But there is two types of pseudoscience: the one that "looks like a clown", and the one that "looks serious". 

The problem with this situation is, that we should not follow our assumptions, that an authentic agility should looks "serious"... because we can fall into two possible mistakes:

• We think someone is "agile", because it looks formal and serious. 
• We think someone is "pseudoscience", because it looks like a clown (for us) 

 The difference between "science" and "pseudoscience" is not the aspect or esthetics... the difference relies in the functionality. 

The difference, we may agree, between science and pseudoscience, is that pseudoscience is not functional.  

Agile is a process to improve product delivery.

 

 

No. 

Its not... 

... first it is not a "process", it is a "cultural phenomenon", and the purpose is not to produce more unnecessary gadgets to people we never met. 

This perspective tries to use "agile" as a "management tool", to solve the "management problem": how to organize resources to fulfill contracts on time and budget. 

Agile is not just another "management tool", its far beyond that, it's much more than that. 

But this simplistic and mechanic perspective could be functional for starters. When you are starting with an "Agile Transformation", the easiest way to do so, is to transform processes, paint the walls and move the chairs... it's ok to start there and also good to know that it's not the limit. 

Well... if Agile is not cosmetic, it's not simple processes, it's not a management tool... then, 

• how can we "demystify agile"? 

Let's suppose that to "demystify" something is to "understand" it. I think is much more easier to understand the phenomenon, if we take a look on it's context, instead of trying to explain it... and also to have a look into it's components.

Let's try, if we can demystify agility together... if you have any question or suggestion, please write me an email... 

 

Context: Where comes Agile from? 

 

 

The Software crisis. During the 80's and 90's, there was a "pandemic failure" in software industry... the traditional waterfall methods were failing with full effectivity. The old hierarchical command and control strategy was not effective to drive software projects. The world was looking for a solution, until 17 gurus met in Utah and in one weekend they found the "Manifesto for Agile Software Development".

The world was changing and the software products became more and more complex... and the cryptonite that defeated classical management was that: complexity. 

If this was relevant on the 80's, imagine how relevant agility is today. It became Urgent.

In order to deal with complexity, it's a better strategy to have "flexible plans", "open collaboration channels", "self-organized and self-managed teams" and to establish a "learn-friendly environment". 

In 25 years, we evolve from the mechanical typewriter to the IPhone... but organizations are not so well and fast on changing and adapting...  

Let's take a look into those components: 

Components: agility pieces 

 

 

 

• flexible plans 
• We abandon the waterfall practices by implementing iterative-evolutive methods
  
• open collaboration channels 
• the opposite of collaboration is competition.
  
• self-organized and self-managed teams 
• we cannot deal with complexity by micro-managing human beings.
  
• learn-friendly environment 
• psychological safety and Dignity, are required components for an agile organization.
  

If we review the mechanic definition to consider agility as a way to "improve delivery", we can see, that in the "heart of agile", we are addressing two areas, of four of them. 

You can be improving processes, reaching efficiency and moving faster (what is always interesting and welcome) but it doesn't means necessarily that you are sustainable, that your organization is evolving into its best version, or you will be ready to adapt to the next crisis.

 

Agile is about adaptability, not velocity. 

 

When those gurus where searching a name for this new strategy, the "best name" for it was "adaptive", but it was not possible, 'cause of registered trademarks, then finally the chosen name was "agile".

I think it's not casual, that the organizations that finds more difficulties to transform to agility, are those old-fashioned, conservative and traditional ones... but it's not a matter of "processes", not only... its a matter of culture. 

• why cultural change is not optional? 

Because culture defines your behavior, your communication, collaboration and inter-dependencies... culture is the believes system that drives you... and also even defines how open are you to change and adapt... there is cultures more closed to adapt and others more open to change. 

• Learn
  
• Evolve
  
• Collaborate 
• Change
  

That's why the market talks about "agile transformations", and not about "agile implementations", because a transformation is an important reframing of your own mindset. 

Ok, now sounds like pseudoscience? Let me explain why not... 

 

 How can we avoid to fall into pseudoscience? 

 

Pseudoscience trends to reaffirm a "rationalized explanation" about the world we habit. But without testing, without experimentation. 

Usually arguments are like:

• because of yes
• because I'm the boss 
• why not? 
• we always did that way, and it works 

So, I think the easiest way to avoid falling into the pseudoscience trap, is to embrace experimentation, validation and tests.

You can start to implement frameworks, processes and methods, it's a good start, but it's just the beginning. 

 

 

Later you can learn and develop a "team-working" culture. Learning to collaborate from the experience itself. 

 

The most popular, common, simple and effective tool for cultural change: education. 

Establish internal and external trainings, and exchange between professionals and teams. Learn from every source you can... Open spaces for learning groups, for example. 

It's not a rocket science. It's just school science... But it is science.

 

What's next? 

 

Keep it rolling! And remember: it's not complicated. And if it's becoming complicated, review your strategy, experiment, learn, adapt and enjoy changing. 

I hope you like this attempt to "demystify agile culture".

Let me know if something is missing or hard to understand in this post and help me to help you... 

Happy Change! 

Daniel

A Human lost in the System...

 This is the story of a Man, that got lost into a Forest... 

 

Its a metaphor that I created during one of my last open talks at meetup.com. 

The Story is to try to understand how would be the experience of a single man, getting lost into a Forest, and trying to survive... 

Our classical paradigm would propose that his survival success "only" depends on his skills, and individual performance. 

Its like that? really?

 

10 lies about Kanban

 

Hello dear readers! 

Today I want to explore with you, something that I found on the way many times: confusion. 

In this case: confusion about Kanban. 

Is not rare to find people that thinks that Kanban is Scrum without sprints. Or maybe they think it is to "just work". 

 Lets go point by point...  

 

 

Kanban is different to Scrum 

In my opinion, the first mistake is to consider that Scrum and Kanban are different concepts, or even "oposite". Not even near... it is not a "versus"

From my perspective, Scrum is Kanban. Scrum is a specific way to Kanbanize a team. 

Here we are not talking about two absolutely different things. And so, to understand both can help you perform better... many people have a lot of problems with the "Scrum strategy", because they don't understand some Kanban principles. 

 

Kanban is better for simple proceses, but not for complex environments 

False. 

 

Both are strategies for complexity. Is how you use it what makes it suitable for complex or complicated contexts. 

Complex: is not predictable. The unknown.

Complicated: you need info to understand it, its not obvious. 

Simple: its self-explanatory. 

Complexity was the "cryptonite" that killed classical management (waterfall, command and control), and one of the basics elements of Kanban (AND) Scrum is the "plan-do-check-act" strategy. 

 

 

Kanban does not have roles (Scrum Master, Product Owner) 

Kanban implements also the "Service Manager" and the "Delivery Manager". 

• The Service Manager, focus to increase the ROI, or value creation. Its like the Product Owner. 
• The Delivery Manager, focus on the flow and deliver, allowing things to get done. It is like the Scrum Master. 

Maybe to understand Kanban roles, may help you to understand Scrum roles... ;) 

 

 

Kanban does not have iterations (Sprints)

Nnnnnnnhhh! False. 

In Kanban the iterations and cycles are called "cadences", and it has more than Scrum. The interesting part of this story, is that Kanban is much more conceived for scalability than Scrum, as Kanban already conceived longer cycles and strategic cycles.  Scrum only defines "sprints" and focus at the "team level".

 

 

Kanban allows you to go faster 

CUACK! 

Typical failure... Kanban is not about VELOCITY, nor either Scrum or Agile... Kanban is about:

• Flow 
• focus on avoiding interruptions
  
• Optimization 
• focus on reducing waste
• Improvement
• focus on finding weak parts of the system 

 

 

Kanban is to do whatever you want 

 To do "whatever you want" you don't even need a method. To have a strategy is to have constraints. But if you want to look or sound professional you can put a name to your "do what you want" ... "method"... 

Let me think... mmm 

Yes... we can call it:

DOYO 2

Then, when someone "important" ask you what method are you using? or what is our strategy? you can answer... 

• We are using a DOYO 2 strategy for risk management and planning. 

That sounds professional.  

 

 

Kanban is Agile

Sorry, I need a break. I feel sick now... this is disgusting...

Ok thanks... 

No my dear friend... let me see how can I explain you... 

Kanban cannot be "agile" because is not a person, is not an homo sapiens. Is a method. 

Tools, methods, cars, boards: Can Not Be Agile. 

Only people can. 

In some "agilized" environments you can read something like this:

• "in our Agile Blog, you can find Agile Posts about Agile games that we can use for our Agile transformation into the Agile Authority PMO, please contact our Agile Officer to be instructed on how to proceed" 

No. Kanban is a method. We could agree that it is "agile friendly", what means, that it could be useful to facilitate and cultivate an "agile culture" among our teams. 

Fair enough. 

But you can be behaving in a an agile way with Kanban, but also is possible to commit war crimes using Kanban.  

Bottlenecks are bad 

In our "project management" (neurotic) culture, we trend to associate bottleneck with "traffic jam", with "going slowly" and many other negative meanings. 

In Theory of Constraints, is said that: bottlenecks are not good or bad, they are just bottlenecks.

What do you think about this bottleneck? 

• Set of "why" questions:
• Why do you think that
• Scrum has only 1 PO?
• Kanban implements wip limits?
• Timeboxes are fixed? 
• We use only 1 Board? 

 

• Why do you think that we work with constraints and restrictions? 
• To optimize the system by reducing waste 
• To reduce complexity 
• and much more...
  

• In Kanban we don't estimate 
• 
  
• Kanban is to do Scrum without Sprints
  

 

• 
  

 

Scrum is not working...

 test

agile vs waterfall
agile is the only one way  to go
if we are following the practices
key that opens the door
scrum is not working
we are here to fail

Coaching & Cultural Change

 Test

Agile Smoke

 Test wip

Agile Hierarchies - WTF!?

 

 (Photo: Bjarne Henning Kvaale / Shutterstock / NTB)

 

 Today I will write about something controversial: Agile Hierarchies. 

Hierarchies, is the mostly observable social phenomenon from the old-classical-waterfall-command&control-taylorist culture.  

 Then... why this is relevant in agility? 

This is what we are talking about. 

What's the new role of hierarchies in the Agile World? 

in-progress... coming soon

Agile Coaching: 13 permanent domains of human interest - Fernando Flores

 

Hello readers! 

Today I introduce you a knowledge perl from Fernando Flores. The original text and documents are in spanish (Chile), so the idea to write this article, is to provide a personal translation to the english world.  

I will write on the first half about Coaching discipline, and will add some hints about Agile Teams at the end. 

One of the main focus in the coaching discipline, is the "adult development" and how this phenomenon impacts on client's performance and life. 

Fernando Flores did a master piece work about this, and he defines 13 permanent domains of human interest. This means, that we can achieve our plenitude, and our adult development, when we take care of all the 13 domains. 

The 13 domains:

• Free time
• Work
• Family
• Body and wellness
• Social relations 
  
• Education
• Money
• Belonging
• Professional career
  
• World 
• Dignity
  
• Spirituality
  
• Situation context

If someone, has a good level on some of these domains, but not in everyone, then this person is not able to live in plenitude. We achieve our adulthood when we take charge on all these domains. 

To "take charge" does not means you must have high skills on them. It means, if you cannot take action, or you are not effective, then you should ask for help. 

Responsibility is the ability to response, and when we cannot solve something, we are responsible when we ask for help. 

For example, some anti-patterns: 

• Someone is workaholic, and dedicates full time to work and profession, but get disconnected from the family and friends (social connections) 
• Someone has no discipline with money, and that starts to affect other domains. 
• Someone focus full time into education and lost social relations. 

 The path to achieve plenitude, and adulthood, is to take care of the 13 domains. This is Fernando Flores Thesis. 

Dignity

 

Human dignity is the right that every human being has, to be respected and valued as an individual and social being, with their characteristics and particular conditions, for the mere fact of being a person. 

In Coaching discipline, we say that we are "in dignity" when we stablished our own "action standars" with whom we express our commitment to live. 

Dignity is one of the "self emotions", the others are self-estime, self-respect and self-trust.

All these "self-emotions" are co-related. 

 

Agile Teams

The Agile philosophy propose many solutions to the dignity challenge in software development teams. On of the is the "self-organized" or "self-managed" team principle. 

Workers dignity in an Agile Team, can be affected on many ways. here are 3 examples:

Overwork

Many times, leadership, tries to achieve higher performance by increasing preassure. Overwork can constitute a form of indignity, mainly when it involves political or management pressure.

Abuse of power

A manager abusing their power and authority is also a common form of indignity. Threats and intimidation can be experienced as humiliation.

Micromanaging

Being micromanaged affects directly autonomy and can prevent individual decision making.

How much Coaching has your Agile Coaching?

Hi survivors! 

Today we will explore two language differences: Coaching vs Agile Coaching. 

Let's try to answer basic questions about this dilemma... These are hard questions, and I will try to provide short answers, and leave you the door open to your own investigation and experimentation. 

I want this blog post to be an invitation for you, to explore and experiment in your own environment.

What is an Agile Coach? 

Lyssa Adkins was one of the first to use this name for such a "role" in an organization game. 

 

She found out someway, that to use the "coaching as strategy" for cultural change in agile transformations, was one of the key elements for success. 

In his work defined that an "Agile Coach" plays 4 different strategies to facilitate learning processes in this transformation processes: Training, Mentoring, Coaching and Facilitating.

• Training is to learn by doing practices and methods that has some proven effectivity. 
• The Teacher has more "knowledge" about the content.
  
• Mentoring, is assisting to improve based on having a big and deeper experience on the practice field. 
• A Mentor has more "experience" on similar fields. 
  
• Facilitating, is like moderation. Is to follow some format, method to assist and enable the right flow of a meeting or conversation. (Meetings moderation, workshops) 
• A Facilitator can moderate a debate following some "structure" to enable results inside a defined time frame. 

Ok, if Training, Mentoring and Facilitation brings knowledge, experience and structure... then... 

What is Coaching? 

 

• a relation to co-create possibilities 
• 
  

Where does coaching comes from? 

Sports, and how the "inner game" affects performance. 

Where does a coaching process focus to cultivate a change? 

• Observer (Ontological coaching) 
• the way of "being"
  
• Relations (Systemic coaching)
  

On what does a Coach focus to, in a coaching conversation? 

• Language
  
• Emotions
  
• Body
  

What are some areas to work in a coaching relation?

• Learning
  
• Maturity 
• Emotional Intelligence 
• Social Intelligence
  

What has to do all this with Agile or agility?

Today and here we are talking about "Individuals and Interactions", and not about "processes and tools". In other words: Humans and Relations. 

And, we are talking about how the Human nature, interactions and relations affects our "effective action capacity", what obviously will affect our "performance". 

(yes, also profit)  

To be, or not to be... effective. That's the question

I want to be like Google, Amazon...

As "Agile Coach", Do I must learn it?

Not at all. Even if its a "core" competence, I don't think its a "must", and not everybody would be interested or motivated to learn this discipline.

Where I can learn more about this?

The Observer and the World 

The Phenomenon 

The power of Relations 

Maturity 

 

 

 

 

Emotional and social intelligence 

What skills are required for it?

Who should care about it?

Everyone that is interested on developing "relational skills", specially leadership roles, as "coaching" is a type of leadership.

Conclusions from 20 years - Manifesto for Agile Software Development

 A day like today, a 12th February, 20 years ago... 17 thinkers initiate what will became a world big change: Manifesto for Agile Software Development. 

The Software Industry was totally frustrated and in crisis, the success rate of Software Projects had very bad numbers. 

During more than 20 years, science tried to bring a "scientific" solution to the "Software Problem". 

Agility bring to the table simple strategies to deal with complexity. At the beginning, many people were skeptic, 

Mike Beedle, the man behind "Agile"

 

Regarding Jeff Sutherland, "Mike brought the agile name on the first day", and it refers more about "adaptability" and "light weight" meaning. Usually confused with "velocity".  

The 4 main values on agility's Core

 

The 4 values behind manifesto, written on the hand of Martin Fowler. 

What's the balance after 20 years?

 Improvements achieved and widely implemented: 

• Iteration model
  
• Team working 
• Education and trainings 

 

Partially achieved

• Decisions de-centralization 
• Self-organized teams 
• Commitment 
  

 

Poorly achieved

• Cultural change
• Coaching  
• Professional Dignity 
• Respect 
  

 

 

All you need, is Trust

Hello apocalypse survivors! 

Today we are going to talk about Trust. 

This article is based on Marco Leone's presentation at ICF. Original was in spanish, but here will provide an english version plus some of my own understandings. 

ICF has a new fresh Coach Competence list. And on its list has one crucial element to enable a Coaching relation to grow and cultivate:  

cultivates Trust and Safety

What is Trust in this context?

Is a "phenomenon" that happens in the context of our human relations.

When we lost Trust, we feel insecure, unsafe. 

Trust is composed by conversations. But not any kind of conversation, but the type of conversations that can creates the future I want to have with the others. 

Is a feeling or a mood that involves some judgements about the future into a relation. 

•  is not an accident 

How can we cultivate Trust?

Sincerity, Care and Competence. 

Trust is a "Skill", that includes these 3 competences.

When one of these 3 fails, Trust fall down immediately. 

When we express sincerely, and we care about others good, and we show proven competence to create results, then we are creating a background where Trust can be cultivated. 

Commitment is a big player in the Trust game. But its not its components. Trust will be the effect of honor our commitments. 

Someone is Sincere, when there is no lies. 

Someone "cares", not only when "cares about the other", but also when "I care about your good". "Care" is a feeling, and an action. 

The other needs to feel cared.

For this is important to sustain the relation through Time. 

Trust has many dimensions:

• How others trust on you
• How you trust on others
• How much you trust in yourself? 
• How your Trust feeling, impacts in your relation with certain reality? 

To Trust or to not Trust, is that the question?

In front of Trust Phenomenon, we can hold 4 types of strategies or attitudes. 2 will open possibilities, 2 will close them. 

 

• Naive 
• Negative, not constructive. 
• Is to trust on anything or situation. 
• Is a childish attitude in front of Life, and can drive to a disaster. 
  
• Trusted 
• Positive, constructive. 
• On this level, you know that is possible that someone can lie or dishonor the commitment, but you decide to take the risk. 
  
• Prudent
• Positive, constructive.
• The Prudent attitude, is to take all necessary measures to reduce risk. 
• The Prudent person takes control and surveillance of the situation. 
• The example, is when parents will give permission to a teenage daughter to go to party for the first time. They will make all necessary questions, and will take all necessary measures to avoid risk and dangers. 
• Where is the party
• Who will supervise it
• Who will drive you back home and when 
• When will the party ends... 
• etc...
  
• Suspicious
• Negative, not constructive. 
• Prefers to never trust in nothing, on any situation. 
• This is a typical situation in persons that get hurt on a Love relation, and decides to not love anymore. 
• Or those who where mistreated by managers, and then decides to not trust never again in the management. 
• Or also, when managers decides to never trust in his own employees.
  

Why the 2 extremes are negative? 

Because they can drive to negative experiences, and negative experiences will damage our skill to Trust. In us and in others. 

Now we are unveiling a new Phenomenon:

Trust is not inside of you, is in the Relation. 

Is a Co-Creation

We don't "coach" people

Coaching is a relation, is a dancing. You never "dance" the other. You "dance with" the partner.

Trust is not a phenomenon of Coaching, is a phenomenon of Life. 

No human relation can prosper without Trust. Is an elemental basic emotion, and even it precedes "Love". 

We use to think that we are in a relation with our partner, because of Love. 

Did you pay attention what happens with Love, when Trust falls down? 

Our Love relation falls down with it. And we would like to stop loving, on the same time that we stop trusting.  But it don't works that way, and then we suffer.

On the other direction, when we Trust so much on someone, Love appears.

The Relation, as a phenomenon, brings us a new paradigm.

Power is not inside you

We have Powerful Relations