A short report on my agile experimental talk

Last week I asked the community for help on designing an agile talk rather than a talk on agile .

If you don’t want to read the full article here’s the TLDR: Can we embed the agile values in the format of a beginners talk so that people will learn by breathing them rather than hearing about them?

I received quite a lot of encouragement from a lot of people. I love the agile/lean community, thank you folks, you are incredible!

I got some great suggestions from Patrick Steyaert that recommended looking into Lean Coffee and Fish Bowl.

Both formats are highly participative and pretty much agendaless and gave me a great point to start at.

My goals in priority order:

  1. Do not bore an audience that for the first time hears about agile. Don’t push them away!
  2. Identify a format that embodies the values I believe to be the most important in agile and make sure the attendees feel and recognise them while they are attending
  3. Make sure people actively participate
  4. Have fun

To me the most important values in agile are: people, customer and responding to change.

The People

I asked 3 fantastic practitioners to help me on the day. The 4 of us were “the agile product team” that was going to deliver the product (learning) to our customers (audience)

Thank you so much to Claudio Perrone, Andrea Baker and Lisa Hickey for accepting to help with less than 24 hour notice and no details whatsoever on what i needed them to do (isn’t this ability to respond to change? :-))

my teammates.png
My Fantastic Team Mates: from left to right Claudio, Andrea and Lisa

The Customers

I told the audience that me and my team mates were going to give a product to them, they were our customers and as such they were extremely important.

To start we needed the customer help to understand what real value is to them.

We asked them to select with dot voting some agile topics from around 35 different agile topics (I took a subset including mainly basic concepts).

The topics were taken from ‘s wonderful Agile Topics card deck that I printed and laminated (for the quite steep price of €50)

The customers immediately queued towards the table where the cards and the markers for voting were. We time boxed the activity to 5 minutes. Claudio, ever the lean man,  immediately identified a bottleneck as the table was too small and only 2 to 3 people could vote at the same time.

Customers queuing to dot vote (bottleneck)

The activity had to be extended to 6 minutes to allow everybody to vote.

The team took 6 topics with highest number of votes and put them on the wall in dot voting ranking order.

We started with the first topic.

It happened to be BDD: First thing, I asked the customers if they knew what it was. One of the people in the audience started giving us his take. When he finished, I spoke about it a bit, then my 3 team mates took turns in adding their perspective.

Responding to change

This lasted for 5 minutes when the timer went off and i asked the audience to tell us by using thumbs up or down whether they wanted to continue talking for 5 more minutes about BDD or if they wanted to move to the next topic.

People voted for sticking to BDD for 5 more minutes

After 5 more minutes we voted again and we went to the second topic.

We made sure that the team swapped activities, everybody took turns in talking about the topics, we alternated roles like time keeping and pulling the cards from the wall.

We wanted to show team collaboration and cross functional abilities.

The topics selected by our customers

I got loads of feedback from the people in the audience and the team.

Claudio suggested that when talking about topics, the first couple of sentences need to describe it in a easily understandable recipe format, this is true in particular because of the audience low level of agile knowledge.

Davide Lovetere an enterprise Architect among our customers gave me a lot of incredibly valuable feedback around some contradiction in terms he had noticed during execution.

Other customers said that they enjoyed the format and want to use it for some of the meetings they do in work (yay!)

Other customers said that they enjoyed it but it finished too early, we only had time to talk about 4 topics and they would have loved to touch more

That’s me having a ball as usual when I speak at conferences 🙂

I loved doing it, received valuable feedback to improve it and can’t wait for the next time!



How about an agile talk instead of a talk about agile?


Here’s the thing, next week I am going to speak at the Agile Tour Dublin . My talk topic is in the beginner track and it is a Quick Introduction to Agile.

How do I keep people awake and deliver something that will be valuable?

I could start with a timeline of the events that brought us to the manifesto and then continue towards the different frameworks, mention the important people, talk about the values etc.

Well, I could, but maybe nobody would care.

I could talk about how agile requires a fundamental change in the mindset and discuss potential problems people might find once they embark into a change journey.

Maybe slightly better

Or I could focus on the values and principles in the manifesto and explain how they apply to what people do within organisations

But people might go back asleep, etc.

Fundamentally I think that no matter which of the 3 approaches I take, it might be something that people could get from reading a wikipedia page, not good enough for my customers!

So I thought, how about I do an agile talk instead of doing a talk about agile.

How about before the start I ask my customers (the audience) to pick from a set of topics they want to hear about. And how about I get the audience to give me feedback while I deliver so that I can react quickly and change the subject when it is not giving value any longer?

This would embody the close customer collaboration, the fast feedback and the ability to react to changing conditions.

Also, how about I ask the audience if they want me to speak for exactly 30 minutes and go through all my slides or if they believe that they can collaborate and give me feedback so that I might be finished 10 minutes earlier if the topics are complete or maybe even 5 minutes later if they still need some answers.

