"What was that? You want to know more about my day and all the fun I had with your daughter's teacher telling me how she wasn't LISTENING to anything she was being told...."
Yes. I am in trouble again for not listening. Totally my fault this time, I got distracted and missed a very important part of what my wife was saying and never quite caught up.
The talking to herself in the third person is an coping strategy mostly to give me another chance to join the conversation as well as being the equivalent of counting to ten before exploding- I can be challenging to live with.
Every time this happens, I am usually doing something else. Whilst I can have many threads spinning away in the back ground, I can only ever have one being actively done - so in checking the post and listening to my wife's day, I inevitably drop something. And it's usually the wrong one.
To prove the world is in balance and everything has a positive spin, I am going to explain how and why not listening was one of the better things I had to learn to do as a Scrum Master:
1) Trust - the detail of what is being delivered is my team's responsibility and I trust them to make the right choices. I have learned over time to disconnect from the detail of what they are talking about and only dive in there is something they need to observe or think about. I like to think of it as filtering and reacting to key words or phrases (more about that in a minute).
2) Non Verbal clues - being involved in the conversation means my attention, running on that single thread is consumed by that alone. I am missing body language from individuals (who's bored, distracted, confused, agitated, annoyed) . This might be revealing how they are sitting, fidgeting, facial expressions - all of which need you to observe and process. These are cues for a good facilitator to jump in, to draw out something that might help us as a group.
3) Who's not speaking - some people are quiet but that does not mean they don't have something to say. Most teams have a dominant character or 2 and it can be all too easy for them to take over. Watching who is not speaking, along with body language allows you to pull them in and give another voice to the conversation.
4) Highlighting issues - I have learned to filter and listen for key phrases. I use these to help the team realise issues or change the conversation they are having. So if I hear things like "Maybe...", "What if...", "I guess..." I'm starting to think there is a little uncertainty in the air. Are we making an assumption? Is there someone we can get to help us with this, if we don't understand it fully? If I hear "Could we..." from a couple of people then maybe we are in whiteboard territory and should be drawing this out rather than trying to explain it. The cues can we quite unique to the team but some are universal.
5) Facilitation - freeing up that single thread means you can help out! We can capture that conversation in notes, write up stickies or actions, repeat and confirm with the team to move conversations along. We can structure the conversations to provide a background for the team - I have noticed that talking about the things we find hard first usually yields better results e.g. deployment, testing.
Allow your team to get lost in the detail but know when to pull them back again. This can only happen if you are the observer and not caught up in the moment with them.
Obviously you probably want to the opposite during a retro. And when you significant other is talking to you.
Showing posts with label conversations. Show all posts
Showing posts with label conversations. Show all posts
Thursday, 9 June 2016
Monday, 20 July 2015
Describing value using Situation Cards
EDIT: I have since found out that Situation Cards are really similar to Social Story and Comic Book Conversations.... read more here
A while back I wrote about situation cards, which Dan Rushton and I came up to help connect developers with the reason why we were doing a particular story.
Our team works on systems where we are essentially passing messages between different services which is particularily difficult (read: boring) to demonstrate in the review. We all hate Powerpoint but looking at Fiddler or SoapUI is way more dull.
Dan's brainwave was to use the situation cards to introduce the stories we had worked on during the review. The feedback from the stakeholders was excellent and they wanted to see this happening earlier in the process.
We now include making situation cards as a part of our prep sessions. We ask the team "How would you explain the value of this story?", putting them in the place of the customer. Sometimes a single card with a one-liner can be used, usually it takes a mini dialog to explain the value:
In the example above, the value stems from additional information to help the customer pin down issues in an area of logic which is hidden from them. By handling the error differently we can show which data item is the cause allowing our customer to find the problem in the logic that drives the output from simply asking the customer which data item are showing as errors.
You might notice that it took me a lot more words to describe this than we used in the situation cards but the level of detail is essentially the same.
This does not happen by accident - a series of conversations happened before we came up with the dialog in the situation cards. The words are not accidental, we arrived at them through discussion.
The cards provide context which helps but they also act as a constraint. At a very simple level, we have very little room! Further, when we are writing them, we are thinking about how we will read these during the review - they need to be short and direct otherwise you sound like a crazy person.
We can easily refactor conversations to convey the value in as few cards as possible by changing the dialog and removing cards.
We have a series of these to represent different situations - we usually use the man on mobile to covey the customer and the man at the workstation to represent the response from the team. We also have a man in a call centre to represent interactions with our customer's customer which has come in handy too.
These become Powerpoint presentations which we then use as initial storyboards in TFS - we simply attach them as storyboards which are stored on our local network. We create them in prep and then use them when we introduce the story to the team to kick start the understanding of 'Why' we are doing this story, which is what we originally intended these cards for.
Interested to know if anyone else uses these or something similar - feel free to leave feedback if you have :)
A while back I wrote about situation cards, which Dan Rushton and I came up to help connect developers with the reason why we were doing a particular story.
Our team works on systems where we are essentially passing messages between different services which is particularily difficult (read: boring) to demonstrate in the review. We all hate Powerpoint but looking at Fiddler or SoapUI is way more dull.
Dan's brainwave was to use the situation cards to introduce the stories we had worked on during the review. The feedback from the stakeholders was excellent and they wanted to see this happening earlier in the process.
We now include making situation cards as a part of our prep sessions. We ask the team "How would you explain the value of this story?", putting them in the place of the customer. Sometimes a single card with a one-liner can be used, usually it takes a mini dialog to explain the value:
In the example above, the value stems from additional information to help the customer pin down issues in an area of logic which is hidden from them. By handling the error differently we can show which data item is the cause allowing our customer to find the problem in the logic that drives the output from simply asking the customer which data item are showing as errors.
You might notice that it took me a lot more words to describe this than we used in the situation cards but the level of detail is essentially the same.
This does not happen by accident - a series of conversations happened before we came up with the dialog in the situation cards. The words are not accidental, we arrived at them through discussion.
The cards provide context which helps but they also act as a constraint. At a very simple level, we have very little room! Further, when we are writing them, we are thinking about how we will read these during the review - they need to be short and direct otherwise you sound like a crazy person.
We can easily refactor conversations to convey the value in as few cards as possible by changing the dialog and removing cards.
We have a series of these to represent different situations - we usually use the man on mobile to covey the customer and the man at the workstation to represent the response from the team. We also have a man in a call centre to represent interactions with our customer's customer which has come in handy too.
These become Powerpoint presentations which we then use as initial storyboards in TFS - we simply attach them as storyboards which are stored on our local network. We create them in prep and then use them when we introduce the story to the team to kick start the understanding of 'Why' we are doing this story, which is what we originally intended these cards for.
Interested to know if anyone else uses these or something similar - feel free to leave feedback if you have :)
Saturday, 9 May 2015
Reference Conversation
So, I have this problem. I find it very hard to start conversations. This has never really been a problem, I put it down to how I'm wired. Just recently, I have cause to think this is holding back my career progress so I have been working on understanding why and finding a solution or workaround.
First, I looked back and realised that fear had a big part to play. I have a tendancy to build up the conversation in my mind, running scenario after scenario in an attempt to control the conversation when I have it. In reflection this creates a negative feeling around the conversation so I shy away from starting it in the first place.
The build up also means that if I do start a conversation I am already apprehensive about it, which I am pretty sure the other person picks up on. Bad news all round really.
Now, I use 2 things to help break this cycle. The first is to think only about what the conversation is about and how I let the person know that. Seems simple really, I just work out how I open the conversation e.g if I am just checking in, I let the person know that in the first few seconds so they can relax.
Even if this is something that the other person might find difficult to talk about, I realise that I only need an opener - something is worrying me, this is why, now lets find a solution. I find this far less scary to think about.
This got me some of the way in that I could shut down a thought process by recognising it as daft from the outset. Once I had an opener, I could put it to one side as there is nothing left to think about.
Then I needed to find a way of countering the fear of starting the conversation, which felt like a learned response at this point.
Taking a cue from story planning, I came up with the idea of having a reference conversation. This gave me something I could refer to in the lead up to a conversation if I was feeling anxious about it. Similar to how we would use a reference story in planning, I would compare the type of conversation I was going to have with my reference conversation in help me recognise that it is really much less than I had built it up to be.
I use my reference conversation at any point that I am holding back from a conversation. If I am putting off booking it or starting it, I review my opener and remove my fear by comparing with my reference conversation.
For me, my reference conversation is one that I would not have the words for. It is one that I can think about and realise that all mine are trivial in comparison. As simple as this technique is, it has helped me move on and focus on having the conversation itself.
First, I looked back and realised that fear had a big part to play. I have a tendancy to build up the conversation in my mind, running scenario after scenario in an attempt to control the conversation when I have it. In reflection this creates a negative feeling around the conversation so I shy away from starting it in the first place.
The build up also means that if I do start a conversation I am already apprehensive about it, which I am pretty sure the other person picks up on. Bad news all round really.
Now, I use 2 things to help break this cycle. The first is to think only about what the conversation is about and how I let the person know that. Seems simple really, I just work out how I open the conversation e.g if I am just checking in, I let the person know that in the first few seconds so they can relax.
Even if this is something that the other person might find difficult to talk about, I realise that I only need an opener - something is worrying me, this is why, now lets find a solution. I find this far less scary to think about.
This got me some of the way in that I could shut down a thought process by recognising it as daft from the outset. Once I had an opener, I could put it to one side as there is nothing left to think about.
Then I needed to find a way of countering the fear of starting the conversation, which felt like a learned response at this point.
Taking a cue from story planning, I came up with the idea of having a reference conversation. This gave me something I could refer to in the lead up to a conversation if I was feeling anxious about it. Similar to how we would use a reference story in planning, I would compare the type of conversation I was going to have with my reference conversation in help me recognise that it is really much less than I had built it up to be.
I use my reference conversation at any point that I am holding back from a conversation. If I am putting off booking it or starting it, I review my opener and remove my fear by comparing with my reference conversation.
For me, my reference conversation is one that I would not have the words for. It is one that I can think about and realise that all mine are trivial in comparison. As simple as this technique is, it has helped me move on and focus on having the conversation itself.
Monday, 30 March 2015
Don't kill good behaviours
Just recently, an update to GMail totally threw me when it subtly changed the way it did something that I use many, many times a day. Although this change probably seemed trivial to the team at Google, it really has been a pain in the neck for me.
Changing the user experience for a popular piece of software is a difficult tightrope to walk. Too little change and you stifle progress whilst changing it too much risks loosing or annoying the user base.
So what caught me out? I get a notification of what has changed in my groups as a top level entry in my inbox. I found this useful since I could simply go to the group, see what has changed and read the items that were of interest at that moment. I return to my inbox and the notification would be removed - happy days.
The update has subtly changed this. Now, it seems to want me to read ALL of the items the notification is related to. If I don't then the notification remains at the top of my inbox until I have viewed everything it relates to or I simply dismiss the notification by swiping it to the left.
This is a tiny change in all reality, it could even be a mistake but I find this change in behaviour very annoying since it requires more action from me. I imagined how this might have been recorded:
Given 1 or more groups have been configured
When the user enters their inbox
Then a notifications is displayed for each group that has new mail
And the notifications are at the top of the inbox
And the notifications are ordered descending by the amount of new mail in the group
It has long been my contention that the words we use in scenarios are often a bit sloppy. In this case you could easily interpret this in 2 ways, which revolves around how we interpret a 'new' mail item. Is a mail item new if it has never been opened or when it has been seen via clicking on a notification?
By not really explaining what 'new' means we may have killed existing behaviour by simply misinterpreting what the original intention was. In this case the word 'new' is not clear as it is open to interpretation.
A good practice is to think how this could be interpreted in the future. Would this be exactly the same as now? If there is any doubt, then deliberating over the words used is a good use of time. The emphasis should be on the author to think about this rather than make the assumption that the reader will interpret correctly.
It is worth thinking about what you know and they don't - the conversation for my scenario may well have included what 'new' meant or it could have been well established by that specific team. Since it completely missing from the scenario, we will never know.
As the author we have access to the whole context of the conversation, so the odd word here or there does not appear to matter. If we take a step back and put ourselves in the place of our intended audience we can often see assumptions we have made and save them a lot of time and effort in the future.
Changing the user experience for a popular piece of software is a difficult tightrope to walk. Too little change and you stifle progress whilst changing it too much risks loosing or annoying the user base.
So what caught me out? I get a notification of what has changed in my groups as a top level entry in my inbox. I found this useful since I could simply go to the group, see what has changed and read the items that were of interest at that moment. I return to my inbox and the notification would be removed - happy days.
The update has subtly changed this. Now, it seems to want me to read ALL of the items the notification is related to. If I don't then the notification remains at the top of my inbox until I have viewed everything it relates to or I simply dismiss the notification by swiping it to the left.
This is a tiny change in all reality, it could even be a mistake but I find this change in behaviour very annoying since it requires more action from me. I imagined how this might have been recorded:
Given 1 or more groups have been configured
When the user enters their inbox
Then a notifications is displayed for each group that has new mail
And the notifications are at the top of the inbox
And the notifications are ordered descending by the amount of new mail in the group
It has long been my contention that the words we use in scenarios are often a bit sloppy. In this case you could easily interpret this in 2 ways, which revolves around how we interpret a 'new' mail item. Is a mail item new if it has never been opened or when it has been seen via clicking on a notification?
By not really explaining what 'new' means we may have killed existing behaviour by simply misinterpreting what the original intention was. In this case the word 'new' is not clear as it is open to interpretation.
A good practice is to think how this could be interpreted in the future. Would this be exactly the same as now? If there is any doubt, then deliberating over the words used is a good use of time. The emphasis should be on the author to think about this rather than make the assumption that the reader will interpret correctly.
It is worth thinking about what you know and they don't - the conversation for my scenario may well have included what 'new' meant or it could have been well established by that specific team. Since it completely missing from the scenario, we will never know.
As the author we have access to the whole context of the conversation, so the odd word here or there does not appear to matter. If we take a step back and put ourselves in the place of our intended audience we can often see assumptions we have made and save them a lot of time and effort in the future.
Monday, 18 August 2014
What do your customers know anyway?
Agile undoubtedly changes how we engage with our customer. The customer is centre stage to all our efforts.
For any organisation that has kept their customers at arms length, this is a scary prospect. It is highly likely that customers are more hostile than helpful in this scenario.
Involving customers in the development process is not an easy thing to achieve. I have even heard it said that it cannot be done for various reasons. This typically reduces customer involvement to demands made during sale or contract renewal - which are both driven by sales people.
At this point, we are clearly in panic mode as our number one concern is to protect revenue. This is typically where good product design is the last consideration and the product is polluted with some pretty badly designed features.
This is not the customer engagement we need. If it were left to the customer they would have the 'Do It' button that basically performs their specific function. The customer does not know best when it comes to product design - you do. That is what you bring to the party.
Just because your existing customers will put up with a naff experience don't forget that new customers might not be so forgiving. A poor user experience will ultimately affect your ability to attract new customers - they have zero investment in you and will simply move on.
Getting involvement with your customer as a standard part of your development process will radically shake up how you work as a business. Listening to your customer is where the agility that you are looking for will come from.
Our engagement with the customer should focus on one thing - what is the problem we are trying to solve for them. By concentrating on the high level behaviours they are looking for, we get to solve that problem for them. That uses our formidable skills as software developers to their full extent.
The customer does not know what they want. They know what problem they need solving. Once we know that, we can create software that is truly useful.
Just like you would not trust anyone to pass on a really important message, getting the customer to explain the problem to the people who will do the work is the holy grail. The more people you have in the way, the less likely we will solve the customers problem. Diluting their message through a chain of dialogues that are each biased is a waste of everyone's time.
If you can do all this, then you only need a team who can guide conversations with your customer to fully appreciate what problem the customer wants to solve.... and we all have one of those, right?
For any organisation that has kept their customers at arms length, this is a scary prospect. It is highly likely that customers are more hostile than helpful in this scenario.
Involving customers in the development process is not an easy thing to achieve. I have even heard it said that it cannot be done for various reasons. This typically reduces customer involvement to demands made during sale or contract renewal - which are both driven by sales people.
At this point, we are clearly in panic mode as our number one concern is to protect revenue. This is typically where good product design is the last consideration and the product is polluted with some pretty badly designed features.
This is not the customer engagement we need. If it were left to the customer they would have the 'Do It' button that basically performs their specific function. The customer does not know best when it comes to product design - you do. That is what you bring to the party.
Just because your existing customers will put up with a naff experience don't forget that new customers might not be so forgiving. A poor user experience will ultimately affect your ability to attract new customers - they have zero investment in you and will simply move on.
Getting involvement with your customer as a standard part of your development process will radically shake up how you work as a business. Listening to your customer is where the agility that you are looking for will come from.
Our engagement with the customer should focus on one thing - what is the problem we are trying to solve for them. By concentrating on the high level behaviours they are looking for, we get to solve that problem for them. That uses our formidable skills as software developers to their full extent.
The customer does not know what they want. They know what problem they need solving. Once we know that, we can create software that is truly useful.
Just like you would not trust anyone to pass on a really important message, getting the customer to explain the problem to the people who will do the work is the holy grail. The more people you have in the way, the less likely we will solve the customers problem. Diluting their message through a chain of dialogues that are each biased is a waste of everyone's time.
If you can do all this, then you only need a team who can guide conversations with your customer to fully appreciate what problem the customer wants to solve.... and we all have one of those, right?
Tuesday, 12 August 2014
What does that mean?!!!
I hate three letter acronymns.
I think they represent a past that we have hopefully left far behind. They obscure conversation and serve only to make people think they sound intelligent. Unless you are a part of the club, their meaning can often be shrouded in mystery.
Over the years I have witnessed a massive change in the type of person who has ended up being involved in IT. I can still remember when it was unthinkable that anyone without a degree in comp sci could write software.
As the Internet gave everyone a new platform to write software for, the tools became more approachable and now everyone is invited to the party. This has been the single greatest change in IT and has brought about a new generation of conversable developers.
I will credit Dan Rushton with this phrase, it's a good one. He also bagged the domain where you can check out his ramblings.
I like to think that we can solve all the technical problems that are thrown at us. The bit we are missing is understanding what it is we are actually developing. It should be easy, right?
The idea that a specification can detail everything is frankly insane. If it could, it would likely be unreadable. The future is through the oldest of all forms of communication - conversation.
Conversations are the corner stone of agile software development. Nothing allows a team to convey ideas and gain understanding faster than conversation. If there is a problem, you can guarantee that a conversation will enable people to get to the bottom of it. If it's important, you pick up the phone and talk about it. Conversation is a natural instinct.
Although business value is pinned as what we are trying to uncover, I cannot see how this happens without good communication. Good conversations enable us to uncover value at all levels of the organisation. It is the unseen foundation for all agile principles.
As a developer, communication transcends all other issues. It is key to the success of my code and the organisation I work for. So, I write about my adventures whenever I can. Enjoy :)
I think they represent a past that we have hopefully left far behind. They obscure conversation and serve only to make people think they sound intelligent. Unless you are a part of the club, their meaning can often be shrouded in mystery.
Over the years I have witnessed a massive change in the type of person who has ended up being involved in IT. I can still remember when it was unthinkable that anyone without a degree in comp sci could write software.
As the Internet gave everyone a new platform to write software for, the tools became more approachable and now everyone is invited to the party. This has been the single greatest change in IT and has brought about a new generation of conversable developers.
I will credit Dan Rushton with this phrase, it's a good one. He also bagged the domain where you can check out his ramblings.
I like to think that we can solve all the technical problems that are thrown at us. The bit we are missing is understanding what it is we are actually developing. It should be easy, right?
The idea that a specification can detail everything is frankly insane. If it could, it would likely be unreadable. The future is through the oldest of all forms of communication - conversation.
Conversations are the corner stone of agile software development. Nothing allows a team to convey ideas and gain understanding faster than conversation. If there is a problem, you can guarantee that a conversation will enable people to get to the bottom of it. If it's important, you pick up the phone and talk about it. Conversation is a natural instinct.
Although business value is pinned as what we are trying to uncover, I cannot see how this happens without good communication. Good conversations enable us to uncover value at all levels of the organisation. It is the unseen foundation for all agile principles.
As a developer, communication transcends all other issues. It is key to the success of my code and the organisation I work for. So, I write about my adventures whenever I can. Enjoy :)
Subscribe to:
Posts (Atom)