How to maximise the work not done

Recently, due to a new exciting engagement, I have been thinking a lot about simple ways to explain the advantages of iterative incremental delivery over big bang releases. When speaking to C-level executives, coaches like me often have very little time, so we need to be able to engage with language they understand to make those few minutes count.

Money and impact on revenue seems to be a topic that is widely understood and accepted, so I have used and will use it during those conversations. My recent musings have brought me to a place where there is a currency that for modern organisations might be more important than revenue itself. Knowledge.

Now, let me expose differences between iterative incremental delivery and bing bang releases in terms of revenue and of knowledge.

Let’s start with revenue.

This picture is probably familiar to most of the agile/lean coaches out there and it is a good one to start the conversation on why releasing often while monitoring our customers behaviours has an immediate positive effect

revenue

From the picture is clear that incremental delivery has an earlier return on investment, while for big bang we have to wait until time t1 to get any return.

This is quite powerful but I don’t think it tells the full story.

Can we express the differences in term of something else?

To look at other aspects of the full story, we need to start visualising a different dimension than the usual revenue or $.

This new dimension is the currency of modern organisations, and it is called knowledge.

Let’s look at what happens with knowledge in a big bang delivery approach:

bigbang

At the start of envisioning and planning we start building knowledge about what the customer wants but at the same time, being humans and fallible, we start building wrong assumptions about it. We will get full knowledge (wisdom) only after the release date t1. At that point we will be able to validate our assumptions and will build the knowledge about what the customer really wants. Isn’t it a bit too late?

Now let’s look at the same dimensions for an incremental iterative delivery

incremental

As we can see, even in our iterative incremental world we build up wrong assumptions about what the customer wants, the difference is that we disprove them very quickly by delivering early and validating them through customer behaviour. This reduces the risk of building assumptions over wrong assumptions but most of all frees our mind to look at how the customer behaves using our product and understand it better. As you can see the assumptions get eliminated and rebuilt often but the knowledge grows continuously. This is very different from our previous graph, what happens if we overlay the two is the following

Maximising the amount of work not done

Every time we deliver a small increment we must ask ourselves 2 questions:

  1. Have we satisfied our customer needs?
  2. Do we still need to do more to satisfy them?

worknotdone

Given K the point at which we can answer one of the 2 questions with a NO then a decision that impacts on the amount of work to be done can be made.

Case A: If at point K i have enough knowledge to decide that I have done enough to satisfy the customer and any other added work will have diminishing return on investment, I can decide to stop.

Case B: It at point K I have enough knowledge to decide that the customers aren’t happy with the product and I am losing revenue, I can decide to stop.

In cases A and B the red area is the work not done as a consequence of my decision. Such decision could not be taken with the knowledge gained with a big bang release if not AFTER the release and all the work had been done.

So, in conclusion, you should use iterative incremental delivery to maximise the amount of work not done. This way, you will save money on work not done, will have the opportunity to spend that money on something your customers really want, obviously through iterative incremental and knowledge seeking delivery.

Advertisements

Test coach versus test specialist, impact on queues

I recently had a very interesting conversation with a group of skilled testers on whether or not there should always be a test specialist in a cross-functional team.

A lot of people say yes, my personal experience says not.

My personal experience tells me that the most effective and efficient approach uses a test coach that slowly makes himself scarce. My experience focuses on creating competencies for completing an activity (testing) in a collaborative context.

One aspect I am finding difficult to explain is the impact on queues of a test coach approach, I will use a series of Scenarios and pictures to facilitate my reasoning.

If you feel like substituting activity A = development and activity B = testing feel free, but this approach is activity agnostic in my experience as I have applied it to analysis, and development obtaining similar results.

Scenario 1 – Test specialist

In the presence of one specialist on Activity B and many specialists on activity A.
Problem: Long q
ueues form in Ready for Activity B (Case1) or worse specialist multitasks on many activities at the same time slowing down flow of work as per Little’s law (Case2)

Screen Shot 2017-05-29 at 10.40.47

