Clues! Signals!

Below is the result of a collaboration with John Cutler. He posted a document on Google Docs, and I liked the outline so much I felt compelled to post my thoughts In fact, it was surreal adding my contents to the Google docs and John coincidentally showed up on line, at the same time and was approving my contribution as I was writing it!  I had to write fast to stay ahead of him. I wrote the top level part of the outline, making it easy to think about that topic and what can and often does go wrong.   It was such an interesting collaboration, unscripted, accidental, and fun.  We had talked about making a short video, teasing out a few of the more interesting ones and talking about them, but the new father has plenty of other more important work.  In  fact, the collaboration was so easy, it turns out making a decent outline in WordPress is the most difficult part.  If anybody can point me to accurate text on how to make an outline in WordPress blog, I am grateful.  Everything below this paragraph is the result of the collaboration.  We hope you enjoy.

Pay attention.  There may be an an opportunity for improvement…

1.)   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.

2.)   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.

3.)   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).

4.)   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 no know the laws of diminishing returns).

5.)   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 take off).
• 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.

6.)   If we bundle these things together we will get [some efficiency]

• Over 80% capacity we are looking at larger delays for small difficulties –  queuing theory.

7.)   We don’t all need to be in the room for [some decision]

• Different perspectives help uncover:
  • Un-vetted 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.

7.)  We can “get ahead of it” by [a series of hand-offs]

• 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).

8.)   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.

9.)   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.

10.)   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.

11.)   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.

12.)   It’s the right the 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”.

13.)   We just need to “lock down” [some specification] and then we can……

• Some portions of the specification, certainly. The entirety no, it really depends on how these specification elements are connected.
• We do not know what we do not know, requires specification changes, no need to waste time with reworking the specification.

14.)   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.

15.)   We need to do this to close [one deal]. But I’m sure it will apply elsewhere……

• See the prior items.

16.)    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.

17.)   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.

18.)   So we have this [side project]…can you attend the meeting to [plan in secret]?

• Missing key players – un-vetted assumptions, few possible ways to approach (idea generation).
• Trust issues – don’t want to share for whatever reason.
• Distraction of workforce if this person should be working on another project.

19.)   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.

20.)   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.

21.)   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.

22.)   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.

23.)   This is too big for one sprint, so we’ll do phase one now and….

24.)   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.

25.)  [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.

26.)  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.

27.)  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.

28.)  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.