I don't think that the following statement should be surprising to anyone but:
EVERYONE WANTS TO FEEL LISTENED TO
The reason, I think, is that everyone wants to feel like they have equal shot, equal footing to have their needs met. It isn't possible to have your needs met when the other people involved in a conversation are not interested in listening to what you have to say. Beyond that it is increasingly difficult to have your needs met if you are not able to articulate what you actually need.
Sounds easy right - you just have to be able to say what it is that you need... You just have to put it out there and allow it to be heard and then your needs might potentially be met, so what makes it so amazingly fucking hard to ACTUALLY do?
Social interaction, moral codes and judgements
My theory is this - over time we are taught as kids by our parents, and elders about things that we can't say or can't do. Kids are negatively reinforced by their elders about how they use their words and are told that the choices that they make can hurt people. As kids we are taught to take care with other peoples feelings and often the ways in which we are taught to do this are statements like:
"...don't say that..."
"...you can't say that to people, you'll hurt their feelings..."
etc.
But we are rarely positively reinforced for using words and other statements to state what we feel and need while also not hurting the people we are interacting with. Think of it like sharing that toy that there was only one of when you were little. Someone else was using it at the time you wanted to also play with it. Now you have choices, you can walk over and take it, you can ask to play with it, etc. However when young we often don't consider beyond ourselves and we don't often have a role model for interacting. We learn as we go about what gets us in trouble and what doesn't including some of the sneaky "I get my way without getting in trouble" actions that can be taken.
Speculate for a minute though - what IF what we modeled for our kids and others was as truthful as kids tend to be, telling things like they see it with few filters but the words were chosen to be clear and concise and non threatening.
Marshal Rosenberg lays out a discussion and conversation model called nonviolent communication. Where he describes the ideas of stating clearly what you observe about a situation, describing how it makes you feel and as a result what needs you have around it. Seems straight forward but is actually amazingly difficult to do. Think about the last argument you had with someone, do you think that you would have been able to be level headed enough to not escalate the conversation with angry commentary but rather stop and say what you observe and what you feel? Ya, I didn't think so - I know I certainly don't - but I am trying.
Imagine if you will
Now - lets go back to the kids. I mentioned them earlier because I wanted to speculate what our adult interactions would be if we were able to example for our children when they were young a method like nonviolent communication. Kids are unfiltered and wonderfully blunt, they say what they see and their interpretation on it. Kids are not afraid to tell us how they feel, but somewhere along the way as we grow up the interactions we have and the things we are told by our elders drum out of us the ability to just say how we feel, and what we need. I love to speculate how much better a place the world would be if we could all get our needs met. I for sure am looking to get my needs met, and using nonviolent communication where I can to help me articulate them.
Monday, April 25, 2016
Friday, April 8, 2016
Trust - Ebbs and Flows
I find myself thinking about trust a great deal lately - it is another of those life things that seems to be rising to the surface enough that I should likely pay attention to it. A friend of mine in fact just said
"Trust once lost, is hard to regain."
Which is why I am now sitting here typing out this post.
From a very young age I found that I was able to read people fairly well. I was certainly not perfect at it as 'reading' someone is a bit of an inexact science but I found I was fairly good at determining quickly if I was bound to trust the person standing in front of me long term. Sometimes body language would say one thing and their words something different which would leave me feeling like I couldn't trust them. Overall I was often left wondering about interactions with individuals long after they had occurred trying to understand why the conversation broke out the way it did, why certain things happened and sometimes why certain things didn't happen at all. The interesting thing for me is that while my instincts may tell me not to trust someone I often trusted them anyway. Glutton for punishment I suppose.
WHY
I have wondered for myself why it is the case that I always seem to start from a default of trusting someone implicitly even when my instincts may tell me otherwise. It seems to be my nature to start a relationship with giving it my all. I want to trust, I want to know I am trusted, I want to exchange ideas and know that ideas can easily be exchanged with me. To put it simply, I pour myself into the relationships that I have because I think it is important to be fully engaged and fully involved. This makes having lots of incidental relationships super annoying, because I am not much for incidental. I want people in my life that are willing to connect that way. I want people in my life that allow me to pour a bucket full of my trust into the relationship, instantly. In the reverse I hope for the same from them, but I can do no more than hope as their trust isn't in my control...
Trust Exchange
I had a conversation with my friend Maurice Gaston at one point about trust and trust as a flowing exchange between people. The idea that trust isn't something all on or all off at all points, that it more flows like a river or comes and goes like a tide. The discussion framed up some thoughts around why some discussions I have feel more relaxed and others feel more strained, as if some conversations require a great deal of concentration to get right and others go right naturally on their own. I think it does boil down to the trust that we have and the mental model we have built up of the person(s) we are talking to.
Chris Argyris, an American business theorist, wrote about these mental models we create for our interactions. He outlined that people over time generate a 'theory' of the person that they are interacting with and how that person will or won't react in situations that they are placed in. When we interact with someone else we try to reconcile the actions that individual takes with the theory we have in our mind for that person, if they match, we reinforce the theory being the 'right' theory for that individual. When the theory and the actions that are presented mismatch we get suddenly lost trying to reconcile and come up with a new theory for them that fits the new data and situation. He called out that this all occurs very quickly - likely at a level we don't realize we are doing it. Stay with me... bringing it back around.
I think the reinforcement or the discontinuity of conversations likely line up with the level of trust and the ease with which the conversations seem to occur. That trust ebb and flow maps directly on-top of Chris' commentary. When my theory of an individual is reinforced by that person's actions, I feel more likely to trust and less like something odd is going to happen. When my theory is constantly being challenged, I feel less likely to trust and the conversation and exchange is harder.
I am sure that there is MORE (much more) to this. This post just represents a part of my consideration of trust.
Trust for me means - Getting Hurt
I am a very trusting person, if you ask me a question I will give you the answer, personal or not. Comes with the ADHD and lack of mental filters for what I should or should not say. I have gotten better over the years about picking my words more carefully so that I don't come across as so blunt or surprising, but I haven't stopped trusting people by default. I want it to be the case that people I am involved with trust me and understand that as a friend of mine, that I would likely move heaven and earth to help them, often times at my own detriment. This has made me try to limit the number of close friends I have - but the reality is that most people I see often enough I would consider my friends and they all get equal treatment that way. Move the stars if it would help. It is painful though because often enough that trust only flows in one direction, and for me its hard to turn off allowing me to get hurt or used more than once. That too has changed over the years, but I am likely still not as careful as my experiences would dictate about how much trust I provide people (including those that have hurt me more than once).
Trust can also hurt when I don't pick my words more carefully and a raw feeling escapes to the surface and out my mouth. It often comes as a surprise to the individual involved.
Why is trust so hard to get back
I think that this is only human, we tend to focus on losses more than gains leaving people less able to see how much was there in the first place. It means that we feel so much more keenly the lost trust, no matter how small, rather than all the trust that has been exchanged over time. Changing that around is difficult because people are not wired that way. Consider your avg. IT help desk and all the vitriol they get tossed their way, no one ever calls them to say "Hey, great job your doing". We unfortunately focus on the negatives. Feels odd to me, because I get burned and go running back in, I wonder what does happen when you let go.
"Trust once lost, is hard to regain."
Which is why I am now sitting here typing out this post.
From a very young age I found that I was able to read people fairly well. I was certainly not perfect at it as 'reading' someone is a bit of an inexact science but I found I was fairly good at determining quickly if I was bound to trust the person standing in front of me long term. Sometimes body language would say one thing and their words something different which would leave me feeling like I couldn't trust them. Overall I was often left wondering about interactions with individuals long after they had occurred trying to understand why the conversation broke out the way it did, why certain things happened and sometimes why certain things didn't happen at all. The interesting thing for me is that while my instincts may tell me not to trust someone I often trusted them anyway. Glutton for punishment I suppose.
WHY
I have wondered for myself why it is the case that I always seem to start from a default of trusting someone implicitly even when my instincts may tell me otherwise. It seems to be my nature to start a relationship with giving it my all. I want to trust, I want to know I am trusted, I want to exchange ideas and know that ideas can easily be exchanged with me. To put it simply, I pour myself into the relationships that I have because I think it is important to be fully engaged and fully involved. This makes having lots of incidental relationships super annoying, because I am not much for incidental. I want people in my life that are willing to connect that way. I want people in my life that allow me to pour a bucket full of my trust into the relationship, instantly. In the reverse I hope for the same from them, but I can do no more than hope as their trust isn't in my control...
Trust Exchange
I had a conversation with my friend Maurice Gaston at one point about trust and trust as a flowing exchange between people. The idea that trust isn't something all on or all off at all points, that it more flows like a river or comes and goes like a tide. The discussion framed up some thoughts around why some discussions I have feel more relaxed and others feel more strained, as if some conversations require a great deal of concentration to get right and others go right naturally on their own. I think it does boil down to the trust that we have and the mental model we have built up of the person(s) we are talking to.
Chris Argyris, an American business theorist, wrote about these mental models we create for our interactions. He outlined that people over time generate a 'theory' of the person that they are interacting with and how that person will or won't react in situations that they are placed in. When we interact with someone else we try to reconcile the actions that individual takes with the theory we have in our mind for that person, if they match, we reinforce the theory being the 'right' theory for that individual. When the theory and the actions that are presented mismatch we get suddenly lost trying to reconcile and come up with a new theory for them that fits the new data and situation. He called out that this all occurs very quickly - likely at a level we don't realize we are doing it. Stay with me... bringing it back around.
I think the reinforcement or the discontinuity of conversations likely line up with the level of trust and the ease with which the conversations seem to occur. That trust ebb and flow maps directly on-top of Chris' commentary. When my theory of an individual is reinforced by that person's actions, I feel more likely to trust and less like something odd is going to happen. When my theory is constantly being challenged, I feel less likely to trust and the conversation and exchange is harder.
I am sure that there is MORE (much more) to this. This post just represents a part of my consideration of trust.
Trust for me means - Getting Hurt
I am a very trusting person, if you ask me a question I will give you the answer, personal or not. Comes with the ADHD and lack of mental filters for what I should or should not say. I have gotten better over the years about picking my words more carefully so that I don't come across as so blunt or surprising, but I haven't stopped trusting people by default. I want it to be the case that people I am involved with trust me and understand that as a friend of mine, that I would likely move heaven and earth to help them, often times at my own detriment. This has made me try to limit the number of close friends I have - but the reality is that most people I see often enough I would consider my friends and they all get equal treatment that way. Move the stars if it would help. It is painful though because often enough that trust only flows in one direction, and for me its hard to turn off allowing me to get hurt or used more than once. That too has changed over the years, but I am likely still not as careful as my experiences would dictate about how much trust I provide people (including those that have hurt me more than once).
Trust can also hurt when I don't pick my words more carefully and a raw feeling escapes to the surface and out my mouth. It often comes as a surprise to the individual involved.
Why is trust so hard to get back
I think that this is only human, we tend to focus on losses more than gains leaving people less able to see how much was there in the first place. It means that we feel so much more keenly the lost trust, no matter how small, rather than all the trust that has been exchanged over time. Changing that around is difficult because people are not wired that way. Consider your avg. IT help desk and all the vitriol they get tossed their way, no one ever calls them to say "Hey, great job your doing". We unfortunately focus on the negatives. Feels odd to me, because I get burned and go running back in, I wonder what does happen when you let go.
Tuesday, April 5, 2016
Enterprise source (Open source for the enterprise)
What is enterprise source
Enterprise source for me describes a way in which I can manage software development that involves more than just 'my' team in order to accomplish a given task within my organization. In a host of ways enterprise source mirrors how an individual contributor would work with any open source software project - building up a change that adds a missing feature or fixing an existing bug and then submitting that to the project. What I build/submit might be something of value to everyone, or it might only be of value to me specifically but it is up to the project as to decide if what I submit is worth while to merge and make available as part of their project. The same process is used in enterprise source with some interesting hitches that are worth noting which we cover in slightly more depth later.
Why would you want to do enterprise source
So - in the very small scale of the word organization you likely wouldn't have need to do this at all. If your a company of 10's of developers there may not actually be any occasion to do this at all. Enterprise source however makes a great deal of sense when you are a corporation of significant size, multiples teams doing work across the organization. In the the large corporation sense what you would like to have is teams that are decoupled from one another in a way that allows them all to move to deployment and delivery independent from one another. Different teams will have different product drivers and potentially be working on completely different lines of business that require them to operate independently. At deeper levels in the technical stack however the teams may all have to interface with a back office, or an API set.
In the typical organization the team in control of the API set will have their deployment schedule and will take stories and other content for delivery from teams needing things around them. The stories are organized and prioritized but may not meet everyone's needs. So rather than ask them to write the new code, I give the requesting team (the one with the need) the ability to write the new code into the API code base. Here is where things start to get really interesting.
How does it work
So now I have a change that one team can't do but my team can in order to essentially 'unblock' myself to move forward. Awesome. That API team allows me to submit code to their code base a-la Enterprise Source and get it deployed to support the actual feature function my team was asked to produce. I write what I need following their guidelines for development and using the information that they have provided to me in order to work in their code base. I make my change and submit it for code review which gives them the opportunity to give me feedback on the change my team was looking to make. A few rounds of code changes back and forth between my team and the team I am submitting code to and then the code is merged. That team then deploys on their normal schedule (hopefully following continuous delivery, so as quick as humanly possible).
What are some of the pitfalls
There are some human and technical drawbacks to this way of managing code bases and dealing with things inside the organization. Lets start with the technical drawbacks:
1) Who owns the machinery / hardware that gets deployed to
So my team submitted code to another team and they have deployed that code to their existing hardware providing me with access to the endpoint that I just wrote but this doesn't address situations where what I needed isn't like what anyone else needed. Now things get a little odd because with my team and the team I submitted code to we need to decide if new hardware would get stood up. Who manages that new hardware? Should the new hardware be something I deploy to all the time? Is the deployment in control of the team who 'owns' the code OR is it the responsibility of the team that submitted the code to get deployed? This can get messy quick. This writer also doesn't have a direct answer to these questions. It is an exercise in experimentation to find out what path works best for your teams and your organization.
2) Who owns the deployment process
As noted above this is a decent sized question that goes hand in hand with which team owns the hardware. You might be able to make use of the existing system for deployment easily, you may not and this will vary from team to team as while the infrastructure you are working on might very well be the same - in any company of size - the use of that infrastructure will differ and MIGHT differ greatly.
3) Arguments about the submitted code being 'Up to snuff'
Remember that in all cases there are humans involved so as a result personalities may clash. Teams should be aware that this is an almost 100% guaranteed conflict. As the owning team looks at their own internal process and moves the cheese for other teams that are submitting code to them. Things like code review, code style, testing style can become quite contentious if the discussion is not held in the open.
Benefits and impacts to the organization
The benefits to the organization focus mostly on allowing parts of the organization to slide past one another in a way that allows people to continue to move forward producing value. If one team gets blocked by another, dates become a discussion and people start to play games with he said / she said about when something might be able to be delivered. If teams are completely autonomous and allowed to do work at their own pace, then they control the dates and the delivery to their requester which prevents the dependency from causing to many if any issues. This form of organizational lubrication can be amazingly helpful.
Enterprise source is an excellent way to allow sections of the organization to share a common core code base and to continue to deliver on promises when everyone cares about the quality of the submissions and ownership of that shared code. If you find your team having dependency on another teams code base but they don't have time to make changes for you - consider offering to make the changes for them. Its a conversation starter that may lead to having a more open code environment for your organization.
Enterprise source for me describes a way in which I can manage software development that involves more than just 'my' team in order to accomplish a given task within my organization. In a host of ways enterprise source mirrors how an individual contributor would work with any open source software project - building up a change that adds a missing feature or fixing an existing bug and then submitting that to the project. What I build/submit might be something of value to everyone, or it might only be of value to me specifically but it is up to the project as to decide if what I submit is worth while to merge and make available as part of their project. The same process is used in enterprise source with some interesting hitches that are worth noting which we cover in slightly more depth later.
Why would you want to do enterprise source
So - in the very small scale of the word organization you likely wouldn't have need to do this at all. If your a company of 10's of developers there may not actually be any occasion to do this at all. Enterprise source however makes a great deal of sense when you are a corporation of significant size, multiples teams doing work across the organization. In the the large corporation sense what you would like to have is teams that are decoupled from one another in a way that allows them all to move to deployment and delivery independent from one another. Different teams will have different product drivers and potentially be working on completely different lines of business that require them to operate independently. At deeper levels in the technical stack however the teams may all have to interface with a back office, or an API set.
In the typical organization the team in control of the API set will have their deployment schedule and will take stories and other content for delivery from teams needing things around them. The stories are organized and prioritized but may not meet everyone's needs. So rather than ask them to write the new code, I give the requesting team (the one with the need) the ability to write the new code into the API code base. Here is where things start to get really interesting.
How does it work
So now I have a change that one team can't do but my team can in order to essentially 'unblock' myself to move forward. Awesome. That API team allows me to submit code to their code base a-la Enterprise Source and get it deployed to support the actual feature function my team was asked to produce. I write what I need following their guidelines for development and using the information that they have provided to me in order to work in their code base. I make my change and submit it for code review which gives them the opportunity to give me feedback on the change my team was looking to make. A few rounds of code changes back and forth between my team and the team I am submitting code to and then the code is merged. That team then deploys on their normal schedule (hopefully following continuous delivery, so as quick as humanly possible).
What are some of the pitfalls
There are some human and technical drawbacks to this way of managing code bases and dealing with things inside the organization. Lets start with the technical drawbacks:
1) Who owns the machinery / hardware that gets deployed to
So my team submitted code to another team and they have deployed that code to their existing hardware providing me with access to the endpoint that I just wrote but this doesn't address situations where what I needed isn't like what anyone else needed. Now things get a little odd because with my team and the team I submitted code to we need to decide if new hardware would get stood up. Who manages that new hardware? Should the new hardware be something I deploy to all the time? Is the deployment in control of the team who 'owns' the code OR is it the responsibility of the team that submitted the code to get deployed? This can get messy quick. This writer also doesn't have a direct answer to these questions. It is an exercise in experimentation to find out what path works best for your teams and your organization.
2) Who owns the deployment process
As noted above this is a decent sized question that goes hand in hand with which team owns the hardware. You might be able to make use of the existing system for deployment easily, you may not and this will vary from team to team as while the infrastructure you are working on might very well be the same - in any company of size - the use of that infrastructure will differ and MIGHT differ greatly.
3) Arguments about the submitted code being 'Up to snuff'
Remember that in all cases there are humans involved so as a result personalities may clash. Teams should be aware that this is an almost 100% guaranteed conflict. As the owning team looks at their own internal process and moves the cheese for other teams that are submitting code to them. Things like code review, code style, testing style can become quite contentious if the discussion is not held in the open.
Benefits and impacts to the organization
The benefits to the organization focus mostly on allowing parts of the organization to slide past one another in a way that allows people to continue to move forward producing value. If one team gets blocked by another, dates become a discussion and people start to play games with he said / she said about when something might be able to be delivered. If teams are completely autonomous and allowed to do work at their own pace, then they control the dates and the delivery to their requester which prevents the dependency from causing to many if any issues. This form of organizational lubrication can be amazingly helpful.
Enterprise source is an excellent way to allow sections of the organization to share a common core code base and to continue to deliver on promises when everyone cares about the quality of the submissions and ownership of that shared code. If you find your team having dependency on another teams code base but they don't have time to make changes for you - consider offering to make the changes for them. Its a conversation starter that may lead to having a more open code environment for your organization.
Sunday, April 3, 2016
Living with the gray areas
Agility is about living with the gray
In our travels as technologists we are constantly engaging in conversations with people about how technology works, should work, or has worked in the past. We spend time considering what we should be doing next and helping organizations to navigate through their individual challenges while attempting to deliver something great to consumers or simply to make the organization run smoother by utilizing technology to automate those things that are hard. We technologists write code, discover new things as we go along - our job as technologists is to live in the area outside of the known paths - we live inherently in the gray spaces where things haven't yet completely solidified. The idea isn't new but is just starting to come into power, this idea of living in the gray spaces was brought to light when the Agile Manifesto was penned - the manifesto opens with the following:
"We are uncovering better ways of developing software..."
Indicating that we don't yet know all the ways we might achieve what we set out to accomplish, but we'll discover at least one way. Along the way we may find many ways in which things don't work as well - but in doing so we'll learn what OUR path should be, or what path works best for us in a given situation at a given time.
Software development is all about living with the gray
When we as technologists (developers or otherwise) set out to do something new or to make changes to a system that already exists we are asked to 'create' something that meets a described need. When we start out, we may not be entirely sure how we are going to do the action of creation. At this moment we are confronted with hundreds of choices and hundreds of potential directions. We may feel a little overwhelmed but we are relatively well practiced at living with the gray space that choices create. We quickly navigate through the list of things we know, the list of things we don't know and start to devise ways in which we could experiment so as to understand what we don't know and "clear the fog" from the gray areas in our understanding. We may write example code as a way to experiment, perhaps a scratch refactor of existing code to fit in a new feature or trying something completely new by picking up a new technology or a new software stack. We use these techniques to help us get through the gray areas, solidifying things as we go.
One of the big problems is that while technologists are aware of and deal with gray areas in their understanding fairly well, most people that they deal with do not.
Humans deal with gray areas poorly
Inherently we humans seem to like control or at least to think we are in control. Uncertainty makes us uneasy. Equally, when there are a great number of choices that we could possibly choose from, we feel trapped and our fight or flight reactions start to take hold. Outside of technology this is actually quite un-nerving to most people. As I stated above just about everything in technology is about living solidly in the gray areas and slowly working to make them less gray and more certain. The businesses that we work with and for however don't see things quite that way. Every company I have ever worked for would like to think that software development is an inherently known quantity, that software development easily equates to something that they know is straight forward like building things or assembling items. Software however is a creative process that defies being estimated up front. At the very start of a new endeavor we might be able to provide some context and information which can inform an estimate for how long it will take to accomplish but we should allow that initial estimate to more accurately relate to the gray that surrounds it, all the things we don't yet know. That first estimate should have a confidence interval - say 25% confidence with a list of all the gray areas that surround this beginning estimate and a set of steps for how those gray areas will be solidified and more well understood. This changes the discussion from - "Are we on plan for finishing X" to "What did we learn today and how did it impact our confidence we'll be able to do what was asked".
In short...
Software development, and by extension Agility, and other software development frameworks/methodologies have to help us deal with the gray areas. The systems we choose to use when developing software should allow us to embrace the gray areas. Frameworks we know about currently, Scrum, SAFe, Kanban all describe ways in which we can get context around what we are doing and allowing us to wipe away the gray. We can use small experiments to guide us to better places. We can learn to fail fast, as the faster we fail at doing something the more we learn. We can embrace the gray areas because that is where the learning is and it is where we expand our horizons.
In our travels as technologists we are constantly engaging in conversations with people about how technology works, should work, or has worked in the past. We spend time considering what we should be doing next and helping organizations to navigate through their individual challenges while attempting to deliver something great to consumers or simply to make the organization run smoother by utilizing technology to automate those things that are hard. We technologists write code, discover new things as we go along - our job as technologists is to live in the area outside of the known paths - we live inherently in the gray spaces where things haven't yet completely solidified. The idea isn't new but is just starting to come into power, this idea of living in the gray spaces was brought to light when the Agile Manifesto was penned - the manifesto opens with the following:
"We are uncovering better ways of developing software..."
Indicating that we don't yet know all the ways we might achieve what we set out to accomplish, but we'll discover at least one way. Along the way we may find many ways in which things don't work as well - but in doing so we'll learn what OUR path should be, or what path works best for us in a given situation at a given time.
Software development is all about living with the gray
When we as technologists (developers or otherwise) set out to do something new or to make changes to a system that already exists we are asked to 'create' something that meets a described need. When we start out, we may not be entirely sure how we are going to do the action of creation. At this moment we are confronted with hundreds of choices and hundreds of potential directions. We may feel a little overwhelmed but we are relatively well practiced at living with the gray space that choices create. We quickly navigate through the list of things we know, the list of things we don't know and start to devise ways in which we could experiment so as to understand what we don't know and "clear the fog" from the gray areas in our understanding. We may write example code as a way to experiment, perhaps a scratch refactor of existing code to fit in a new feature or trying something completely new by picking up a new technology or a new software stack. We use these techniques to help us get through the gray areas, solidifying things as we go.
One of the big problems is that while technologists are aware of and deal with gray areas in their understanding fairly well, most people that they deal with do not.
Humans deal with gray areas poorly
Inherently we humans seem to like control or at least to think we are in control. Uncertainty makes us uneasy. Equally, when there are a great number of choices that we could possibly choose from, we feel trapped and our fight or flight reactions start to take hold. Outside of technology this is actually quite un-nerving to most people. As I stated above just about everything in technology is about living solidly in the gray areas and slowly working to make them less gray and more certain. The businesses that we work with and for however don't see things quite that way. Every company I have ever worked for would like to think that software development is an inherently known quantity, that software development easily equates to something that they know is straight forward like building things or assembling items. Software however is a creative process that defies being estimated up front. At the very start of a new endeavor we might be able to provide some context and information which can inform an estimate for how long it will take to accomplish but we should allow that initial estimate to more accurately relate to the gray that surrounds it, all the things we don't yet know. That first estimate should have a confidence interval - say 25% confidence with a list of all the gray areas that surround this beginning estimate and a set of steps for how those gray areas will be solidified and more well understood. This changes the discussion from - "Are we on plan for finishing X" to "What did we learn today and how did it impact our confidence we'll be able to do what was asked".
In short...
Software development, and by extension Agility, and other software development frameworks/methodologies have to help us deal with the gray areas. The systems we choose to use when developing software should allow us to embrace the gray areas. Frameworks we know about currently, Scrum, SAFe, Kanban all describe ways in which we can get context around what we are doing and allowing us to wipe away the gray. We can use small experiments to guide us to better places. We can learn to fail fast, as the faster we fail at doing something the more we learn. We can embrace the gray areas because that is where the learning is and it is where we expand our horizons.
Subscribe to:
Posts (Atom)
