Ineffective communication is clearly the weak point of several software development projects. The causes can be diverse and the consequences catastrophic. Looking more deeply to these causes, we identified two major ramifications of the problem:
- the interaction between the product owners and the end users and
- the interaction between stakeholders and developers.
Communication between the owner who is paying for the development of the software and the users who actually use it has been widely studied by the Lean Development, with practical and extremely effective results for those who are actually willing to minimize the problem (Product-Market Fit, Minimum Viable Product, Lean Code, ...). No magic solution yet found, but it is understood that the work must be in conjunction with the direct participation, unrestricted and as early as possible by the end users in the software development process. Learn more about Lean Development here, or about Lean Startups here.
Is not hard to see the huge conflict of interest that most development companies just generate within their own environment. When interests are in conflict, information came to mean a source of power, directly affecting the transparency and effectiveness of communications.
How many programmers have not heard from their managers the annoying phrase: "Why do you want to know that?"?
How many stakeholders have already faced totally fuzzy development diagrams, beginning with the "Gang of Four" and ending with no terms that can be understood?
We know that transparency is key to most of the eXtreme Programming values (citing courage, communication, feedback and respect). The Live Source Toolkit gives stakeholders or any non-technical person a non-intimidating window into code and a concrete medium for communicating with developers in familiar language. We are advocating that open dialog in front of the reality of the source code brings a confidence that can't be provided anywhere else. It will be the stakeholder's responsibility to supply feedback with respect and the programmer's responsibility to maintain the courage and clarity of communication.
In summary, we are building a tool to go beyond social interaction without replacing it. We are building a medium to enable a conversation with transparency, not only a case tool.
June & Alline
No Rights Reserved. Please copy us!
- the interaction between the product owners and the end users and
- the interaction between stakeholders and developers.
Communication between the owner who is paying for the development of the software and the users who actually use it has been widely studied by the Lean Development, with practical and extremely effective results for those who are actually willing to minimize the problem (Product-Market Fit, Minimum Viable Product, Lean Code, ...). No magic solution yet found, but it is understood that the work must be in conjunction with the direct participation, unrestricted and as early as possible by the end users in the software development process. Learn more about Lean Development here, or about Lean Startups here.
The other branch of the problem of communication in building software is the gap created between project developers and the stakeholders (project managers, company directors, business experts, ...). Let's bring the conversation from the lofty abstraction that is the usual context for such conversations, down to the brass tacks available to us through closer involvement with actual code.
Experience on both sides of the communication divide (as stakeholders and as developers), has led us to believe that a deeper understanding of the psychology behind such interactions contains a solution.
Is not hard to see the huge conflict of interest that most development companies just generate within their own environment. When interests are in conflict, information came to mean a source of power, directly affecting the transparency and effectiveness of communications.
How many programmers have not heard from their managers the annoying phrase: "Why do you want to know that?"?
How many stakeholders have already faced totally fuzzy development diagrams, beginning with the "Gang of Four" and ending with no terms that can be understood?
Like it or not, developers are motivated to keep their code hidden from those they are accountable to. Their specialized technical knowledge provides a layer of protection from attack for bad technical decisions and sloppy work.
Even if a programmer is producing excellent code, but also works in an environment strictly hierarchical, unlike an Agile team, this developer is probably at the bottom of the blame chain and will still have the tendency to hide artifacts, because it is the only way to be protected in turbulent situations. A typical defense mechanism used by programmers is to use language and jargon that are deliberately obtuse to the stakeholders.
Stakeholders are typically specialized in a field other than software engineering. Code is black magic to them and they are required to invest blind faith in the technical team to build them a quality product. They can’t speak programmer language, but need deeper insight into the technical cost of what they are requesting.
We know that transparency is key to most of the eXtreme Programming values (citing courage, communication, feedback and respect). The Live Source Toolkit gives stakeholders or any non-technical person a non-intimidating window into code and a concrete medium for communicating with developers in familiar language. We are advocating that open dialog in front of the reality of the source code brings a confidence that can't be provided anywhere else. It will be the stakeholder's responsibility to supply feedback with respect and the programmer's responsibility to maintain the courage and clarity of communication.
In summary, we are building a tool to go beyond social interaction without replacing it. We are building a medium to enable a conversation with transparency, not only a case tool.
June & Alline
No Rights Reserved. Please copy us!
No comments:
Post a Comment