Collaboration and roles, learning from Rugby union

rugby

I keep on hearing team mates say things like

“it’s not my job to test, I am a <insert_role>” or “It’s not my job to design the product, I am a <insert_role>”

and I am quite tired of the behaviours caused by the message when left unchecked.

A team is more than the sum of its parts, a team has the power of collaboration.

When I was young I used to play Rugby (union).

Rugby union is a highly specialised sport, in fact the 15 players on the pitch are divided in 2 main silos, “forwards” and “backs” and within the silos there are these following roles:

Forwards: 1. Loose-head prop, 2. Hooker, 3. Tight-head prop, 4 and 5. Lock, 6. Flanker, 7. Wing Forward, 8. Number eight, 9. Scrum half

Backs: 10. Fly half, 11 and 14. Wing, 12. First centre, 13. Second centre, 15. Fullback

WOW 13 different roles for 15 people in the same team, more than the usual PO/BA/DEV/TEST/UX etc. we find in modern agile teams. How come they are able to collaborate so effectively?

The difference is that nobody in a rugby team will ever use a sentence of this type:

“I am not doing X because my role is Y”

In fact the very best rugby players are not the super specialists but the ones that are good at every different skill and activity required to play rugby. (Research the case of Brian O’Driscoll to me the synthesis of excellence in collaboration skills)

When there is a ruck 2 meters from a goal line you will see the ten stone (63Kg) Scrum Half stick his head in and push the 15+ stone (95Kg+) players away from his goal line.

He won’t say, I’m a scrum half I don’t do rucks, I guarantee 100% he won’t, because if he does he will lose the respect of his teammates, his coach and his fans and never play the game again.

Why do rugby players collaborate so well even though they are such a specialistic group? Because they have one clear goal, the clear goal is to score more points than the opponents. They all get that and do their utmost to help their teammates achieve it.

Why are agile teams not collaborating like rugby players?

One of the reasons is that they don’t see a common goal in the customer value to be delivered but see the beauty of the “elegant code”, “smart test strategy”, “beautiful solution”, outstanding “user experience” and so on.

So if you want to get your team to collaborate better together you got to give them a common cause to fight for. And just to save you time, it is not lines of code, story points, tests passed, number of bugs or lack there of, it is something bigger and more important.

Discover what it is together with your team.

 

Advertisements

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.

The hidden dangers of Process Debt

Most of us involved in software development are familiar with the term “technical debt”.

As a quick reminder, it was introduced by Ward Cunningham to describe the phenomenon that occurs when we use code that is easy to implement in the short run instead of applying the best overall solution we have identified.

It is by definition a conscious decision to take a shortcut for short term gratification (like taking out a new credit card for a holiday) that in thew long term will cost us to spend extra time in development when improving the system (like paying interest on the credit card debt).

Until the capital is repaid in full we will always pay interest when adding features to the system as the debt creates obstacle to adding new code efficiently.

Ward suggests that when we are in a situation of rushing something out we need to be conscious that we will have to pay the capital in the future or the interests will cripple us.

Ward suggests refactoring as a solution to paying off technical debt.

I really like Ward’s vision and I want to expand the metaphor one level up.

Now if we change the word “software” in my description of technical debt above with “processe” we can define Process Debt.

Replacing we get:

Process Debt is the phenomenon that occurs when we use a processes that is easy to implement in the short run instead of applying the best overall solution we have identified.

Let’s look at one example

You notice that lately the system seems to be more unstable than usual. You know this because there are more calls from customer care and more defects get raised.

Option 1: You want to get to the bottom of the situation and believe that a root cause analysis with 5 whys could get you there. If you use this approach you will probably identify a change in your process to help you prevent some defects in the future.

Option 2: You implement a better policy for developers to select the defects to work on reducing the time the defects are in the unresolved queue while maintaining new features creation throughput relatively stable.

You know Option 1 is better in the long run because it will generate a change in the process to reduce the amount of rework. This will mean less time spent fixing and more time spent on new features that as a consequence means higher throughput and lower lead time for new features.

Option 1 requires some investment. You need to hold one or more root cause analysis sessions, identify the problem(s) experiment with solutions until you find a solution that mitigates your problem.

If you are under pressure, because the new product needs shipping and the old defects need fixing, you are likely to choose option 2.

By doing this you have introduced process debt

The capital of this debt is the lack of change in the process  you could have identified if using Option 1.

Oh, yes, I forgot, change is difficult.

The worst part of it is the interest on the debt you will pay forever until you pay the capital. This interest will appear in the form of.
1. bugs keep on coming, we seem to be fixing bugs all the time
2. new features get delayed because now the queue is in the new features to be delivered
3. the lead time of any new feature is expanded by a factor X
4. the customers continue on complaining because of your defects in production
5. your product owner starts being annoyed at the amount of work spent by the development team on defects
6. developers are tired of always fixing defects
7. …
n. need I say more?

This interest will be paid for the rest of your life if you don’t fix the problem.

Months after you are covered in defects, are stressed by your customers and change job.

Is this healthy? Certainly not.

Is there a cure? Oh yes, indeed.

Continuous improvement has the same effect on process that refactoring has on software. It repays the capital of your process debt.

With small changes in the form of experiments you will be able to clearly discuss the problem that the team is having and make small tweaks continuously.

My esteemed colleague and fervid innovator Claudio Perrone presents his continuous improvement model called PopcornFlow saying

If change is hard, make it continuous

I could not agree more.

By making process change a continuous activity, we enable behaviours that will stay with teams forever and we unleash the power of people’s creativity in improving their own way of working.

 

 

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.

 

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!

 

 

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