Agile = Hardware + Software

Hello Readers!

Today we are going to explore an alternative perspective to evaluate the "Agility" of a Team, Project, Organization, etc.

One way I like to explain it, is to compare with the concepts of Hardware and Software from the computer science.

Hardware are those part of a computer that we can see, touch, weight. The physical side.

Software is the computer reality that we cannot touch or weight.  (many people says that it is that part that you can only blame).


To understand the alternative model that I propose to you today, we need to distinguish between these two kind of components: tangible and intangible.

There is many common assumptions, that Agile is for example:
  • “to do iterations” 
  • a set of practices that must be well done
  • to go faster
  • tests automation

These assumptions and generalizations are partially true, but they are a little bit problematic: they skip us to think that Agile could be something more than that. They stay in the "surface".

Starting from these assumptions, we can make the mistake to focus only on the "Hardware" side:
  • how to write a User Story
  • how to Estimate
  • the Backlog
  • team structure
...every other reality that is visible and obvious. We could say: the "Mechanic" part.

We can say that a "Mechanic Mindset" will see everything as a process, and will try to manipulate the "pieces" without understanding reality's intangibles.

Robot, Woman, Face, Cry, Sad

The problem indeed is that we can do all practices right and good, and anyway our project can go down and out. We can fail. People abandon the company, there is conflicts, apathy, lack of commitment and trust.

Everything that I've just mentioned are related to the "software side" of our Agile reality. That's why today I want to offer you a model to understand the hole reality:

Agile = Hardware + Software

Of course process and methods are important, but the "invisible" side has its own importance. To have a "Mechanic Mindset" in the Leadership can create problems.

One example, that affects directly team's "self-organization", is when the teams are restructured by top-bottom decisions. As a metaphore, People are reassigned to other teams like moving pieces in a chess board. (like "resources")


How can we classify all factors into Hardware and Software? Let's take some examples:

Hardware (methods, tools, processes):
  • How to write a User Story
  • Meetings duration and structure
  • Post-its color and quality
  • Team structure and “resources” assignment
  • Estimation method
  • Code Coverage
  • Feedback method

Software (feelings, values, believes):
  • Trust 
  • Motivation 
  • Business Values
  • Fear 
  • Commitment 
  • Respect 
  • Culture 
Then, how many times we worry a lot about processes and tools? How many times we worry more about the "Hardware", than the "Software"?

Is your Scrum Master / Agile Coach taking care about both: "Hardware" and "Software"? 

Ok, once we got awareness about this reality, the next question is: "what can we do about?". 

Which Tools do we have to work with the "Software" side of Agile?
  • Motivation and engagement: coaching, mentoring 
    • To make a general "happiness review" once a year is not good enough. The year has 365 days, and every Human Being is different. The Coaching and Mentoring methods are focused on individual and its necessities. 
  • Trust: fail-friendly environment, free speech, no judgments, respect. 
    • Strong Hierarchies with a control-oriented Mindset will be the "Trust predators". An environment where everything that you say, could be used against you, or any minimal failure will be punished, is a desert where the Trust seeds will not find where to grow.
  • Culture: meetings, values, learning spaces, hiring and firing
    • The Culture is one of the invisibles that may more impact on success chances could make. Its a part of the solution or part of the problem. The companies, normally, don't have budget problem, or lack of opportunities. They usually have Cultural problems, that holds them back to be able to escalate, retain talent and succeed. 
    • More over, to implement Scrum or Agile without a cultural change, don't have sense. Is what is commonly called a "cosmetic" solution.
The important point right now, is to relect about what is a True and Authentic Agility.
  • To be Agile is to write User Stories? you can be agile without User Stories
  • To be Agile is to do iterations? you can be agile without iterations 
  • can someone be Agile without respectful relations?
  • can someone be Agile without Trust?
  • can your team be Agile without Motivation?
I leave the answer open, each one can find your own opinion.  

Thank you for reading! Your feedback is welcome.

Agile Regards,


PS: I explored this topic and many others in my last Book: 

Make Scrum Great Again

No comments:

Post a Comment