Scenario 2 – Test coach

Stage 1: In the presence of one coach on Activity B and many specialists on activity A
Initially coach pairs on Activity B with people that do activity A. This way we obtain 2 benefits:

  1. Queue in “Waiting for Activity B” is reduced as one person normally performing activity A is busy pairing with coach on one activity B task
  2. By pairing on activity B feedback loops are shortened
  3. Person with activity A acquires new skills to perform activity B from pairing with coach
  4. Quality of activity B increases as it is a paired activity
  5. Flow improves because of 1 and 2

Screen Shot 2017-05-29 at 11.22.49

Stage 2: When cross-pollination of skills required for activity B starts to pay off, we have 2 benefits

  1. Normally some activity A person will show particular abilities with activity B, in this case this person can pair with another less skilled activity A person to perform activity B
  2. Queue in “Waiting for Activity B” is reduced as more people with activity A skills are performing activity B
  3. Flow of value improves lead time decreases
  4. More activity A people get skills on activity B

Screen Shot 2017-05-29 at 10.56.00

Stage 3: All activity A people are able to perform activity B
Activity B Coach can abandon the team to return only occasionally to check on progress. Benefits:

  1. Activity A and activity B can be performed by every member of the team
  2. the WIP limit can be changed to obtain maximum flow and eliminate the queue in Ready for Activity B.
  3. The flow of value is maximised
  4. The lead time is minimised

Screen Shot 2017-05-29 at 10.58.05

WARNING: I have applied this approach to help teams with testing for many years. It has worked in my context giving me massive improvements in throughput and reduction of lead time. This is not a recipe for every context, it might not work in your context, but before you say it won’t work, please run an experiment and see if it is possible.

This is not the only activity that a good test coach can help a team on, there are many shift left and shift right activities that will also reduce the dependency on activity B.

I have been told a million times “it will never work”, I never believed the people who told me and tried anyway, that’s why it worked.

Try for yourself, if it doesn’t work, you will have learned something anyway.

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.

 

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!

Ultimate guide to use metrics to distract your teams and destroy your company

I have had a lot of conversations, with agile people and not, around the topic of measuring success of an agile team. I have heard all sorts of metrics thrown around, from velocity, throughput, number of bugs or lack thereof, and so on.

The fact is that those metrics are completely useless, let me tell you why.

Imagine that your team in a period of 3 months has increased its velocity from 24 to 48. What does that mean? Some people will tell you they are 100% better or even 100% more successful!

I say that they are 100% better at delivering stories (assuming they didn’t game the metrics)

More than likely they work in an organisation that measure success based on the old Budget-Time-Scope paradigm.

Unfortunately in your search for speed you are sub-optimising your system and not achieving the real goal of your company.

buildeverythingandpray
A team that bases success on the Budget/Time/Scope triangle I call it BuildEverythingFastAndPray)

What is a successful team?

A team is successful if they help the organisation they serve be successful, regardless of how many story points they deliver.

Let me tell you what a successful team measures.

A successful team measures business outcomes. What are business outcomes? Let me give you some examples:

1) x% increase week to week on downloads of your mobile app
2) y% increase in signups month to month
3) z% reduction of customer support calls month to month

or any similar outcome depending on your context where x,y,z>0

Why?

Because an organisation that obtains those outcomes is normally successful.

Even more importantly, the team will continuously monitor how their actions affect the business outcome metrics they have set to achieve so that they might decide to:

  1. Stop writing that feature, we have obtained the result and any further bell and whistle wont give us ROI
  2. Do more of this, the metrics are going in the right direction but not as expected
  3. Stop doing this and do something else, this feature is not producing the results we were expecting
  4. Ah, look at what the customer is doing instead of doing what we thought he would do! Let’s help them do it in an easier way…

 

 

buildmeasurelearn.jpg
Build Measure Learn

Now compare this to delivering all the 1 zillion stories in the fixed scope at the velocity of 48 per sprint.

What’s a successful team for you?

 

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

asleep

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