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

3 Simple Steps to Help Overloaded Teams

dublin-rain-491-390x285It was a wet and dark morning in Dublin when I sat with team X for the first time.

I had been told: “Gus, these guys are struggling, they really need your help. They are always late, and everybody complains about the quality of their work, it’s bad, very bad”.

I expected a demotivated team of technically poor developers with its members playing video games or youtube videos instead of doing their job, but I was wrong.

No developer was slacking or pretending to work, on the other hand, I saw people with worried faces shuffling around, some listening to angry customers, some head down into code, some testing and quietly cursing.

To a newcomer, they looked super busy and doing their thing.

I perceived the first hint of trouble later in the day. I went to talk to some of them, just introducing myself and telling them that I was going to work with them to try to make their life easier. Each and every one of them was too busy to talk. All of them had something urgent, being a production issue, being a customer waiting behind their backs, or a release they had to finish by 5pm. Sorry, sorry Gus, I really can’t now, I have this blah blah…

I took it in and let them alone for the day. The day after, I kept on observing without saying a word. The amount of pressure that I saw applied on to these poor kids was frightening. In the same day I saw 8 different people go to the same developer and demand he finished something he was meant to have finished already. The requesters were different people and asked for 8 different things, all quite angrily.

The subsequent days, my observations stressed more and more this situation, the people were pushed over the limits and by trying to finish things quickly and relief some of the pressure were skipping steps and introducing new problems, new issues to work on, and so on.

I kept on observing and asking questions here and there, but the people saw me as somebody that couldn’t help them with the code, hence quite useless. I had to do something different.

On the 4th day, in the morning, after their standup, I told them to stop doing what they were doing and come and have a chat with me.

Believe it or not, It was almost impossible to get them off their seats.

no-thanks-were-too-busyThey felt they could not leave the sinking ship, they needed to continue trying to flush the water out with their hands. Did I have a powerful drain pump and could save the boat easily? They didn’t have time to learn how to use it, they needed to keep on shovelling with their bare hands.

I eventually got them into a room. We had a retrospective. I disguised the retro to be something else, because I had heard from one of the developers: “we don’t do retrospectives anymore, what’s the point if we don’t have the time to change anything?”

That’s a very valid question. Very.

The team was obviously overloaded and didn’t have the maturity and the necessary negotiation skills to express that to their customers and stakeholders. They had reacted to the overload with what I call the “headless chicken approach”. It works like this: “Just do all you can, forget about quality, process, product, customers, just run for your life and even if your work product is terrible, people won’t be able to blame you, as you work like a donkey every day.”

fuck-it-let-s-just-panic-and-run-around-like-headless-chickensDo you think this is uncommon? Well think again.

The first step we took was to visualise the work in progress. The guys were using Jira with no physical board and didn’t realise how much work they were really taking on. The board was scary, full scary I mean.

As the work came from many different products, another thing that we did was separating the products into different classes of service.

By doing this we immediately saw that one product had most of the tickets, why? We don’t know yet, but at least we are aware of it now.
After this very simple step  the team members started having conversations that were beyond the need to finish MyNewFeature, they started looking at current priorities and talking about the whys of the bad situation they where in.

Then they started talking about experiments to fix it.

They were improving the system.

I looked outside the window, the sun had come out.

p9220189_dublin_hapenny
What were the 3 steps we made that enabled the behavioural change?

  1. Acknowledge we were in an unsustainable situation that needed changing
  2. Agree the team had the responsibility and the authority to improve it with my support and management agreement
  3. Visualise the work they were already doing

 

Just this small change had transformed a group of intelligent people acting like headless chickens into people that were trying to improve a complex system, not bad for a weeks work I’d say!

If you are curious stay tuned and I will tell you what happened next, no more chickens, I swear.

The new episode of the story of Team X is out

Stop moaning – Be the change!

You feel like this
You feel like this

People moan, it’s a natural thing. It is a way of reacting to difficult situations where we are not able to change outcomes. By moaning, we feel some relief in sharing our discomfort with our friends, family and colleagues.

I confess; I have a problem with moaners because I don’t believe there is anything positive about it and it doesn’t really cut it for me. If I am not happy about something and moan about it, I normally become angrier rather than feeling any better. If I am really unhappy about something I would rather rant for 5 minutes, than moan all my life.

People see you like this
People see you like this

I am sorry to say it, but testers are in my experience the worst category of moaners in IT, maybe at pair with tech support people, but I’ll focus on testers here because I am one.

Testers moan about developers that don’t understand the customers, moan about business analysts that can’t write requirements, moan about managers that don’t give them enough resources, moan because they talk and people don’t listen, moan because sometimes they are paid less than developers, moan because the environment is not working, moan because they find bugs, moan because they don’t find bugs, moan because the application is delivered late to them, moan because the quality of the application is not to their standard and find just about another thousand reasons to moan about.

While I can understand moaning coming from a junior or mid-level tester that has say 1 to 8 years’ experience, I cannot understand, accept or condone a tester calling himself a “senior practitioner” that moans about any of the above.

Senior practitioners are like moaning rock stars, they have all they need but keep on moaning
Senior practitioners are like moaning rock stars, they have all they need but keep on moaning

One simple reason: a real test practitioner is able to face up to every single one of the moaning causing issues and is well able to change them.

Dear senior test practitioner, It is not acceptable that if management doesn’t give you enough resources, you are not able to influence them into understanding that they are making a mistake and need to release more resources, it is not acceptable that the developers don’t understand the needs of the customers and you are not able to come up with a solution that can minimize or even completely resolve the issue.

It’s NOT acceptable.

If you want to call yourself a senior practitioner, then act like one; influence and change the environment you are not happy with. What’s the point in moaning? You will bring down the rest of the team with your negative whiney attitude, won’t resolve anything and will piss off everybody else outside your team that is so unlucky to have to listen to you.

Senior Moaner – “Yes but management don’t understand!”

This is the ultimate answer of every senior moaner. The reality is different though, in fact 60% of the moaners didn’t even talk to managers to suggest a solution, 15% of them have tried and failed because they weren’t able to make their point and influence management, 20% have tried but management were right all along and they keep on moaning hiding the truth, finally 5% of them have tried repeatedly and appropriately to influence managers, but management are actually stupid and don’t understand.

Moaners Distribution among Senior Test Practitioners
Moaners Distribution among Senior Test Practitioners

Now look at that chart, where are you? If you are in the 5% that already did everything they could, but hit a rubber wall, then I suggest you change job before your moaning alienates you from the rest of your team mates, your wife and friends, in the other 95%, simply stop moaning, do something meaningful with your job, be brave and BE THE CHANGE you moan about!