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
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.
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):
- Business Values
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.
- 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?
Thank you for reading! Your feedback is welcome.
PS: I explored this topic and many others in my last Book:
Post a Comment