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

Can we train ourselves to be more empathetic?

how_does_that_make_you_feel_

For a good while, I have been thinking more and more about the impact of our behaviour on our success and the success of the organisations we are part of. This brought me to observe people’s behaviour in trying to achieve a goal and the different reactions that each approach caused.

I have also done some experiments myself, trying to achieve the same goal using different behaviours on purpose.

The differentiator in the behaviours I have been observing is empathy

The subjects I have observed are of the type: developer, tester, analyst, business stakeholder, manager, leader.

What I found out is that the difference in the success of people with high empathy versus the less empathetic ones is astonishing. It is a different ball game. Empathetic people, get things done while building strong relationships and creating an enjoyable environment.

On the other hand, I have seen extremely skilled and capable people struggle to get anything done because their lack of empathy for their teammates made them choose behaviours that instead of achieving their goal, frustrated them and in some extreme cases made them withdraw into a corner full of anger and resentment with a common mantra: “they are idiots and they don’t understand”.

Being very empathetic, I feel very bad for them and I want to try to help.

You control how empathetic you are

The first thing I can do to help my less empathetic readers is to demonstrate to you that you are in control and can train your empathy to become more successful.

I believe we decide whether we want to act with empathy or not. Empathy is not in our DNA, it can be learned and improved. How do I know that? 

Let me tell you a story

A few years ago, driven by my burning curiosity, I had managed to get the hang on agile software development and I really thought I knew a lot about it.

Being an extrovert, I thrive when I am in the presence of big groups of people. At the same time, I am also an avid learner and I know that for me, sharing my thoughts in public, is the most effective way of learning something new.

One obvious  way of taking advantage of this two aspects of my character was to start participating actively to some Agile and Agile testing online groups with the honest intent to help people that needed help and learn in the process.

I tried. It was a train wreck.

My goal was learning by helping people resolve their problems, but the result was that I was pissing people off and pushing them further away from subjects that they found already enough challenging before they met me, the annoying Italian dickhead that thought he knew everything.

What was the cause of this disaster?

Was my knowledge on the subject not sufficient? Did I fail because of my incompetence?

No.

I knew enough to help the people starting with agile, I had the necessary knowledge and skills.

So what?

One day, I started following the answers of another person in the group let’s call him Mr. Joe. He was saying the same things I was saying, we agreed on everything, we even spoke a few times about how much we cared for the agile community and how much we wanted to help.

So, same skills, same motivation. Was he annoying people like me?

No. People loved him. They asked him direct questions and thanked him all the time.

I remember in one specific case, I got frustrated as I had spent quite a long time replying to a quite complex question with a good solution, then after I already did, Mr. Joe said the same things I said, in different terms.  and the person asking the question would thank him and ignore me.

Guess what? The person asking the question thanked Mr. Joe and completely blanked me.

Can you imagine? Somebody asks a question. I give him the right answer. Mr. Joe gives him the right answer after me. Mr. Somebody thanks Mr. Joe and blanks me.

I knew something was wrong and I started trying to find patterns, similarities and differences between me and Mr. Joe.

Then one day it hit me.

I was answering to “say the right thing”. Mr. Joe was answering because he cared that the person that asked the question would learn.

I felt stupid and ashamed of myself. I was really down. I realised how self-centered and selfish I had been while acting righteously as the “saviour of agile”.

Discovering bad things about ourselves is painful, but life has taught me that it is also the best thing that can happen to us because that’s the time we can make a decision to change and improve our lives.

I changed, bit by bit, slowly. Before answering any question on the forum, I started asking myself:

This person came to a public forum and asked for help on a subject he doesn’t know well, how might he feel?

How might this answer affect his feeling?

If I say this will he feel bad? How about I say it like this, same message but more positive, will he feel any better?

And it worked.

empathy

Week after week I started to get people contact me privately and thanking me for my time and help. They were telling me how my message had helped them resolve the problem.

I had been doing that exact same job for years and nobody ever did thank me. Then it became a stream of people thanking me for my help.

Be considerate, mindful, empathise with others. They will feel your empathy and compassion. They will want to work with you and their actions will also make you feel good about yourself.

It’s a win-win, we are both happy, why don’t you try?

Cross-dysfunctional teams

Every agile enthusiast will tell you how powerful an empowered, self-managing, cross-functional team can be. Once you have one, it brings complete team accountability from product idea to customer support, it naturally grows with continuous improvement, and finds self motivation in innovation and delivery of customer value.

It’s a beautiful and powerful concept; the practical implementation sometimes is not so beautiful and more often than not what you get, is a cross-dysfunctional team.

Let’s have a look at the cross-dysfunctional examples I have experienced.

Pseudo specialist cross-dysfunctional teamfarm-silo

Developer: “I am a developer I am not meant to test, the testers test!”

Tester: “I don’t need to know anything about how the product is designed, I only care about how the customers use it!”

Business Analyst: “I am not technical, I can’t help you guys!”


devops“As Long As It Works for us” cross-dysfunctional team

Developer: “It works in our environments, it’s operations responsibility to make it work in production”

Tester: ”Listen, it worked in UAT, it must be a configuration issue, or a missing firewall hole and nothing I could have spotted during testing…”

Customer: “Hello! Nothing works here…”

Abdicating cross-dysfunctional teamheadinsand

Developer: “The architect told me to do it like this”

Tester: “Feck it, let the Test manager deal with it”

Business Analyst: “I don’t think there is any value in this story, but the Product Owner wants it, so get on with it and develop it!”


no-thanks-were-too-busyContinuous Decline cross-dysfunctional team

Developer: “No point in doing retrospectives, things are always the same”

Tester: “We DON’T HAVE TIME to try new things!”

Business Analyst: “We do it like this, because that’s how we do things here, and that’s it!”

Disintegrated cross-dysfunctional teamWorked-Fine-In-Dev-Ops-Problem-Now

Developer: “My code works perfectly, it’s their system that doesn’t work, who cares”

Tester: “We have 100% coverage, all our tests pass and we have no bugs, if the developers of system X are idiots, there is nothing we can do about it”

Customer: “And still, nothing works here…”


ihazsuperiorityNazi cross dysfunctional team

Developer: “Testers are failed programmers, they shouldn’t be called engineers”

Tester: “Developers are only able to produce bugs, the world would be better with more testers and less developers”

Business Analysts: “I don‘t know why I bother talking to testers and developers, they are total idiots”

Do you recognise your team in one of the categories above? What have you done until now to help your team change? Little? Nothing? But you are still bitching about it, aren’t you?

Remember, you are very powerful and can become the change that you want to see.