This chapter is from the book
This chapter is from the book
This chapter is from the book
Internal Mentee
There are some important areas that you will need to consider when selecting your Internal Mentees—mentors-in-training. Internal mentees are resources that are typically employees who will be actively pursuing knowledge transfer from the external mentor. The goal of the knowledge transfer is for the mentee to possess the required skills/characteristics, behavior, and competencies in order to be considered qualified to perform the mentoring solo.
Skills and Experience
The Internal Mentor must have a solid knowledge of the RUP discipline they are specialized in, as well as an overarching knowledge of the entire RUP. However, they must not be a RUP purist, where they insist that work should be done because it is in RUP and, therefore, the teams they are mentoring must do regardless of whether any value is added (i.e., a paper-producing methodology approach).
Candidates for the Internal Mentor should have as much software development experience as possible in all facets of software development (i.e., writing requirements, slinging code, managing a project, being an analyst, etc.—the more and varied experience a candidate has, the better). The Internal Mentor, having significant software development experience, must not be so rigid as to insist on adhering to their old ways of developing software. Instead, the Internal Mentor should have a sufficiently open mind to accept and embrace new approaches to developing software.
The Internal Mentor should have social skills that are good enough to entice project practitioners to want to follow his or her recommendations, as opposed to engaging the project team in a confrontational manner to force those recommendations upon them.
Behavior
The single most important logistical task is that the Internal Mentor should have enough time and capacity to shadow the External Mentor 100% of the time when the External Mentor is on site. The Internal Mentor should have a natural leadership style. The ideal candidate has the respect of project teams because of his or her experience, decision-making skills, and knowledge.
The Internal Mentor should be encouraged to ask questions of the External Mentor and challenge recommendations the External Mentor makes to ensure that the External Mentor provides ample justification for his or her recommendations. This will help the Internal Mentor provide justifications when he or she makes recommendations to project groups later on.
The Internal Mentor should strike an optimal tradeoff between following the tenants of RUP on the one hand and ensuring that the project productivity does not drastically decrease on the other (some decrease is going to happen, which must be viewed as an investment). He or she will be the steward of the practices that project teams are expected to follow. He or she should ensure consistency across the enterprise in the manner in which these practices are followed. If the mentoring team observes that, despite the Internal Mentor's best efforts, a project team is failing or refusing to consistently follow common software development practices, the Internal Mentor should know whom to contact to escalate within the management chain (the champion of the initiative or discipline) such a problem.
The Internal Mentor should communicate his or her knowledge in a consistent manner from project team to project team as well, being in sync with the other discipline mentors (i.e., if the Requirements Mentor is giving recommendations to sparingly use <<extends>> and recommends the use of <<includes>>, that should be consistent from team to team). Additionally, the Internal Mentor should keep his or her mentor brethren such as the Project Management Mentor in a consistent message.
The Internal Mentor should be able to distinguish between substantive differences and cosmetic differences from project to project. He or she should discourage the former and countenance the latter. For example, listing of the data elements should include element name, required or not, default values, and any logical validations or notes—period. All use cases must have this level of information. However, including the contents of business rules within the narrative of the plain text vs. including them in a separate table within the text should be an acceptable difference in the "style" of the use case, and one that the Internal Mentor should be able to distinguish between.
Competencies to Be a "Solo" Mentor
The final step in "certifying" that an Internal Mentee is ready to go it alone and become a mentor is a key milestone. The Internal Mentees should be able to demonstrate competencies and pass tests that validate that they are ready to begin solo mentoring.
Each discipline's mentees will need to have competencies, or tests, that they must pass for the External Mentor to approve the transition to a Solo Mentor. I have included two examples: one for the requirements discipline and one for the project management discipline. These two examples should provide the insight into the types of criteria and tests that you will need to create for your specific environment.
Requirements Mentor
The Internal Requirements Mentee is required to pass the following two tests before he/she can be considered qualified to perform the mentoring solo and be considered a mentor:
-
The Internal Mentor must be able to independently review system use cases and produce comments that satisfy the criteria set forth by the External Mentor. No major shortfalls in the review should be discovered by the External Mentor. The review should point to the best practices as applicable with sufficient justification for the review comments. The review comments must be consistent with the style, content, and level of detail of the External Mentor.
Test #1: The External and the Internal Mentor shall independently review three project use cases. 90% of the comments from both have to essentially agree.
-
The Internal Mentor must be able to lead requirements sessions/workshops of identifying and describing use cases, at first with the supervision of the External Mentor, and later with little or no assistance from the External Mentor.
Test #2: The External Mentor shall passively observe the Internal Mentor lead two requirements sessions. No more than one question per hour of session time shall arise that the Internal Mentor cannot answer by him or herself (i.e., without the help of the External Mentor).
Project Management Mentor
The Internal Mentor must demonstrate the following competencies to be considered self-sufficient and become a Solo Mentor:
-
The Internal Mentor must be able to independently review and produce comments that satisfy the criteria set forth by the External Mentor in the following key RUP Project Management Discipline artifacts. Table 9-3 provides samples of the type of key principles you should consider.
Table 9-3. Key Project Management Artifacts
Artifact
Comments
Vision Document
Provide feedback on Inception and Elaboration versions for at least one, but preferably two, projects.
Software Development Plan
Provide feedback on the plan at all stages of the RUP lifecycle on at least one project.
Iteration Plan
Provide feedback on two iteration plans for each phase of the RUP lifecycle on at least one project.
Metrics Plan
Provide feedback on one software development Metrics plan in the Elaboration and Construction phases.
Risk Plan
Provide feedback on the Risk plan during the Inception and Elaboration phases for at least one project.
Business Case
Provide feedback on business case in the Inception phase of at least one project.
Test #1: The External and the Internal Mentor shall independently review the Project Management artifacts from three projects. 90% of the comments from both have to essentially agree.
-
The Internal Mentor must be able to lead and co-facilitate the following sessions/workshops at first with the supervision of the External Mentor, and later with little or no assistance from the External Mentor. Table 9-4 provides samples of the type of key sessions you should consider.
Table 9-4. Key Project Management Sessions
Session
Comments
RUP Project Kick-Off
Co-facilitated with the External Project Management Mentor.
LCO, LCA, and IOC Milestone Review Session
Co-facilitated with the External Project Management Mentor.
Inception, Elaboration, and Construction Phase Estimation Sessions
Co-facilitated with the External Project Management Mentor with active involvement from other project team leads.
Metrics Review
Enable the External Project Management Mentor to understand how to interpret key project progress and quality metrics at various points in the project lifecycle.
Change Control Board Session
Co-facilitated with the External Project Management Mentor.
Test #2: The External Mentor shall passively observe the Internal Mentor lead the preceding sessions. No more than two–three questions per hour of session time shall arise that the Internal Mentor cannot answer by him or herself (i.e., without the help of the External Mentor).
-
The Internal Mentor should be able to be conversant in a number of key principles of RUP project management discipline, RUP principles, and general project management concepts. Table 9-5 provides samples of the type of key principles you should consider.
Table 9-5. Key Project Management Principles
The Principles of Modern Software Management
Comments
Architecture-First Approach
Explain the basic premise, how it differs from a requirements first approach, and what the benefits are.
Iterative Development
Explain the basic premise, how it differs from a single pass waterfall, and what the benefits are.
Component-Based Development
Explain the basic premise, how it differs from a line of code mentality, and what the benefits are.
Change Management Environment
Discuss concurrent workflows and project baselines.
Round-Trip Engineering
Explain the basic premise and what the benefits are.
Model-Based Notation
Explain the basic premise, how it differs from a document/specification approach, and what the benefits are.
Objective Quality Control
Explain the basic premise and what the benefits are.
Demonstration-Based Approach
Explain the basic premise and what the benefits are.
Evolving Levels of Detail
Explain the basic premise, how this differs from a traditional "plan-driven approach," and what the benefits are.
Configurable Process
Explain the basic premise and what the benefits are.
Test #3: The Internal Mentor shall discuss these key concepts at length with the External Mentor. The External Mentor will provide feedback that the Internal Mentor has sufficient understanding and ability to communicate the key message of these concepts and the benefits they provide.
Discipline Specific to Full "RUP" Mentor
Up to this point, the focus has been on mentors who specialize in a specific discipline. This is absolutely needed and will continue to be needed throughout the implementation timeline and beyond. Providing mentoring for RUP techniques such as describing fully detailed use cases takes a person who is highly skilled in that specific technique. This expertise will not diminish, but for your most senior mentors, they will need to begin transitioning into what I call "Full RUP Mentors."
In this transition, the senior discipline specific mentor is "cross-mentored" by the other External Mentors. The initial focus should be on the key disciplines you have identified in your original assessment and have been managing to all along. Figure 9-4 represents the "certified" Internal Requirements Mentor becoming a "Full RUP Mentee." The External Mentors begin the process of transferring the knowledge from the other key disciplines. This step, evolving the overall RUP knowledge, helps your Internal Mentors realize in actual practice how each of the other disciplines are tied to theirs in reality on actual projects. Your Internal Mentors will become much better versed in the entire RUP software development lifecycle.
)
Figure 9-4 Program-level mentoring model