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

 

 

 

 

Stop building a Shitload of products, you are killing your company

idreamoforganizations0awherepeopleareempowered0atodeliverproductsthat0amatterjoyfulorganisations0a28-defaultI took my first steps in technology over 20 years ago. If we exclude the year off I took in 2006 I have always been employed in many different companies and I can say with certainty that I worked on a “shitload of products” and I use that specific term with purpose, read on to find out.

During all these years, being somebody that loves learning, I ended up working as system analyst, developer, tester, business analyst, manager, leader, coach, change agent, plus some other short term hats.

If I exclude the last 6-7 years where I had the skills and the ability to influence decisions I can go back and say for sure that the products that were initially envisioned, before any customer feedback was used, can be called a shitload of useless stuff and one or two good ideas that resolve real customer problems.

Very often the product envisioned was very similar to the product that we delivered.

Am I saying that in my first 13 years I worked I mainly produced waste?

Pretty much YES.

Another thing I remember in those early years was that I was never in a team where we could say, oh thank god we are busy but it’s not too bad, we can do our work, go home and have a balanced life. Invariantly there was pressure. We need all this by that date, come on! Work faster!

To me, it always felt like we were told by Dilbert’s boss that if we shove some more paper in the printer it will print faster. Also, when we were not busy, then managers will fill our capacity with a new shitload of useless products created for the purpose to make people sweat, very often no thought on the customer whatsoever.

Am I saying that trying to deliver fixed scope, fixed date shitloads of products creates big problems to the workers that build them?

YES, not even the pretty much is needed this time.

Another thing that I have noticed through the years is that without exception, companies older than 3 years have already built a shitload of products that are now impeding their ability to respond to change and survive. We will call this “shitload of legacy systems”.

This specific shitload is used as the excuse for not being able to change, as if saying “yes sure, we can’t compete with the market and we will die soon, but it’s not our fault it’s the fault of the legacy system (that by the way we built)

Am I saying that the shitload of products are also causing the slow death of the companies that created it in the first place?

Yes

Next time you start a product, think twice before rewarding people for the delivery of all the scope, in time.

I have been helping organisations deliver products that matter to their customer as soon as possible, I am not in the business of delivering projects or shitloads of products.

I am researching new ways of demonstrating THE VALUE in MONEYof the “non built shitload of products and features”, if you are interested, let’s do this together.

 

 

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.

bottleneck.png
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
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

cufbzuuw8aazvyr
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!

 

 

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?

Massively

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

episode2newz
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.

goodbadandugly
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!

What you are measuring is wrong, let me tell you why

idreamofthedaywhen0aorganisations0awillbeabletofocuson0athereal0aproblemstheyface-default

There is one measurement that is commonly accepted when examining the effectiveness of delivery teams. Lead Time.

This is a definition from Wikipiedia.

A lead time is the latency between the initiation and execution of a process. For example, the lead time between the placement of an order and delivery of a new car from a manufacturer may be anywhere from 2 weeks to 6 months.

If software delivery team “LightningFast” is able to give to its customers product X in 1 week while software delivery team “SlowAndSteady” requires 4 weeks to deliver the same product we can state without error that LightningFast is better at software delivery than SlowAndSteady. In fact it is 4x better.

(For the purpose of this article let’s consider the quality of the product delivered by the 2 teams to be equal)

At this point we are considering the starting time to be when a development team has some form of requirements to start working on and finishing time when the bits are deployed to a production environment.

As a business owner you would want to hire team LightningFast and try to avoid SlowAndSteady, I agree with you.

Let’s imagine that team “LightningFast” works for “BestProduct.com” and “SlowAndSteady” works for “WeAreTheBest.com”

l

The CTO at WeAreTheBest.com would willingly spend a lot of money for either replacing SlowAndSteady with LightningFast or coaching SlowAndSteady to lower lead time and become more like LightningFast.

But the business world is not a software delivery speed contest, it is much bigger than that.

Follow me and you’ll discover that even if you have team LightningFast in your organisation you might have bigger problems to solve.

Let’s expand a little our concept and start looking upstream (left).

Team SlowAndSteady have a very effective way of transforming their roadmap into actionable requirements and are able to complete this specific task for product X in 2 days. Team LightningFast don’t have a lot of skills on this department and spend a lot of time upfront to create the requirements. In the specific, for product X it took them 4 weeks.

So let’s calculate lead time one more time.

LigntningFast => 1 week + 4 weeks = 5 weeks

SteadyAndSlow => 4 weeks + 2 days = 4.4 weeks

Okay, does this mean that SteadyAndSlow are more effective than LightningFast? It would seem so. The starting point for the calculation of the lead time changed completely the judgement we had built over the effectiveness of the delivery teams.

This seems interesting, what’s next?

Next is a different question. The question is what is the lead time that we should be measuring? What’s the lead time that is important to our business?

The answer, unsurprisingly, is the whole. From start to finish.

Now, let’s walk backwards to see where the start is.

Next bit I would add is the time that product X took before it got prioritised and given to the delivery team to work on. In many cases, companies have an Enterprise Portfolio from which the Products get selected from when prioritising.

WeAreTheBest.com (the home of SlowAndSteady) have mastered a very good prioritisation process and priorities are continuously assessed based on market conditions, customer feedback and active monitoring so when a product becomes the highest priority for the company the process signals it clearly and they can start creating a roadmap within 1 week.

BestProduct.com (the home of LightningFast)  are struggling with prioritisation, they are not aware of how their customers use their products and have no intention of using customer insights to make decisions on what to build. They rely on the CEO that is the smartest person in the company to decide what gets prioritised. The CEO got it wrong this time and should have started working on product X last year when  it was added to the enterprise portfolio. It took 1 year for the product to get picked up.

Ok. Now things are interesting.

BestProduct.com => 1 week + 4 weeks + 1 year = 1 year and 5 weeks

WeAreTheBest.com => 4 weeks + 2 days + 1 week = 5.4 weeks

Wow, more than a year difference between the 2 companies, this is incredible!

We could go on and on going back to the moment the idea appeared in that company for the first time and add the time lag between the idea appearing and the corresponding product materialising on the Enterprise Portfolio or even go back further and research when for the first time social conditions emerged a problem to be resolved for customers that will be eventually resolved by product X.

I have seen many enterprises and many delivery teams. Don’t take my word for it, look out there, delivery teams effectiveness is equated to how good they are at doing the Requirements to production transition.

This creates a need for improvement localised to that context. A lot of money is invested and spent to resolve the last bit of the ride, while monstrous inefficiencies slow down delivery in measures orders of magnitude bigger.

the narrow focus on a sub-system is called sub-optimisation and it is a very well known concept in systems thinking and lean but it seems to have flown over the heads of most of the agile community.

Still today, a lot of agile experts focus almost exclusively on technical aspects and are not concerned with resolving the real problems in the system.

Do you want to know more about this?

Do you want to know how to identify the real problems in your system?

Give me a shout and let’s have a chat!