Is agile Alive? Dead? Misunderstood?

Lats Sunday, after reading multiple “Agile is Dead” articles, I posted this short update on linkedIn

screen-shot-2017-03-05-at-11-03-37

As you can see from the stats, in less than 7 days it has received a lot of attention (I am not an influencer and my updates generally do not receive such large feedback)

My contacts in linkedIn include a lot of Agile or Lean Coaches and as expected, initially the message got some positive comments. Soon after some agile detractors joined the conversation and made it much more interesting as generally feedback that comes from different perspectives enriches the conversation adding dimensions that sometimes cannot be expressed by a biased mind.

I noticed 3 interesting trends in the messages.

  1. When agile is not driven by technology, agile fails
  2. When agile is driven by technology and not the business stakeholders, agile fails
  3. Agile is only useful to deliver something nobody wants quickly

The first 2 are extremely interesting, in fact they say exactly the opposite thing but they both come to the same conclusion “agile is dead”. I read and reread those messages and then I saw it

If agile is driven by one part of the organisation, whichever it is, and trust is not built within the whole organisation, it will fail. Do it like this and agile is dead before you even start.

If you try to own something that will change your organisation and run with it, you better make sure you share your vision, your responsibilities and your success with the rest of the organisation. How do you expect people outside your little world to want to follow you in this difficult change if they don’t know, understand, own and help you change. Agile/lean transformations are not driven by a department, they are driven by the whole.

And the result might be that you even stop talking about departments and only talk about the whole.

Now on objection #3.

Agile is only useful to deliver something nobody wants quickly

I have seen this very often and honestly makes me sad. A lot of scrum implementations have a Product Owner that is seen as the heart of the product, the person that understands the vision of the product and that takes the responsibility to take the important decisions for the future of the product in regards to strategy, prioritization and so on.

If you look at it this way, you might think that the PO is a single point of failure, in fact what if he is not able to make good decisions, how about his bias, is he a dictator?

As an agile coach I make sure that any product owner that works with me will have the tools for making good decisions. He in fact will know how to manage flow using WIP limits, he will be aware and become proficient in UX techniques, he will learn how to monitor, gather and use feedback from his customers, he will understand the importance of small experiments, he will be aware of cost of delay and when prioritising his features and user stories will have access to many advanced prioritization techniques.

Being agile does not mean automatically ignoring lean startup, lean UX, research. No that is not being agile, that is being a scrum master after 2 days training.

 

Advertisements

How a little man from Japan helped Team X focus on their customers

screen-shot-2016-10-28-at-08-26-32

Previously on “A knowledge worker’s tale“: Team X discovered that lack of clarity on what to build, was creating a backlog in their exploratory testing work queue. They realised that adding new testers would have only fixed the symptom of the problem but not addressed its root cause.

Team X met to talk about a possible solution to the fact that too many misunderstandings in the user stories were slowing down the work dramatically and driving the testers crazy.

When Gus walked in, they were all there, nobody was late, the team really wanted to resolve this problem.

Mike took charge and said “We need to ensure that the user stories contain all the details, we can’t be blamed for problems in the requirements”. All the others nodded in unison, the bloody user stories were the problem…

Peter added “Absolutely Mike, we need Fritz to sign off the user stories so that when we start, if there is a problem, we know who’s fault it is and we don’t get the blame every time, I am tired of this!” he added “we need to make sure we know who’s fault it is”.

Before Fritz could answer, Gus interjected “OK, let’s see. Am I right in saying that our goal is to deliver value to our customers? Right. How is identifying who to blame going to help our customers? How is blaming somebody going to help our customers at all?”

He continued “Customers will still get the product late because of the misunderstandings, I bet if you asked them, they will tell you that they don’t give a rats arse who’s fault it is. What they care about is to get a solution to their problems, through our software”

Then he went “Once there was a little man in Japan, many years ago. He said that every activity that does not benefit the final customer is waste and needs to be removed from the process. He went to define 7 categories of waste that can be found in manufacturing. This guy’s name was Taiichi Ohno, he revolutionised the motor industry and his learnings have been used to improve manufacturing all over the world, he worked at Toyota. I strongly believe his lessons can be used very much in every context, including software development, let’s not introduce waste, let’s focus on value add activities”

“It seems reasonable” said Mike “but how do we make sure the defects in our stories don’t get caught only at exploratory testing, we have seen that when that happens our flow gets to a standstill, we can’t allow that”

“Taiichi would be proud of you Mike” said Gus. “One of his 7 categories of waste was exactly what you described, ‘defects’.” he continued “Quality was fundamental in the Toyota production line, one tenth of a millimetre difference in a bolt could bring the line to standstill, Taiichi knew it and made sure the workers knew it too so that they could find new ways of avoiding it”

Gus stood up and went to the whiteboard, he wrote “Prevention over Detection”. Then he drew a circle that had 3 stages “1. Write a failing test” – “2. Write enough code for the test to pass” – “3. Refactor”.

