JonMQuigley
12-29-2018, 02:32 PM
Clues! Signals!
This is the result of a collaboration initiated by John Cutler (https://twitter.com/johncutlefish) on Twitter with Jon M Quigley (https://twitter.com/JonMQuigley). In fact, we did this over Google docs he was accepting the changes just about faster than I could write them down, it was funny to do that in real time.
Pay attention. There may be an an opportunity for improvement...
Might as well do [some extra thing] while we [do the original thing]
Distraction consuming hours putting the original thing at risk (hours available and cost) (see 6 myths of product development)
Second thing not being communicated with the rest of the team members may come at cost to the system when entirety is assembled
Something unexpected by other team members = cost poor quality rework
We dont want to have to revisit [some decision]
Staying with a solution that is not a solution, or will end poorly. wasting time and effort
Unable to make a decision or decision takes inordinate amount of time for fear that the decision is irreversible
While were waiting on [some blocker], lets start [something new]
When the block is removed we are unprepared or distracted due to task switching
Too preoccupied with new something to contribute to the blocked cause
No learning from blocked cause by those others that are not participating in resolution (which may be okay)
It would probably be more efficient if we
Doubling up when things should be consecutive puts depending tasks at risk of rework and unable to adapt to actual outcome
If we neglect some base product management (cutting schedule time is not necessarily efficient)
Throw talent at the problem believing that 9 women pregnant for a month can produce a baby (do not know the laws of diminishing returns)
Its too early to [some interaction with users/customers]
Waiting for feedback means more built and the possibility of being farther away from the desired objective (like a pilot that only checks the compass after hundreds of miles from takeoff)
Mockups, quick product demos and prototypes that look little like the end product can be effective to get this information from the customer the earlier the better.
If we bundle these things together we will get [some efficiency]
Over 80% capacity we are looking at larger delays for small difficulties - queueing theory
We dont all need to be in the room for [some decision]
Different perspectives help uncover:
Unvetted assumptions
Different ideas to explore and pursue
Communications needs of different people or team members
Ultimately project failure due to limited or conflicting communication and excluding voices that should have been heard
We can get ahead of it by [a series of handoffs]
Every hand off is a communication hurdle and opportunity for missed communications
Risk dependency, probability of success 1 X probability of success 2 = Sum of probability of success
Think of this as the more exchanges the more opportunities for failure (systems engineering)
Well [some person] is the only person who can do [some task]
Lost opportunity to get rid of this limitation when we do not double this up seasoned person and new but interested person
when this person leaves the company, we have no-one
It doesnt work now, but it will work when [some future task is done]
How do you know, if you are incorrect, you find out way too late and are unable to respond?
If we have a little downtime, we might as well try to fit in [another task]
If this is not part of the scope this is a waste of time and money
Team synchronization / communication - that is working on parts that other team members should be aware
Well have to wait on [some person] to make that decision
Delaying decisions delay the project, this consequence must be accepted
No escalation plan - could put you in a holding pattern indefinitely
Its the right thing to do but [some excuse masquerading as pragmatism]
Not looking at long term consequences - lack of systems thinking
Lack of courage our team does not feel comfortable saying things that rock the boat
We just need to lock down [some specification] and then we can
Some portions of the specification, certainly. The entirety no
We do not know what we do not know, requires specification changes, no need to waste time with reworking the specification
Just this one time lets [some cut corner] and then well fix it, hopefully
This become habit we will do this for any modicum of pressure
Those not technically oriented wil challenge when you want to resort to no corner cutting
People will forget what correct looks like because we now have many ways to do this
The path of least resistance becomes common even i this is not the best approach
We need to do this to close [one deal]. But Im sure it will apply elsewhere
See the prior items
Oh Ill just do this on the side. That way it will not be micromanaged
No communication with other team members
Fit issues
Micromanagement is a problem also - that would be what should be solved -your team does not believe they can make decisions and take the initiative. You paid for talent then let it waste away.
Oh, this doesnt need UX [or QA, Ops, etc.]
You will likely find out later that the product does not meet the customer needs
Poor quality in the field comes with rework and replacement in the field, litigation, service costs, reputation impact
Not including operations means we may not have the ability to build this thing and ship to customer or deploy
So we have this [side project]...can you attend the meeting to [plan in secret]?
Missing key players - unvetted assumptions, few possible ways to approach (ideation)
Trust issues - dont want to share for whatever reason
Distraction of workforce if this person should be working on another project
Oh we cant risk [trying some valuable goal]...
No risk = no reward
Exploration need not be risky - could find an easy low risk way to explore
Eliminating learning opportunity for team members
No desire for innovation which comes from this type of exploration
Oh you cant test [some feature] because [some perceived limitation]
Testing incremental iterations provides feedback to the developers
It is possible to test some portions that work to learn about that work
Configuration Management (via release notes) provides the map of features able to be tested
Waiting for all functions available to start testing means finding bugs up against the launch deadline
You are destroying the iterative and incremental model of working
We need individual owners otherwise [some inability to track/punish]
Problem when you punish - trust issues in the organization
One perspective often does not provide a true view of the field
Well, were unique because [some non-unique challenge]
Unique or not unique, there is likely a solution that will meet the objective if you explore, test and learn. Otherwise you are stuck in this morass for the rest of your days
No way to get better living with the limitations without exploration
This is too big for one sprint, so well do phase one now and .
Im pretty sure I can represent the customer in this case
Not sure any individual not a customer is in a position to actually
Myopic one perspective
Likely discovered when the product goes to the customer things that were missed resulting in rework
Gets in the habit of making the call for the customer rather than asking the customer
[Some effort] is too big to fail. We need to get this right
Still requires attacking incrementally (how do you eat an elephant)
Building all, means we find all of the errors and poor decisions late or at the end
Requires rework - and late with no time to adequately address
We need some quick wins because [normal wins take too long]
Then find a way to improve the normal wins rate
Work on your corporate discipline - delayed gratification
Eroded the corporate discipline and any repeat-ability
I think we can parallelize [two related efforts]...
If these are to be sequential there is risk of rework of the depending task when the preceding task does not deliver exactly as expected (see compounding impact of risk)
Delays delivery of the iteration
And then [some other group] can maintain it, right?
There was learning in the development of the product that only the group doing will have
Communications challenges with the transition - what should we tell and to whom
Better to keep some members of the maintaining group involved during development if this must be a different group
Problems with the ability to maintain, constant interaction with the developers
Ultimately poor post development support
This is the result of a collaboration initiated by John Cutler (https://twitter.com/johncutlefish) on Twitter with Jon M Quigley (https://twitter.com/JonMQuigley). In fact, we did this over Google docs he was accepting the changes just about faster than I could write them down, it was funny to do that in real time.
Pay attention. There may be an an opportunity for improvement...
Might as well do [some extra thing] while we [do the original thing]
Distraction consuming hours putting the original thing at risk (hours available and cost) (see 6 myths of product development)
Second thing not being communicated with the rest of the team members may come at cost to the system when entirety is assembled
Something unexpected by other team members = cost poor quality rework
We dont want to have to revisit [some decision]
Staying with a solution that is not a solution, or will end poorly. wasting time and effort
Unable to make a decision or decision takes inordinate amount of time for fear that the decision is irreversible
While were waiting on [some blocker], lets start [something new]
When the block is removed we are unprepared or distracted due to task switching
Too preoccupied with new something to contribute to the blocked cause
No learning from blocked cause by those others that are not participating in resolution (which may be okay)
It would probably be more efficient if we
Doubling up when things should be consecutive puts depending tasks at risk of rework and unable to adapt to actual outcome
If we neglect some base product management (cutting schedule time is not necessarily efficient)
Throw talent at the problem believing that 9 women pregnant for a month can produce a baby (do not know the laws of diminishing returns)
Its too early to [some interaction with users/customers]
Waiting for feedback means more built and the possibility of being farther away from the desired objective (like a pilot that only checks the compass after hundreds of miles from takeoff)
Mockups, quick product demos and prototypes that look little like the end product can be effective to get this information from the customer the earlier the better.
If we bundle these things together we will get [some efficiency]
Over 80% capacity we are looking at larger delays for small difficulties - queueing theory
We dont all need to be in the room for [some decision]
Different perspectives help uncover:
Unvetted assumptions
Different ideas to explore and pursue
Communications needs of different people or team members
Ultimately project failure due to limited or conflicting communication and excluding voices that should have been heard
We can get ahead of it by [a series of handoffs]
Every hand off is a communication hurdle and opportunity for missed communications
Risk dependency, probability of success 1 X probability of success 2 = Sum of probability of success
Think of this as the more exchanges the more opportunities for failure (systems engineering)
Well [some person] is the only person who can do [some task]
Lost opportunity to get rid of this limitation when we do not double this up seasoned person and new but interested person
when this person leaves the company, we have no-one
It doesnt work now, but it will work when [some future task is done]
How do you know, if you are incorrect, you find out way too late and are unable to respond?
If we have a little downtime, we might as well try to fit in [another task]
If this is not part of the scope this is a waste of time and money
Team synchronization / communication - that is working on parts that other team members should be aware
Well have to wait on [some person] to make that decision
Delaying decisions delay the project, this consequence must be accepted
No escalation plan - could put you in a holding pattern indefinitely
Its the right thing to do but [some excuse masquerading as pragmatism]
Not looking at long term consequences - lack of systems thinking
Lack of courage our team does not feel comfortable saying things that rock the boat
We just need to lock down [some specification] and then we can
Some portions of the specification, certainly. The entirety no
We do not know what we do not know, requires specification changes, no need to waste time with reworking the specification
Just this one time lets [some cut corner] and then well fix it, hopefully
This become habit we will do this for any modicum of pressure
Those not technically oriented wil challenge when you want to resort to no corner cutting
People will forget what correct looks like because we now have many ways to do this
The path of least resistance becomes common even i this is not the best approach
We need to do this to close [one deal]. But Im sure it will apply elsewhere
See the prior items
Oh Ill just do this on the side. That way it will not be micromanaged
No communication with other team members
Fit issues
Micromanagement is a problem also - that would be what should be solved -your team does not believe they can make decisions and take the initiative. You paid for talent then let it waste away.
Oh, this doesnt need UX [or QA, Ops, etc.]
You will likely find out later that the product does not meet the customer needs
Poor quality in the field comes with rework and replacement in the field, litigation, service costs, reputation impact
Not including operations means we may not have the ability to build this thing and ship to customer or deploy
So we have this [side project]...can you attend the meeting to [plan in secret]?
Missing key players - unvetted assumptions, few possible ways to approach (ideation)
Trust issues - dont want to share for whatever reason
Distraction of workforce if this person should be working on another project
Oh we cant risk [trying some valuable goal]...
No risk = no reward
Exploration need not be risky - could find an easy low risk way to explore
Eliminating learning opportunity for team members
No desire for innovation which comes from this type of exploration
Oh you cant test [some feature] because [some perceived limitation]
Testing incremental iterations provides feedback to the developers
It is possible to test some portions that work to learn about that work
Configuration Management (via release notes) provides the map of features able to be tested
Waiting for all functions available to start testing means finding bugs up against the launch deadline
You are destroying the iterative and incremental model of working
We need individual owners otherwise [some inability to track/punish]
Problem when you punish - trust issues in the organization
One perspective often does not provide a true view of the field
Well, were unique because [some non-unique challenge]
Unique or not unique, there is likely a solution that will meet the objective if you explore, test and learn. Otherwise you are stuck in this morass for the rest of your days
No way to get better living with the limitations without exploration
This is too big for one sprint, so well do phase one now and .
Im pretty sure I can represent the customer in this case
Not sure any individual not a customer is in a position to actually
Myopic one perspective
Likely discovered when the product goes to the customer things that were missed resulting in rework
Gets in the habit of making the call for the customer rather than asking the customer
[Some effort] is too big to fail. We need to get this right
Still requires attacking incrementally (how do you eat an elephant)
Building all, means we find all of the errors and poor decisions late or at the end
Requires rework - and late with no time to adequately address
We need some quick wins because [normal wins take too long]
Then find a way to improve the normal wins rate
Work on your corporate discipline - delayed gratification
Eroded the corporate discipline and any repeat-ability
I think we can parallelize [two related efforts]...
If these are to be sequential there is risk of rework of the depending task when the preceding task does not deliver exactly as expected (see compounding impact of risk)
Delays delivery of the iteration
And then [some other group] can maintain it, right?
There was learning in the development of the product that only the group doing will have
Communications challenges with the transition - what should we tell and to whom
Better to keep some members of the maintaining group involved during development if this must be a different group
Problems with the ability to maintain, constant interaction with the developers
Ultimately poor post development support