This would reflect the customer collaboration over contract negotiation

How about if I told them that I am not going to send them the slides by mail but I am available all day long to talk to each and any of them discussing the content of the talk.

This would sound like face to face collaboration over processes and tools

Wouldn’t this format also embody Working software over comprehensive documentation?

Do you think a format like this would be valuable?

Do you have any other suggestions to do an agile talk instead of a talk about agile?

Please help me by using the comments or mail me at augeva@gmail.com






Testers: what’s your strategy in a continuous delivery context?

smallbatchIn my last stint as a tester from October 2012 to Jan 2014, I helped my organisation at that time moving from delivering once every month, to delivering multiple times a day.

Let me first clarify that we didn’t move to multiple deliveries per day just for the fun of it, but because we needed it.


Your organisation might not yet know it needs this level of agility but more than likely it will at some stage in the future.

How did this transform the role of the testers within the organisation?


The start

When I joined I found scrum teams that delivered either once a month or once every 2 months. The teams had 3 different defects management databases full with old and new defects. Testers were doing the following activities:

  1. automation (~30-50%)
  2. exploratory testing (~50-70&)

The batches were big, the exploratory sessions were long and found a lot of defects. The automation was not effective, as it was slow and unpredictable, its value was negative.

When I left

When I left, we were using kanban, delivering multiple times a day, defects were more or less a myth of the past, no defect management tool existed. Testers were doing the following activities:

  1. Three amigos BDD sessions with customers and developers
  2. Exploratory testing (1~5%) – never longer than 10 minutes per card, more often than not reporting no defects
  3. Pairing with developers
  4. Coaching developers on testing
  5. Writing automation (0%)
  6. Talking to the customer and the team
  7. Improving the system
  8. Designing the product with the team and the customer
  9. Helping define what to monitor in production
  10. Any other valuable activity the team needed them to do

As you can see the activities that before occupied 100% of testers time, now occupy from 1 to 5% of testers time.

Were testers busy before? Yes, absolutely

Were testers busy after? Yes, absolutely

Were testers complaining because they weren’t doing automation or enough exploratory testing? No, believe me. Most testers I worked with saw the new activities in the role as a learning activity and an opportunity to broaden their skills and become more valuable to any company.

If a tester didn’t want to adapt to the new reality and embrace the change and new ways of doing things, he would have been busy for 10 minutes  a day (~2%) and he would have not been useful to the team.

Did we get there with the touch of a magic wand? No, the end stage was the result of many experiments. It was, back then, a good recipe for that context at that time (it is continuously changing)

So, tester, what’s your strategy for working in a company that releases multiple times a day?


The magic talking board

This is the second episode of the adventures of team X, if you haven’t already, read the first part of the story

Things looked slightly less grim now. We had visualised the work that was coming through and at least we could see how deep the hole we had dug for ourself was.

For a team of 8 (programmers testers and analysts) we had something like 60 work items in progress, it was gigantic, daunting and scary.

But that was huge progress, because now we knew it was there. Now that we could see it and show it, we could do something to stop it from happening again.

messy-deskLittle we knew that what we had created was not only a board, what we had created was a living and talking entity, you don’t believe me? Read on.

The morning after we built the board, Zach appeared, he was the most unreasonable customer in the Northern hemisphere, known for his famous saying “take this ticket, if you finish it last week you are late”. He walked hurriedly to the team area with his usual bunch of new unbelievably urgent tickets to work on.

While he was walking, I swear, I thought I heard the music from “The good the bad and the ugly” such was the tension in the air.

Jimmy, a developer, told him: “Hey Zach, yes, we will work on them but we need to finish these first” pointing at the board.

Zach wasn’t happy, squinted and said, “but this is urgent! I need it now!”.

Jimmy was relentless, looked at the cards that Zach had already in progress on the board and said “that’s fine Zach, no problem, have a look at these cards on the board, they are your 6 tickets already in progress, if your new two are more urgent then let’s replace them”.

Zach eyes widened with disbelief, looked at the other cards and said, “but, but, but… I, I, I… need, need , need… …well no, those are more urgent, work on these new 2 only once you are done with the old ones”, he said goodbye and went back to his office.

From Top to Bottom: Jimmy, Gus and Zach

Jimmy the developer had defeated Zach, the fastest ticket-slinger in the company!

The team X guys looked at each other, high fived Jimmy and noted that the board had told the customer what they had been trying to say for the last 2 years, i.e. “we are too busy we can’t take more work”, but for some magic reason now that the work was visible, that conversation was much easier and Zach was not shouting anymore, miracle!

This small event made the team determined to always make sure that their work was visible on the board, the board was a silent ally, they won’t forget to feed it!

If Zach had been brought to reason, what else could the board help them do?