He went “Ladies and gentlemen, this is TDD, the one most effective ways of preventing defects in your code I have found in my 20 years as an engineer. In one of it’s more modern evolutions it is called BDD. Through high collaboration and conversations it allows teams to deliver code that has a fraction of the defects of code written without it. If you like to know more, I can organise a one day workshop to talk about BDD and how it can help us prevent defects”

Peter said “I am a bit confused about all this stuff, little Japanese people building cars and tests that are written before code, it doesn’t make sense. But in all fairness Gus has been right before with even more nonsensical stuff like ‘do less to do more’, I think we could take a leap of faith and trust something good will come out of this, what do you think guys?”

The team nodded in silence, they were puzzled. Accepting something brand new and counterintuitive can be scary, but true agile teams are courageous in their decisions.

Gus smiled and left the room so that the guys could make a decision freely.

Will Gus’s nonsense help team X? Stay tuned and discover what happens next

 

 

 

 

2 lessons Muhammad Ali taught me about Agility and Innovation

muhammad-ali-572571_1280

Muhammad Ali has always been my personal hero and source of inspiration. I recently discovered that my affinity for him might also reside in his natural born “agility” and ability to innovate.

This is what Ali has thought me about agility and innovation

First lesson: Be ready to react quickly to changing conditions.

Kinshasa, Zaire, October 30, 1974, 4:00 am. The fight that will be remembered as the greatest of all time is about to start.

Ali wants his world champion’s title back. He tried to get it back from Joe Frazier three years earlier but didn’t succeed, he lost. Before he could have a rematch with Joe Frazier, a brand new guy stormed the scene and took the title, this guy is George Foreman, tonight’s opponent. George Foreman is a young giant, with incredibly powerful punches that managed to knock out Frazier 6 times during their title bout.

Nobody believes Ali can beat Foreman apart from Ali himself.

The fight starts. Ali and Foreman go at each other. Ali is being hit hard by Foreman. He is incapable of making his fast hands count against his opponent’s superior power. His dancing feet are not enough to keep Foreman away. This is a disaster. Ali’s best skills, punch speed, and fast dancing legs are not enough against this guy, Ali is going to lose.

But he is Ali, the King Of The World, the greatest of all time, it wasn’t going to be that easy.

It is at this point that Ali decides to change his tactics. This is something that boxers do all the time. They start with a plan; if it doesn’t work, they go to plan B, then plan C and so on until they either find an approach that is effective or they go down.

Ali is different, his plan B is something that nobody had done before and he devises it there and there while the fight is on, while he is being outpowered by his opponent.

The rope-a-dope is born.

Ali decides to let Foreman push him to the ropes of the boxing ring and to focus only on defending. He uses the loose ropes of the ring to go down on his back and duck his opponent blows. He decides that it’s a good choice as he can transfer some of the power of his opponent blows to the elasticity of the ropes and out of his body.

His guard is as high and tight as it had ever been in his career. He throws one or two punches only when he sees a clear opening. These punches are by design not powerful, no intent of knocking his opponent out, they are defensive punches, because “he won’t hit me while I hit him clean”.

For any of the millions of Ali’s fans, the first 7 rounds of the fight are heartbreaking. They can see their hero bullied against the ropes, unable to hurt his opponent. Everybody thinks it is only a matter of time before Foreman unleashes a clean blow and knocks Ali down. Not even his corner trainer, Angelo Dundee, can understand what Ali has in mind, and he keeps on shouting “Get away from the ropes! Ali, get away from the ropes”.

Then the 3rd, 4th, 5th, 6th, and the 7th round go by like this. But by throwing so many punches, George Foreman is starting to get tired. His punches are not effective against Ali. Ali uses the ropes to absorb the power and keeps his face out of reach through a tight defensive guard. George Foreman is punching himself out, Ali’s plan is working.

Then the 8th round. Foreman’s tiredness is showing clearly, even the commentators notice he is unsteady on his legs throwing ever slower and tired punches. Ali was waiting for it and sees it too. Foreman is tired, it’s time to strike.

Twenty seconds before the end of the 8th, Ali sees Foreman unsteady on his feet slightly lose his balance, he slips the ropes by turning to his right and hits Foreman with the most beautiful combination of 6 punches you will ever see.

Foreman goes down, he never gets up.

Ali is the King Of The World again.

Second Fundamental: Don’t be afraid to fail if you want to innovate

Ali had to try something new, if he didn’t he would have lost. He could have tried a less risky approach, less risky than one that nobody had ever tried before.

But he was Ali, he was brave, he went for the big bet, and choose the riskiest solution.

His experiment was successful,  he created the rope-a-dope, an innovation in the 100-year-old world of boxing.

From Ali, I learned that being able to react to changing conditions and having courage when experimenting can help us innovate.

Thank you, my hero!

That’s what creates innovation in this world. We’ve got to try!