A month ago, I was part of the continental event of Agile Latinamerica.
Among many interesting topics, a colleague motivated me to present my retro format. This is what I'm sharing here...
In many organizations where there is a "process culture", the retrospectives trends to be "action items oriented" (action-item-itis)
My proposal here, is that we move from the "retro as a meeting" to "the continuous improvement as a continuous flow".
(in progress..)
7.30.2019
When we should abandone Scrum?
Hello Agilers!
Today we are going to aboard a heavy Agile Myth:
when to leave Scrum behind and try something else.
This is a Strong Taboo in the Agile community, and if you open the topic in a conference, many people will question your Agility. They will looks you like a crazy man...
From the creators of
...today we bring you:
Everybody that has seriously studied the Scrum framework should know the "Cynefin matrix". No? let's review it:
This matrix explains the difference between environments or contexts:Complex, Complicated, Chaotic, Disorder and Obvious.
In base, Scrum is recommended for "Complex" problems solution. For the other 5 situations, Scrum is NOT suitable. Specially for Chaotic and Disorder contexts.
Good news: in software development we are mostly in front of a Complex challenge.
But the complexity exceed the product. The teams are complex. The management is complex. The market is complex. Everything is fuck$%& complex!
This is the point where the Management can make more damage, than help.
Management can destroy everything just with a sneeze. They can destroy the team's self-organization, the Product Owner autonomy, the Scrum Master change work....
Scrum depends on the context, the environment. You may not know how much.
Let's think about it. Imagine you are building a simple sand castle on the beach.
On which context factors you depends to be successful?
In Scrum is more or less the same.
Leadership must support and respect the Product Owner decisions. Also Team decisions. Customers and End Users should adapt to the new collaboration strategy.
The "context" must allow the team to self-organize.
This is the context where you will find impossible to run a "good enough Scrum": the Chaotic one.
Many people believe strongly that they are doing good Scrum. Then you visit the teams, and see a Scrum Master secretary as "calendar manager", a Product Owner as "delivery boy" that will bring the pizza you order, and a Team (platoon) specially selected to obey and serve...
In this context you may find a User Story like this:
In my understanding, (some of) the minimal conditions that every team needs, to be able, in order to implement Scrum are:
The answer is simple: Kanban + Lean.
You can keep building a new sand castle after every wave that moves, but it is frustrating.
Kanban+Lean allows you to deal with the Chaos around you, without need to modify nothing. And later from this start point, search improvements.
...to be continued...
Today we are going to aboard a heavy Agile Myth:
when to leave Scrum behind and try something else.
This is a Strong Taboo in the Agile community, and if you open the topic in a conference, many people will question your Agility. They will looks you like a crazy man...
From the creators of
"Everybody do Scrum, and don't know why..."
...today we bring you:
"The limits of Scrum"
Everybody that has seriously studied the Scrum framework should know the "Cynefin matrix". No? let's review it:
This matrix explains the difference between environments or contexts:Complex, Complicated, Chaotic, Disorder and Obvious.
In base, Scrum is recommended for "Complex" problems solution. For the other 5 situations, Scrum is NOT suitable. Specially for Chaotic and Disorder contexts.
Good news: in software development we are mostly in front of a Complex challenge.
But the complexity exceed the product. The teams are complex. The management is complex. The market is complex. Everything is fuck$%& complex!
This is the point where the Management can make more damage, than help.
Management can destroy everything just with a sneeze. They can destroy the team's self-organization, the Product Owner autonomy, the Scrum Master change work....
Scrum depends on the context, the environment. You may not know how much.
Let's think about it. Imagine you are building a simple sand castle on the beach.
On which context factors you depends to be successful?
- That people will not kick your castle "accidentally"
- The see waves will not come close to the castle and destroy it
- The Weather will be friendly (no wind, no rain)
In Scrum is more or less the same.
If the people on the context don't help,
you will have a lot of frustration.
Leadership must support and respect the Product Owner decisions. Also Team decisions. Customers and End Users should adapt to the new collaboration strategy.
The "context" must allow the team to self-organize.
This is the context where you will find impossible to run a "good enough Scrum": the Chaotic one.
Many people believe strongly that they are doing good Scrum. Then you visit the teams, and see a Scrum Master secretary as "calendar manager", a Product Owner as "delivery boy" that will bring the pizza you order, and a Team (platoon) specially selected to obey and serve...
In this context you may find a User Story like this:
"as Product Owner I want..."
What we need to run a minimal Scrum?
In my understanding, (some of) the minimal conditions that every team needs, to be able, in order to implement Scrum are:
- Stable team structure
- Unmodifiable sprints
- Participative StakeHolders
- (Independent + autonomous + dedicated) Product Owner (when possible with diplomatic immunity, and bullet proof vest)
- a temporary Coach with ownership in "practices" and framework governance
- a Product Owner worried about the Product, the Market and the End Users
- a Coach that do Coaching
- a Team that cares about Product
- direct contact with Market and End Users
Which alternative do we have when we cannot reach Scrum discipline?
The answer is simple: Kanban + Lean.
You can keep building a new sand castle after every wave that moves, but it is frustrating.
Kanban+Lean allows you to deal with the Chaos around you, without need to modify nothing. And later from this start point, search improvements.
...to be continued...
6.27.2019
Scaling Agile, since 3000 BC
Hi Followers!
Today we explore together one of my favourite topics: Agile Scale.
One of my main concerns is to understand "why" people wants to escale Agile. Many people think that it is related to a demand, that buys some support. In other words: consultancy smoke. If you are following my publications, you already know which is my vision about.
And not only you can't. You shouldn't, and you will not.
How can you scale something that is intended to be small? In the very moment it becames big, it is not any more small... I think the concept is easy to understand.
Then why is the situation that there is so many frameworks walking around, and some of them with some metric of "success".
Right... let's explore some ideas.
The clasical structure in a big organization looks like this:
Characteristics: simple. Easy to control and to find some "guilty" individual to punish when necessary. Responsibilities are strongly splitted. The person above tells the people below "what to do". Disobedience is punished and not accepted. "To move up" in the pyramid, is a career path, and a promotion.
With Agile, comes a new collaboration model: self-organized teams. What can we do now?
We want to be big, and we need to abandone this model. There is an answer to that problem...
This framework with a sexy name, among many solutions, bring one opportunity: to re-allocate all the bricks of the old pyramid into the new structure. With the most important aspect: to keep the order "upper" and "below".
We change the ball, and the court, but not the game. Fair enough, and easy to buy.
But... effective?
There is another experiments that tries to remove for ever that "pyramid" structure.
Yes!!! That's great!
Sociocracy and the Holocracy models are really good and interesting. But exists some derivated frameworks that, with good intentions, tries to bring a real solution to this "hierarchy" human behaviour disease. In the practice, and at the end, the "circles" ends in a "hierarchy", and as Niels Pfläging says:
Why we need to have this "command line" above us, or below?
If you take a look into the pictures, you will see something in common with this:
Today we explore together one of my favourite topics: Agile Scale.
One of my main concerns is to understand "why" people wants to escale Agile. Many people think that it is related to a demand, that buys some support. In other words: consultancy smoke. If you are following my publications, you already know which is my vision about.
How can we Scale Agile?
You can't.And not only you can't. You shouldn't, and you will not.
How can you scale something that is intended to be small? In the very moment it becames big, it is not any more small... I think the concept is easy to understand.
There is a popular phrase on Internet:
Elephants cannot dance ballet.
Then why is the situation that there is so many frameworks walking around, and some of them with some metric of "success".
Right... let's explore some ideas.
Organigrams and hierarchies.
The clasical structure in a big organization looks like this:
Characteristics: simple. Easy to control and to find some "guilty" individual to punish when necessary. Responsibilities are strongly splitted. The person above tells the people below "what to do". Disobedience is punished and not accepted. "To move up" in the pyramid, is a career path, and a promotion.
With Agile, comes a new collaboration model: self-organized teams. What can we do now?
We want to be big, and we need to abandone this model. There is an answer to that problem...
Safe
This framework with a sexy name, among many solutions, bring one opportunity: to re-allocate all the bricks of the old pyramid into the new structure. With the most important aspect: to keep the order "upper" and "below".
We change the ball, and the court, but not the game. Fair enough, and easy to buy.
But... effective?
There is another experiments that tries to remove for ever that "pyramid" structure.
Yes!!! That's great!
Sociocrazy (or "similar")
"flat hierarchies, are still hierarchies"
What has all in common?
Why the human beings trend to allocate all in hierarchies?Why we need to have this "command line" above us, or below?
If you take a look into the pictures, you will see something in common with this:
At the end, many "agile transformations" looks like this:
They use a lot of post-its, they implement practices, meetings, artifacts... but the hierarchy remains behind all.
The culture stay still. And remains.
Every honest cultural transformation has at least two main challenges: to change the leadership, and to change the teams.
...to be continued...
3.26.2019
1.22.2019
Subscribe to:
Posts (Atom)