|
Push software development describes a set of communication principles for software development under which requirements and solutions evolve through the collaborative effort of multi-functional individuals as opposed to cross-functional teams. The model is used only when all participants for a business requirement have a mid to high level understanding of the overall business. This model is used all individuals participating have a similar understanding of the business and the communication style in the business. This model differs from existing models/paradigms as every participant in the development process must have a cross understanding of each other participants perspective in the process. Agile software development generally requires cross-functional teams whereas, push development requires cross-functional individuals comprising and over all team. An example how everyone has a mutual understanding of everyone else's position and role in a process would be in a surgical operating room. During surgery everyone has a different task yet everyone has the same understanding of the process, medical terms, generally how long the procedure should take, what is involved during the procedure, the basic order of the procedure, etc. This model is inherently used by small start-up software companies, e.g, think Facebook, Google, Uber, Instagram in their first 2 yearsof existence. Some companies maintain this model but most tend to deviate to more traditional business process and project management cycles. A simple example would be where marketing requests a new feature on a website. The classic "push" comes in where marketing explains the desired feature to development and development already has an <u>understanding of how the feature will work in the business</u> and requires no other input from marketing. The result is the final feature is pushed into the production environment and marketing. Marketing and the developers need to understand each aspect of the requirement and it's over all impact on existing and future parts of the business. The more traditional method would be; for marketing to give their requirement (aka user-story) and then continually work in small agile like groups getting weekly updates, deploying and then following up with further "fixes" that where not fully understood or communicated during the cycle. Basically the business world will need to adopt and development understanding and everything is becoming softwarefor the business. Marketing can no longer, "throw it over the wall" * You will need to have a basic understanding of business. * You will need to have a basic understanding of finance. * You will need to have a basic understanding of software development. * You will need to have a basic understanding of the operational requirements of the system the process will run on. * You will need a basic understanding of the future direction of the business. Developers that are "contractors" will have a more difficult time in this environment as they will not have the deep and on going understanding of the business. Another example of this level of communication would be where a lay-person was directing a surgery using lay-person terminology and having no knowledge of medial procedures. This would cause confusion and time to interpret and re-interpret terms and would invariably perform a procedure out of standard surgical order. This model does not deviate greatly from other software develop activities but everyone involved will need to understand the requirements, the design, the construction limitations, testing, and maintaining. this model will become more prevalent as systems and processes from every aspect of every business become dependent on software. It will be necessary for everyone in a businesses to have a basic to moderate level of understanding of what goes into a final software system. This model is inherently used by start-ups as the very few people involved in a start-up will understand everything going on in the business. Generally as business grow larger there will be a growing divergence in departments which will undermine push-style development. The divergent departments will no longer understand the entire overall needs of the business. For existing companies that have a silo-model of management push-development will not work. As marketing, sales, finance, logistics, manufacturing, executive and the like decide on a new software process each doesn’t understand the overall needs of any other dept and development. These types of failures have and will always exist in these; Why 40-Year-Old Tech Is Still Running America’s Air Traffic Control Collaborative meetings that attempt consensus are not desired. In push-development collaboration doesn't equal consensus; meetings need to move people away from the undefined center or group thinking and move to innovative and definitive ideas. Collaborate not compromise nor find a consensus it is not supposed to be democratic it is supposed to be somewhere from tactical to strategic with each deployment. Collaboration would mean everyone has an equal understanding of the end result. General Electric's CEO wants every millennial that he hires to learn to code. <references />
|
|
|