Question

Ron is a topnotch programmer with over twenty years experience. He prides himself on his ability to solve any problem, and produce great code. He was appointed to a project team led by LaVerne, a young analyst, given her first chance at a lead role. She gave him some DFD diagrams (that she worked very hard to do), and he became very irritated. Ron told her that she had wasted her time and his. DFD diagrams don't show what the system has to do in detail, like physical model flowcharts. Furthermore Ron tells her he doesn't need (or want) diagrams of any kind because he writes "self-documenting code". At this company, Ron is considered a genius. How should LaVerne handle this?

Answer 1

LaVerne is really in a difficult situation. As a team lead, she is ultimately responsible for maintaining the quality standards and time schedules in system development and at the same time responsible for ensuring the following:

· Any issues or problems within the team and to make sure they are dealt with appropriately

· Team is always working on the highest priority work and is aware of the priority

· The team is self-organizing so that we take collective responsibility for the work

· The team is adhering to the principles and practices the team is committed to do work efficiently and effectively at the highest quality standards

· Ensure the team is collaborating closely

· The progress of work the team is undertaking

· Ensure all team members turn up promptly to team meetings

As a first time team lead, LaVerne must be first clear about her roles and responsibilities. She must be able to identify and respect the individual strengths, weaknesses, technical expertise and self-learning ability of her team members. She must also clearly track the performance of each individual member in terms of quality of output, quantity of work produced, innovativeness and other relevant parameters. In the feedback sessions, she must share honest feedback with the team members, including things they did well, things that didn’t go well and strategies for improvement.

With this this strategies in mind, LaVerne will be able to solve the current problem very well. She must first respect the fact that Ron is a topnotch programmer with long technical experience and problem solving ability to solve any problem, and produce great code with quality standards. From the odd behavior of Rom in declaring that ‘diagrams in system development are just waste of time’ it is now clear to LaVerne that Ron is a tough guy with little flexibility. The best thing LaVerne could do is use Rom’s abilities maximum by assigning him to coding, testing and other problem solving activities. However, LaVerne must clearly communicate to Ron and other team members during the feedback and review meetings that the developing physical and logical DFD diagrams are integral part of the system development that can capture the system components and processes, system environment and the information flow within and outside the system. Standing from her own experience, LaVerne must clearly explain to the team members that use of DFDs have several advantages and that a simple detailed Flowchart or well-documented code cannot capture the system perspective of the project as they fail to capture system components, its environment, and the data flow within and outside the system. She must clearly highlight the advantages of using DFDs like:

· DFDs easily capture system components, its environment and information flow that would be hard to describe in a chunk of text.

· DFDs can be used to map out an existing system and to plan out a new efficient system for implementation.

· Visualizing of elements helps identify inefficiencies and produce the best possible system.

· DFDs are useful in describing the boundaries of the system.

· DFDs can provide a detailed representation of system components.

· DFDs can act as system documentation which would helpful in future expansion and maintenance of the system.

· DFDs are can act as communication tool for both technical and non-technical users

· DFDs are really useful in system analysis, designing, decision making, and system maintenance.

If the team members are not educated on the need for maintaining proper system documentation and including them in the system deliverables, the junior programmers will get the impression that the system development just building the right code. LaVerne must also be assertive in stating that Ron must change his perception on DFDs and otherwise, the junior programmers, taking him as a role model, may get the wrong impression that DFDs are just waste of time, which could hamper the chance making them great programmers.