I read this great blog by slim this past week and commented saying 'Developers need to be empathic as they deal with lot of different teams in their daily work schedules and hence have to deal with lot of different people'. I also said that I have felt that there are instances wherein much of delay is caused by misunderstanding between people. In case you are wondering why developers need to talk to so many people let me give you an example:
'I (developer) write a code that sends external e-mails and I find the ports are not configured. I have to contact the basis administrator to get that done as in a typical scenario I would not have authorization to do that. I would work based on a functional specification given to me. I would like to know how does the transaction work and business case it solves, before I would do any custom coding. For that I would contact the functional consultant. Let's say while I analyze the specification I find that there are unclear requirements, I would have to contact the requirements gathering team (could be my customer).'
Slim wanted to know kind of delays happening due to misunderstanding between teams. Even before I proceed to answer his question I would like you to imagine a workplace like this: 'People understand you the way you want them to. Your words are perceived the way they were said. People don't try to draw conclusions based only on the words spoken but also by what was not spoken. They try to understand not only what is being said but also the background information which lead to the words that were spoken'. Well, when I imagined this kind of workplace I had a feeling like 'Wow'. There would be no conflicts if everyone becomes like this. Now when I say this, I don't mean that no one of this kind exists now, certainly there are people with such admirable characteristics but I have come across very few of them. At the same time, when I expect people around to be part of that ideal workplace, I would expect myself to scale up and improve my understanding/listening skills too.
Back to answering Slim's question, there is one experience that comes rushing to my mind. I was new to a team and obviously unaware of mindset of people and work culture. A fresh piece of development was handed over to me with a Functional specification (FS). As I mentioned earlier, after going through the FS, I went to the functional consultant to understand the transaction and to verify the understanding of object to be developed. She [I am addressing people involved as 'she' and does not actually mean that the person was a she] explained me well but she said that the 'Smartform' [object to be developed] would be triggered at 'Delivery level'. I came back and reread the FS and was pretty sure that 'Smartform' had to be triggered at 'Handling Unit' (HU) level and the 'Output type' had to be configured at HU level and not at the header level. I made an attempt to make her understand. She refused to accept that and she gave numerous examples of objects developed previously where print was at the header level. She was so confident of her assumption that she might have overlooked what was not-so-explicitly mentioned in the specification. This is clearly an example of people resistant to change and assume that anything new would be done just the same way, it has been done in past.
I was in a strange situation as certainly the 'Importing parameters' of the code depended on the level at which the 'Output type' was configured. With the deadline within which the object had to be completed, I could not spare much time in convincing her 'What she needed to do' and hence rather decided to complete the coding with the understanding I had. My role was to code the object and hand it over to her for the final testing.[Was I being selfish, but how could anyone help a person who is resistant to change?]
At the same time I kept discussing the issue with some other consultants who might have developed something similar and kept investigating as to how 'Output type' could be configured at HU level. Anything when started newly takes more time and seems more trickier. Finally, days moved and the coding was complete, needless to mention that the delivery date of object too was very near. With my numerous attempts to convince her, she actually at a pretty later stage made an attempt to contact another person from the concerned team to verify if the print had to be triggered at HU level and how could output type be configured at HU level. Finally, things were sort out and she accepted that it was at HU level.
Test plan had to be prepared and the object had to be thoroughly tested before it was delivered. After she understood, she did the configuration and then I had to finish the developer testing. Did it cause a delay? My answer would be a certain Yes. I had to work on a weekend to meet the delivery date. Apart from that, there were unnecessary last minute communication sent to different teams to get the configuration done as not all authorizations were given to her. There were high chances of missing the due date, had those last moment communication not acknowledged urgently. So, certainly it was not smooth. So if I give this whole episode a summarized look it could be like:
The specification was not documented very explicitly w.r.t level of output. The concerned team might have assumed it to be 'implicitly' clear.
Functional person 'assumed' it to be what she had been doing previously.
Poor developer could not easily convince her functional of what was right.
Now let me introduce the element I am talking about, 'Empathy'. It was certainly lost in this whole episode. Who had to be empathic here? The functional consultant, the specification writer or the developer or everyone of them?
Let me concentrate on the developer. Had developer tried finding out as to why the functional was so confident of her understanding, developer would have pulled out specification of those objects and tried making a comparison among them and could have found differences to prove her point. There was a high chance that specification did not give developer enough clue, she would have tried to respect the fact that functional was resistant to change and would have approached her with a more polite or well researched opinion helping her with ways of configuration rather than thinking 'It's her job'. Developer could have respected the fact that functional was highly experienced person and hence was deriving conclusion based on past experiences and thought of an appropriate approach to correct her.
This experience actually taught me a lot and I have made it a point to get things straight, right at the first place rather than at later stage of development.
Slim has also commented saying, often people think that they understood what the word used by another person means. Let me relate to another experience. When a specification comes to a developer's desk to be verified and estimated, the explicitly unclear cases are easily identified and asked but how about some of the tricky ones which in most of the cases get assumed by the developer and causes problem at a later stage. Most of these arise because the same words are perceived in different ways by different peoople. One such occassion was when one of the developers was going on leave and I had to take over her work. I read the specification and concentrated on what needed to be done by that interface. [object to be developed] I found a statement saying 'Some update would be done by this "transaction"'. The interface was handling couple of big scenarios and the update highlighted above might not have been much emphasized or highlighted in previous discussions. I asked her about that and I could clearly understand that it was assumed by her that it would be done as part of some other process and not part of the same interface being developed, just because in specification it was written ''transaction" and not very explicitly that the update would be part of the same interface. I later had a discussion with the concerned team and found that they used the word "transaction" for any scenario handled via that interface and hence did not necessarily feel the need to highlight that in the specification. Did this cause a delay? Certainly yes as that called for additional calls and time before it was estimated.
I could give more examples of confusions arising due to misunderstanding but I think the point is clear. I can't expect eveyone around me to be empathic but I am very sure if I keep making a conscious effort to be empathic in dealings with people, that would make my life easier and peaceful.
'I (developer) write a code that sends external e-mails and I find the ports are not configured. I have to contact the basis administrator to get that done as in a typical scenario I would not have authorization to do that. I would work based on a functional specification given to me. I would like to know how does the transaction work and business case it solves, before I would do any custom coding. For that I would contact the functional consultant. Let's say while I analyze the specification I find that there are unclear requirements, I would have to contact the requirements gathering team (could be my customer).'
Slim wanted to know kind of delays happening due to misunderstanding between teams. Even before I proceed to answer his question I would like you to imagine a workplace like this: 'People understand you the way you want them to. Your words are perceived the way they were said. People don't try to draw conclusions based only on the words spoken but also by what was not spoken. They try to understand not only what is being said but also the background information which lead to the words that were spoken'. Well, when I imagined this kind of workplace I had a feeling like 'Wow'. There would be no conflicts if everyone becomes like this. Now when I say this, I don't mean that no one of this kind exists now, certainly there are people with such admirable characteristics but I have come across very few of them. At the same time, when I expect people around to be part of that ideal workplace, I would expect myself to scale up and improve my understanding/listening skills too.
Back to answering Slim's question, there is one experience that comes rushing to my mind. I was new to a team and obviously unaware of mindset of people and work culture. A fresh piece of development was handed over to me with a Functional specification (FS). As I mentioned earlier, after going through the FS, I went to the functional consultant to understand the transaction and to verify the understanding of object to be developed. She [I am addressing people involved as 'she' and does not actually mean that the person was a she] explained me well but she said that the 'Smartform' [object to be developed] would be triggered at 'Delivery level'. I came back and reread the FS and was pretty sure that 'Smartform' had to be triggered at 'Handling Unit' (HU) level and the 'Output type' had to be configured at HU level and not at the header level. I made an attempt to make her understand. She refused to accept that and she gave numerous examples of objects developed previously where print was at the header level. She was so confident of her assumption that she might have overlooked what was not-so-explicitly mentioned in the specification. This is clearly an example of people resistant to change and assume that anything new would be done just the same way, it has been done in past.
I was in a strange situation as certainly the 'Importing parameters' of the code depended on the level at which the 'Output type' was configured. With the deadline within which the object had to be completed, I could not spare much time in convincing her 'What she needed to do' and hence rather decided to complete the coding with the understanding I had. My role was to code the object and hand it over to her for the final testing.[Was I being selfish, but how could anyone help a person who is resistant to change?]
At the same time I kept discussing the issue with some other consultants who might have developed something similar and kept investigating as to how 'Output type' could be configured at HU level. Anything when started newly takes more time and seems more trickier. Finally, days moved and the coding was complete, needless to mention that the delivery date of object too was very near. With my numerous attempts to convince her, she actually at a pretty later stage made an attempt to contact another person from the concerned team to verify if the print had to be triggered at HU level and how could output type be configured at HU level. Finally, things were sort out and she accepted that it was at HU level.
Test plan had to be prepared and the object had to be thoroughly tested before it was delivered. After she understood, she did the configuration and then I had to finish the developer testing. Did it cause a delay? My answer would be a certain Yes. I had to work on a weekend to meet the delivery date. Apart from that, there were unnecessary last minute communication sent to different teams to get the configuration done as not all authorizations were given to her. There were high chances of missing the due date, had those last moment communication not acknowledged urgently. So, certainly it was not smooth. So if I give this whole episode a summarized look it could be like:
The specification was not documented very explicitly w.r.t level of output. The concerned team might have assumed it to be 'implicitly' clear.
Functional person 'assumed' it to be what she had been doing previously.
Poor developer could not easily convince her functional of what was right.
Now let me introduce the element I am talking about, 'Empathy'. It was certainly lost in this whole episode. Who had to be empathic here? The functional consultant, the specification writer or the developer or everyone of them?
Let me concentrate on the developer. Had developer tried finding out as to why the functional was so confident of her understanding, developer would have pulled out specification of those objects and tried making a comparison among them and could have found differences to prove her point. There was a high chance that specification did not give developer enough clue, she would have tried to respect the fact that functional was resistant to change and would have approached her with a more polite or well researched opinion helping her with ways of configuration rather than thinking 'It's her job'. Developer could have respected the fact that functional was highly experienced person and hence was deriving conclusion based on past experiences and thought of an appropriate approach to correct her.
This experience actually taught me a lot and I have made it a point to get things straight, right at the first place rather than at later stage of development.
Slim has also commented saying, often people think that they understood what the word used by another person means. Let me relate to another experience. When a specification comes to a developer's desk to be verified and estimated, the explicitly unclear cases are easily identified and asked but how about some of the tricky ones which in most of the cases get assumed by the developer and causes problem at a later stage. Most of these arise because the same words are perceived in different ways by different peoople. One such occassion was when one of the developers was going on leave and I had to take over her work. I read the specification and concentrated on what needed to be done by that interface. [object to be developed] I found a statement saying 'Some update would be done by this "transaction"'. The interface was handling couple of big scenarios and the update highlighted above might not have been much emphasized or highlighted in previous discussions. I asked her about that and I could clearly understand that it was assumed by her that it would be done as part of some other process and not part of the same interface being developed, just because in specification it was written ''transaction" and not very explicitly that the update would be part of the same interface. I later had a discussion with the concerned team and found that they used the word "transaction" for any scenario handled via that interface and hence did not necessarily feel the need to highlight that in the specification. Did this cause a delay? Certainly yes as that called for additional calls and time before it was estimated.
I could give more examples of confusions arising due to misunderstanding but I think the point is clear. I can't expect eveyone around me to be empathic but I am very sure if I keep making a conscious effort to be empathic in dealings with people, that would make my life easier and peaceful.
No comments:
Post a Comment