Gus said, now the fun starts, let’s talk about setting a WIP limit…

Wanna know what happened next? Is the WIP limit going to make the team even more powerful? Stay tuned for the 3rd episode to find out what Jimmy and the team X lads get up to!

The new episode is out!

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.

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

The art of doing 1/15th of the work and getting earlier business outcomes

imagesIf you are an agile practitioner you are likely to have read the book “Scrum – The art of doing Twice the Work in Half the Time” from Jeff Sutherland. I am a fan of Jeff and I believe that what he has done for software development in the last 20 years is great.

I do have issues with the book’s title though.

That title is what makes people think that being agile means being able to go fast and deliver more stuff.

Is this what real agility is?  Let me tell you a story.

At a client of mine a couple of years ago, I was asked to coach a product team and help them with a new product they were starting to work on. I was excited about it and asked the product owner to meet for a coffee and initial chat.

He kindly agreed and told me: “before we meet, have a look at our requirements document so you will know what the topic is”. He also told me that a high level estimation had been done and that the product would take from 6 to 8 months based on one agile team and that there would be licensing costs associated with an automated scanning system we had to acquire.

Attached to the mail there was a document of about 50 pages with detailed workflows, low fidelity prototypes of the screens and quite a lot of explaining text. I skimmed through it looking for a description of the problem that the product was meant to resolve, but couldn’t find it.

I read and reread the document and I couldn’t find the original problem that the product had to resolve, it was not there.

When I met the product owner, after agreeing the weather was miserable (that’s how we start any conversation in Dublin regardless of the season) he started describing his solution. I let him explain to me the beautiful features to build and the amazing technologies we were going to use.

When he was finished, I asked him: Why are we building this?

The initial reaction (completely normal) was a defensive stand for his solution. When I probed more, it was clear that after having worked for so long on the product on his own he had forgotten the nature of the initial problem that triggered the decision to build this product.

Using the 5 WHYs technique, in about 10 minutes, we eventually got to the initial problem that we needed to resolve.

At this point the conversation became different.

I asked what he thought were the features we should prioritise to resolve the problem so that the customer could have something earlier than in 6-8 months. That triggered the interest in the PO that identified 5 features (about 30% of the total described in the document).

I then took each feature and asked him if it was necessary to resolve the problem we just identified. After another 10 minutes we agreed that 1 single feature, that accounted for about 1/15th of the initial solution, would resolve the customers problem. To avoid making the PO feel bad about having done so much unnecessary work, I told him that we would build the other features incrementally, and that it was a great success that he had identified a single feature that would be useful for the customer almost immediately.

We then agreed to identify outcomes of success for the full product and start measuring immediately as soon as we released the first feature.

These read something like:

“We will know we have succeeded when 30% of customers do X instead of Y” or

“We will know we have succeeded when we will have 40% less support calls related to problem X”

et cetera. I made sure the business outcomes were related to the initial problem, not any product.

What ended up happening is that we built the first feature in 2 weeks (opposed to 6-8 months) and the measurements told us that we had reached what we wanted already.earlierbusinessoutcomes

We never built the other 14 features, we stopped because the business outcomes we had set were reached.

And yes, you guessed, we didn’t have to buy the licenses for the automatic scanning system either.

As a coach, my mission in organisations is to guide teams and navigate problems, maximising value with minimum work. This is always welcome when meeting CTOs or CIOs because – most of the time – less work means lower costs and earlier delivery.

We did 1/15th of the work and got business outcomes earlier, a big improvement IMHO from “doing Twice the Work in Half the Time”, what do you think?

What I like about Jeff Gothelf’s lean UX approach

Product development has been my focus (more like obsession) for the last few years. I have read all the books and experimented with many of the approaches from lean canvas to impact mapping to the 100 different ways of framing an MVP.

While experimenting I had some success, many failures but in general I have been left with an after taste of something missing. Sometimes I failed to engage by using the wrong language, some other times I failed to even get started because some people just don’t want to hear that they might be wrong and are threatened by experiments that might just show that.

I had the fortune to attend the workshop “Lean UX in the enterprise”  with Jeff Gothelf in Stockholm yesterday and I think I might have found a simple tool that can help me frame the conversations and get results.

Jeff is an excellent facilitator. During the workshop he gets teams of people to design a product. I was really impressed by the simplicity of the approach and the universality of the language used. But most importantly, at the end of the exercise, making decisions on what to build first becomes trivial.

His approach is linear, simple, easy to reproduce and will resonate with anybody with some understanding of lean and agile. I have to say this is a breath of fresh air in this space where some of the authors sometimes feel they are not great if they don’t introduce some new unnecessary term that creates ambiguity and confusion (but also a lot of discussion and website hits for them).

I am going to experiment with Jeff’s approach for the next product I see, I really look forward to it. Thanks Jeff!gothelf