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.
Showing posts with label collaboration. Show all posts
Showing posts with label collaboration. Show all posts
Tuesday, April 5, 2016
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.
Monday, November 24, 2014
Generativity, an open door policy
So, I have had some time to sit and consider what it is about software projects in my work a day world that make for successes and what things make for interesting types of failure. Here is where my thinking landed me:
1) Being open, and inviting is a benefit not to be undersold
It sounds so tantalizingly simple when you type it out like that, so much so that you might read that line above as "...If you build it, they will come..." but that isn't quite what that line means.
When teams develop new software, the software being developed is sometimes about a new feature or a new thing that BigCo. wants to have as a product and sometimes is to scratch an itch that the team has. In either case, this new software is likely to be able to assist a whole bunch of people which same or similar needs (it is unusual for software to actually be built 100% single purpose). Because most software can actually serve many 'close knit' needs, once you or your team has taken the time to build, you should also take the time to advertise and allow other teams to make use of what you have built. Being open, means no matter what you develop that you essentially open the door to others to build, manage or deploy with you. Let other groups make use of the things you built, with as few a number of restrictions, provisos, caveats as humanly possible.
2) Protect the system, but keep the number of rules as low as you can
This is somewhat self explanatory - try to only put in place those rules that help you to make sure that the system is up, available, and working correctly.
3) Trust people to do whats right
When you open the door - you are opening your system up to whatever may come. To that point, you have to be able to trust that peoples self interest will also align with you and yours to some degree. Try to keep a light touch and trust that people will not go out of their way to screw you - or the system you built - that they are now using. If those who have been invited in through the open door do take advantage, know in advance how you would like to react to those coming to seek your new hot thing. Describe your "open door" so that people know what they are signing up for in advance.
4) Don't fall into the trap of N.I.H.
Part of doing work this way, with this mind set, is preventing yourself from going off into a corner and building it yourself because:
* You believe that building it yourself is the only way to control your own destiny
* Your team can't possibly be successful because your success is dependent on another team
It will always be simpler to modify something that is already built than it will be to go from scratch no matter how good your developers are. Work already done can trump work to be done in a great number of occasions.
5) Command and control will squash peoples desire to use what you build
Don't try to control the software and how its used too must - exercise just enough control to manage and maintain the quality of the system. I have seen plenty of people that believe that becoming the manager, exec, vp, director or what have you is all about being able to do it JUST the way they want. Nothing really could be further from the truth. The farther up the chain you go, the less desire to control you should have and the more trust you have to have that things will head in the right direction. If you attempt to stringently control things, no one will want to come be a part of the thing that was built and like holding a fist full of sand, the harder you squeeze the more sand you will lose, no way to hold it all.
Be open, be inviting, be willing to negotiate and understand how people will want to use your software. Be generative - providing space for people to get the most amount of benefit out of the building blocks you have already put together. It will eventually help the bottom line because everything being built will start to move faster, eventually.
1) Being open, and inviting is a benefit not to be undersold
It sounds so tantalizingly simple when you type it out like that, so much so that you might read that line above as "...If you build it, they will come..." but that isn't quite what that line means.
When teams develop new software, the software being developed is sometimes about a new feature or a new thing that BigCo. wants to have as a product and sometimes is to scratch an itch that the team has. In either case, this new software is likely to be able to assist a whole bunch of people which same or similar needs (it is unusual for software to actually be built 100% single purpose). Because most software can actually serve many 'close knit' needs, once you or your team has taken the time to build, you should also take the time to advertise and allow other teams to make use of what you have built. Being open, means no matter what you develop that you essentially open the door to others to build, manage or deploy with you. Let other groups make use of the things you built, with as few a number of restrictions, provisos, caveats as humanly possible.
2) Protect the system, but keep the number of rules as low as you can
This is somewhat self explanatory - try to only put in place those rules that help you to make sure that the system is up, available, and working correctly.
3) Trust people to do whats right
When you open the door - you are opening your system up to whatever may come. To that point, you have to be able to trust that peoples self interest will also align with you and yours to some degree. Try to keep a light touch and trust that people will not go out of their way to screw you - or the system you built - that they are now using. If those who have been invited in through the open door do take advantage, know in advance how you would like to react to those coming to seek your new hot thing. Describe your "open door" so that people know what they are signing up for in advance.
4) Don't fall into the trap of N.I.H.
Part of doing work this way, with this mind set, is preventing yourself from going off into a corner and building it yourself because:
* You believe that building it yourself is the only way to control your own destiny
* Your team can't possibly be successful because your success is dependent on another team
It will always be simpler to modify something that is already built than it will be to go from scratch no matter how good your developers are. Work already done can trump work to be done in a great number of occasions.
5) Command and control will squash peoples desire to use what you build
Don't try to control the software and how its used too must - exercise just enough control to manage and maintain the quality of the system. I have seen plenty of people that believe that becoming the manager, exec, vp, director or what have you is all about being able to do it JUST the way they want. Nothing really could be further from the truth. The farther up the chain you go, the less desire to control you should have and the more trust you have to have that things will head in the right direction. If you attempt to stringently control things, no one will want to come be a part of the thing that was built and like holding a fist full of sand, the harder you squeeze the more sand you will lose, no way to hold it all.
Be open, be inviting, be willing to negotiate and understand how people will want to use your software. Be generative - providing space for people to get the most amount of benefit out of the building blocks you have already put together. It will eventually help the bottom line because everything being built will start to move faster, eventually.
Subscribe to:
Posts (Atom)
