On design and collaboration
This post has had a long gestation period, starting after I attended the BCS PROMS-G Spring Summer School on Risk in 2013!
I've been thinking a lot recently about process and why we do it and what we hope to achieve. In my experience there are a large group of people who cringe when they even hear the word "process", seeing it as a command and control mechanism. But I believe that for every necessary process there is a positive by product that we should be focussing on, and working with, for improvement.
To illustrate this I will discuss a design review process. Say an organisation has issues with the introduction and evaluation of new technologies and techniques. So the re-action is to introduce a formal design review process, with feedback from various stakeholders and sign-off before the change gets the go ahead.
The tale of the 6 blind men and the elephant where different perspective and views on an issue, we need to see the bigger picture and get a common perspective to overcome conflict (or a poor/incomplete solution). For example, if you're the blind man by the leg your strategy for dealing with the "tree" in front of you might backfire when the tusk you can't see gauges you.
Or a much snappier summation:
With a design process some developers seem to be good at getting input from business owners and production services. It is very hard for any individual team in a company, once it gets to a certain size, to have all the skills required within it to be entirely self-sufficient. The trouble is depending on your day-to-day work your view of "good" or "efficient" and so on can be very different.
Changes that introduce “new” and “different” code are also areas that introduce risk. I can understand non-technical PMs not getting involved in the solution design, but there are trigger words that should be coming up in the progress meetings that should then prompt them to ask the questions “does this change need a design review?”, “is this type of solution being used elsewhere in the company?”, “have you run this past X,Y or Z?” (or even high-level, forward looking things like “how can this be maintained without downtime when live?”)
Perhaps I'm projecting my fears, but I think that some experienced developers will avoid a design review as they only see it as getting technical advice on programming techniques etc., which since they can see the solution to the problem in front of them they then don’t feel the need for. I’m also not sure that they or the PMs then see it as also being a way of managing risk and communication … in addition to the more obvious goal of getting a fuller solution input. It is easy for both groups to miss that coding time and effort is only a small part of the software development life-cycle and don’t consider the impact it will have on operations and production services. Hopefully we can all agree that the best solutions come from multiple views points and specialisms, indeed that is a general thrust from Agile, I know even my very best ideas are made better by getting other people to review them ;-)
Build a Trustworthy Design Process - Blog post on Medium that talks about how the purpose of critique in design is to draw out mindful or intentional decisions.
I've been thinking a lot recently about process and why we do it and what we hope to achieve. In my experience there are a large group of people who cringe when they even hear the word "process", seeing it as a command and control mechanism. But I believe that for every necessary process there is a positive by product that we should be focussing on, and working with, for improvement.
To illustrate this I will discuss a design review process. Say an organisation has issues with the introduction and evaluation of new technologies and techniques. So the re-action is to introduce a formal design review process, with feedback from various stakeholders and sign-off before the change gets the go ahead.
The tale of the 6 blind men and the elephant where different perspective and views on an issue, we need to see the bigger picture and get a common perspective to overcome conflict (or a poor/incomplete solution). For example, if you're the blind man by the leg your strategy for dealing with the "tree" in front of you might backfire when the tusk you can't see gauges you.
Or a much snappier summation:
With complex problems, we need as many and as diverse conversations as possible @hjarche bit.ly/c5Y4kz
— David Gurteen (@DavidGurteen) March 22, 2013
With a design process some developers seem to be good at getting input from business owners and production services. It is very hard for any individual team in a company, once it gets to a certain size, to have all the skills required within it to be entirely self-sufficient. The trouble is depending on your day-to-day work your view of "good" or "efficient" and so on can be very different.
Changes that introduce “new” and “different” code are also areas that introduce risk. I can understand non-technical PMs not getting involved in the solution design, but there are trigger words that should be coming up in the progress meetings that should then prompt them to ask the questions “does this change need a design review?”, “is this type of solution being used elsewhere in the company?”, “have you run this past X,Y or Z?” (or even high-level, forward looking things like “how can this be maintained without downtime when live?”)
Perhaps I'm projecting my fears, but I think that some experienced developers will avoid a design review as they only see it as getting technical advice on programming techniques etc., which since they can see the solution to the problem in front of them they then don’t feel the need for. I’m also not sure that they or the PMs then see it as also being a way of managing risk and communication … in addition to the more obvious goal of getting a fuller solution input. It is easy for both groups to miss that coding time and effort is only a small part of the software development life-cycle and don’t consider the impact it will have on operations and production services. Hopefully we can all agree that the best solutions come from multiple views points and specialisms, indeed that is a general thrust from Agile, I know even my very best ideas are made better by getting other people to review them ;-)
Further Reading
Three books - Blog post from Bob Marshall for further reading on gathering ideas from a variety of sources (especially like the Jim Benson quote ;)Build a Trustworthy Design Process - Blog post on Medium that talks about how the purpose of critique in design is to draw out mindful or intentional decisions.
Comments
Post a Comment