Clues! Signals!

This is the result of a collaboration initiated by John Cutler on Twitter with Jon M Quigley. 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 don’t 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 we’re waiting on [some blocker], let’s 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)
• It’s 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 don’t 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 doesn’t 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
• We’ll 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
• It’s 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 we’ll 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 I’m sure it will apply elsewhere……
• See the prior items
• Oh I’ll 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 doesn’t 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 - don’t want to share for whatever reason
• Distraction of workforce if this person should be working on another project
• Oh we can’t 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 can’t 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, we’re 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 we’ll do phase one now and….
• I’m 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