Desktop version

Home arrow Management

  • Increase font
  • Decrease font

<<   CONTENTS   >>

Appendix 1: Learning and Organization Development Checklist

This is a brainstormed check list of the things that get in the way of the development of our organization.

■ Reduce required billable hours ratio (80% or even less)

■ Make time for learning and spreading what is learned

■ Gamify the work and learning opportunities

■ Encourage exploration by the individual and the team

■ Each team member shares their expertise

■ Encourage lateral (silo to silo) communication

■ Develop communities of practice as a resource to the organization (not a way of usurping the organization)

■ Integrate learning and improvement objectives in the daily work

■ Schedule recurring point to share the learning of all the department

■ Consider online database with searchable metadata tags

■ Job rotations, specifically to interfacing or depending departments

■ Special assignments for individuals to develop new skills / knowledge the organization will need in the near-term future

■ A career development plan for team members that is used act to as if learning and improvement matter create an environment that does not punish failure — but ensures exploration of what happened and why. Baseline expected analytical / statistical tools for the department and team members

■ Act as if learning and improvement matter, do not pay lip service

■ Create an environment that does not punish failure — but ensures exploration of what happened and why. Failure is not a good thing, nor a bad thing.

■ Baseline expected analytical / statistical tools for the department and team members

■ Identify teachers / coaches within the team to develop these skills throughout the team

■ Create knowledge sharing networks for dissemination of learning

■ Develop a culture of questioning. It is okay to say I don’t know

■ Those that know should not tell, but coach, ask questions, point to places to look and evoke answers from within the student

■ The work is learning. Encourage learning beyond the daily, and present activities of the job

■ Set up a library or virtual library for the organization - of books and other material that applies to the organization

■ Frequent lunch and learns

■ Frequent work reviews / critiques a la retrospectives

■ Mental or thought experiments

■ Develop an environment that grows a common lexicon and shared mental models

■ Prioritize learning, slow down to allow it to happen, include learning in work estimates (time & cost)

■ Team members teach team members

■ Abolish sloganeering

■ Develop corporate culture that values learning and sharing

■ Managers are teachers and coaches

■ Embrace continuous learning in the culture

■ Organization subsidized or reimbursement of education - degrees, no degrees, certifications

■ 360-degree feedback for employee evaluation

■ Display organization objectives and associated metrics for all to see, monitors or other physical boards

■ Encourage learning beyond the daily, and present activities of the job

■ Develop and implement a mission, vision, and value statement that is actually supported at all levels of the organization.

Appendix 2: Clues! Signals!

A2.1 Overview

The material below is the result of a collaboration with John Cutler, known as @ JohnCuttefish on Twitter. The document started out as a list posed by him, and he was looking for people to comment on it. Upon seeing his list, a bunch of ideas came into my head, and I started adding to it on the Google Drive location. As fast as I was addiing content he was approving of the updates. To me this is another great example of how people can connect to make interesting and perhaps helpful things.

■ 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 ...

- Doubled up when things should be consecutive puts depending tasks at risk of rework and unable to adapt to actual outcome

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

■ 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

■ 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. Not the entirety.
  • - 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 let’s [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 will 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 if 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 nor 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 repeatability
  • - 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 it 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
<<   CONTENTS   >>

Related topics