Business people and Engineers .. are we like cat and dog?
In the past it look like it could be like that. We were living in separate worlds, and to be sincere we did not care much to approach the other world from our side, and either from theirs. I do not need to explain why was that, but briefly for the lucky ones who lived that period for a short time or did not live those times at all we can simply say that business people needed to deliver something quick, did not have much time to share their view. Developers just wanted to receive a document with the information we need to do something and do that thing on time, and that thing on time could be a project that in most of the cases was estimated from someone who did not have enough information to know how long it will take. Also we did not have enough knowledge and information about why something was needed, we just knew what they need, not why.
What have changed now? In this new world of agile development we are working together, and in most of the cases in the same space, close to each other (as it should be). But working together is not the key element. The factor that comes now into place is the direct communication, but communication is nothing if there is no trust from both parts. I am not going to explain today the agile methodology vs waterfall. I am going to explain why is that possible.
We can like it more or less, but in majority of business, they need to have a plan, they manage important budget and they cannot risk that budget. Why they can change the way they are working and work directly with us, just knowing how difficult are things to do in the next weeks? They can do that because they trust their team. And that trust is based in many things, but today I will focus in what for me are two key points. Good estimates and transparency in the communication.
What is a good estimate? We need to change our obsolete view that a good estimate is the fastest one possible. The first thing that we want with our estimates is to reflect our view of our how things should be done. I am not talking about overcomplicating what needs to be done, or providing a solution that will do more things that are required. I am talking to be clear of what we think it will involve. If we think something is complex we should say so. Engineers should not be scared of saying that something will take a long time even if the product owner do not like it. In the same way we need to say that something can be done really quick and not think that it will cause more pressure on other things cause they will take longer. Estimates is a key element for our business people to have the level of knowledge to prioritize things properly.
We have been saying in the recent years that estimating something with years in mind and a humongous scope is not the way we should build software, but we need to provide them with something they can trust. They need to trust us when we say something is more complex or that something is really easy. We need to do our best so they can trust us. We cannot do things like saying something is complex just cause we do not want to do it, or cause we do not know how to do it and we want to avoid that. That sounds really important right? but how do we achieve that level of trust? It is simple, transparency.
As I was mentioning before, we cannot be obscure or hide things. If we do not know how to do something we must say it. If we think we should not do something we need to highlight that. We need to build the trust with the business. If we made a mistake on something we need to say that we did a mistake, not shut our mouths and fix later. It is really important to show transparency with our problems, cause it is really easy to be transparent with our success, but if they ask for example why the stories are not updated by us on the tool we are using (say pivotal tracker or Jira) and we say that we forgot to do it instead of inventing that we were too busy or the tool was not working we will build trust on us, and that trust we build with those kind of things will be used later when we want them to trust us challenging their view on something. It is not unlikely that we need some times to educate business in the agile methodologies, so if we want them to trust us when we say something needs to be done in a different way, or that we cannot estimate with months in advance, we need them to trust us, and being transparent is how we build that trust.
If they do not trust us there is no point of estimating stories, giving feedback or sharing your thoughts on a meeting cause they are not going to believe in what we say, and the confidence will collapse like a house of cards. In the other hand if we have build a solid trust they will share more things with us, they will come to ask our opinion to take decisions. Imagine that you have your garage where you take your car, You want them to be transparent with you. If you have a break down you want them to be realistic with you, and if something is expensive you would like to know in advance , cause you do not want them to tell you that the repair will be cheap so you don't go to another garage just to discover later on that will be expensive when you cannot move your car from there. Imagine also that you are doing a extension on your house, and your contractor says it will take X days. The contractor realizes the first day that the terrain is difficult and it will take more time to do it, of course you would like to know that the same day, not wait till later to know that there is a problem that can have some costs , or even you can decide to postpone that cause the week after you will not be at home. You want transparency even if the communication is about something you do not want to hear.
I can put more examples but you can start to see a pattern. Do not hide things, show your opinion and do not be scared to challenge a decision if you do not agree. If you make a mistake do not be scared to say so. If they do not see that as a positive thing is that the environment is not a good environment for you. The mistake is already there, you are only making it worst hiding it. If something is going to take a big effort to be done, do not say it will be easy to look like a better software engineer cause you are being the opposite, in summary, be transparent my friend, they will thank that, as a community we will grow, and you will be a better person in general.
What is a good estimate? We need to change our obsolete view that a good estimate is the fastest one possible. The first thing that we want with our estimates is to reflect our view of our how things should be done. I am not talking about overcomplicating what needs to be done, or providing a solution that will do more things that are required. I am talking to be clear of what we think it will involve. If we think something is complex we should say so. Engineers should not be scared of saying that something will take a long time even if the product owner do not like it. In the same way we need to say that something can be done really quick and not think that it will cause more pressure on other things cause they will take longer. Estimates is a key element for our business people to have the level of knowledge to prioritize things properly.
We have been saying in the recent years that estimating something with years in mind and a humongous scope is not the way we should build software, but we need to provide them with something they can trust. They need to trust us when we say something is more complex or that something is really easy. We need to do our best so they can trust us. We cannot do things like saying something is complex just cause we do not want to do it, or cause we do not know how to do it and we want to avoid that. That sounds really important right? but how do we achieve that level of trust? It is simple, transparency.
As I was mentioning before, we cannot be obscure or hide things. If we do not know how to do something we must say it. If we think we should not do something we need to highlight that. We need to build the trust with the business. If we made a mistake on something we need to say that we did a mistake, not shut our mouths and fix later. It is really important to show transparency with our problems, cause it is really easy to be transparent with our success, but if they ask for example why the stories are not updated by us on the tool we are using (say pivotal tracker or Jira) and we say that we forgot to do it instead of inventing that we were too busy or the tool was not working we will build trust on us, and that trust we build with those kind of things will be used later when we want them to trust us challenging their view on something. It is not unlikely that we need some times to educate business in the agile methodologies, so if we want them to trust us when we say something needs to be done in a different way, or that we cannot estimate with months in advance, we need them to trust us, and being transparent is how we build that trust.
If they do not trust us there is no point of estimating stories, giving feedback or sharing your thoughts on a meeting cause they are not going to believe in what we say, and the confidence will collapse like a house of cards. In the other hand if we have build a solid trust they will share more things with us, they will come to ask our opinion to take decisions. Imagine that you have your garage where you take your car, You want them to be transparent with you. If you have a break down you want them to be realistic with you, and if something is expensive you would like to know in advance , cause you do not want them to tell you that the repair will be cheap so you don't go to another garage just to discover later on that will be expensive when you cannot move your car from there. Imagine also that you are doing a extension on your house, and your contractor says it will take X days. The contractor realizes the first day that the terrain is difficult and it will take more time to do it, of course you would like to know that the same day, not wait till later to know that there is a problem that can have some costs , or even you can decide to postpone that cause the week after you will not be at home. You want transparency even if the communication is about something you do not want to hear.
I can put more examples but you can start to see a pattern. Do not hide things, show your opinion and do not be scared to challenge a decision if you do not agree. If you make a mistake do not be scared to say so. If they do not see that as a positive thing is that the environment is not a good environment for you. The mistake is already there, you are only making it worst hiding it. If something is going to take a big effort to be done, do not say it will be easy to look like a better software engineer cause you are being the opposite, in summary, be transparent my friend, they will thank that, as a community we will grow, and you will be a better person in general.
Comments
Post a Comment