Difference between revisions of "Reconciling Perspectives"
(Added ahas) |
m (→Ahas from the session: remove seemingly random text) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
| − | + | === Ahas from the session === | |
| − | |||
| − | Ahas from the session | ||
* Difference between consensus and consenual agreement | * Difference between consensus and consenual agreement | ||
* Can apply it to multiple levels. The double loop learning concept | * Can apply it to multiple levels. The double loop learning concept | ||
| Line 18: | Line 16: | ||
* Nice to see the model. I used to do a lot of bunkering and deliver the wrong thing | * Nice to see the model. I used to do a lot of bunkering and deliver the wrong thing | ||
* Did notice that you can apply this model for any team that is doing anything together. This model provides a reason for why we are teaching certain practices. | * Did notice that you can apply this model for any team that is doing anything together. This model provides a reason for why we are teaching certain practices. | ||
| + | |||
| + | === Notes on the paper from [[Laurence Whelpton]] === | ||
| + | (Originally shared on the CITCON Slack instance: https://citcon.slack.com/archives/CFP4Z5GPL/p1558356657048300) | ||
| + | <p>''This was a very interesting session. In this context a perspective is a mental model or view on the piece of work that needs to be done. When two (or more) individuals have differing perspectives then there is said to be a perspective mismatch (for example not agreeing on what the final software would look like). I believe the model can be applied to customer-developer relationships (perspective mismatches on requirements) and developer-developer relationships (perspective mismatches on internal implementation).''</p> | ||
| + | <p>''When there is a mismatch, then generally reaching out occurs, where the parties will communicate, negotiating consensus until their perspectives converge and they reach a consensual agreement. Note that it is consensual agreement and not necessarily that you believe the perspective is correct, you come to some kind of agreement that allows you to then move on to work on the product.''</p> | ||
| + | <p>''Then comes the validating stage, which involves bunkering (doing the work) and accepting (checking it against perspectives). My take on this is, during bunkering you do the work and produce some kind of artifact or product which you can then see if it matches your perspective. If it doesn't, you continue to work. If you are happy with it, then the artifact is shown to others and if it mismatches their perspectives (ie you have built the wrong thing), then you once again have a perspective mismatch that you need to reconcile.''</p> | ||
| + | <p>''Then you will go back to the converging process and once a consensus is there, back again to validating (and building). The paper goes in to more detail and talks about scale (the model applying to both large high level jobs and smaller immediate cycles) and I would recommend at least reading Part 3 - Results for the most value from this paper.''</p> | ||
| + | <p>''To me, it is a nice model for agile product development, if you can make the whole reconciling perspective loop as iterative (short and fast) as possible you will reduce risk of wasted effort, ie spending all your time in the bunkering state building the wrong product only to finally have a massive artifact that is completely rejected from the other's perspective.''</p> | ||
| + | <p>''We also in the session, tried to apply the model to a waterfall process and we came up with the idea you do a once off reconciliation of perspectives (the big old requirements gathering), negotiating consensus (signed off/passes the phased gate), then the large duration of bunkering happens (development) and finally one artifact is produced that is likely to not be accepted, and as we know with waterfall, by this point it is usually too prohibitive to go back to reconciling the perspectives and starting again.''</p> | ||
Latest revision as of 01:37, 25 May 2019
Discussion based on the paper Reconciling perspectives: A grounded theory of how people manage the process of software development
http://www.sxf.uevora.pt/wp-content/uploads/2013/03/Adolph_20121.pdf
Ahas from the session
- Difference between consensus and consenual agreement
- Can apply it to multiple levels. The double loop learning concept
- Relating this to myself and how comfortable I am in bunkering and how hard is is for me to reach out and it is crucial to validate my model.
- The work generates information and that generates misalignment. Coupled with that, with cognitive distortions you are often not aware of the fact that your views change over time. The work not only generates misalignment but it’ll also make consensus this way (it’s obvious and has always been obvious). The information generated in bunkering will lead to more problems in negotiating consensus
- To learn that there is a model out there to be aware of where you are in the point of delivering software.
- Descriptive model and recognize and think “I’ve done that and I’ve seen that happening”. Could be useful to provide theese labels in the future.
- It is a scientific explanation for why we should continue duing kanban. And can put a sticker on it without using a buzzword
- Like the model. Nice to see an abstract description of what we do
- Nice to see the model. I used to do a lot of bunkering and deliver the wrong thing
- Did notice that you can apply this model for any team that is doing anything together. This model provides a reason for why we are teaching certain practices.
Notes on the paper from Laurence Whelpton
(Originally shared on the CITCON Slack instance: https://citcon.slack.com/archives/CFP4Z5GPL/p1558356657048300)
This was a very interesting session. In this context a perspective is a mental model or view on the piece of work that needs to be done. When two (or more) individuals have differing perspectives then there is said to be a perspective mismatch (for example not agreeing on what the final software would look like). I believe the model can be applied to customer-developer relationships (perspective mismatches on requirements) and developer-developer relationships (perspective mismatches on internal implementation).
When there is a mismatch, then generally reaching out occurs, where the parties will communicate, negotiating consensus until their perspectives converge and they reach a consensual agreement. Note that it is consensual agreement and not necessarily that you believe the perspective is correct, you come to some kind of agreement that allows you to then move on to work on the product.
Then comes the validating stage, which involves bunkering (doing the work) and accepting (checking it against perspectives). My take on this is, during bunkering you do the work and produce some kind of artifact or product which you can then see if it matches your perspective. If it doesn't, you continue to work. If you are happy with it, then the artifact is shown to others and if it mismatches their perspectives (ie you have built the wrong thing), then you once again have a perspective mismatch that you need to reconcile.
Then you will go back to the converging process and once a consensus is there, back again to validating (and building). The paper goes in to more detail and talks about scale (the model applying to both large high level jobs and smaller immediate cycles) and I would recommend at least reading Part 3 - Results for the most value from this paper.
To me, it is a nice model for agile product development, if you can make the whole reconciling perspective loop as iterative (short and fast) as possible you will reduce risk of wasted effort, ie spending all your time in the bunkering state building the wrong product only to finally have a massive artifact that is completely rejected from the other's perspective.
We also in the session, tried to apply the model to a waterfall process and we came up with the idea you do a once off reconciliation of perspectives (the big old requirements gathering), negotiating consensus (signed off/passes the phased gate), then the large duration of bunkering happens (development) and finally one artifact is produced that is likely to not be accepted, and as we know with waterfall, by this point it is usually too prohibitive to go back to reconciling the perspectives and starting again.
