Improving your Processes and Teams
Up until this point, this book has focused on how to manage projects with Microsoft Visual Studio Team System. Managing projects, however, also involves fine-tuning the way you develop software so that it can adapt to changing teams, technologies, tools, and processes. This chapter discusses that process of fine-tuning, which involves understanding and reflecting upon lessons learned-those best practices your team will naturally uncover as they develop software. The goal, then, is not only having great processes but also learning how to adjust those processes and practices over time so that your organization can move from proficiency in delivery to proficiency in adaptation. In this chapter, we will discuss how to turn the learning and adapting process into something much more deliberate and controlled, which will help identify the most valuable aspects of change for your organization and teams.
Harvesting Lessons Learned
At the end of your projects, you conduct a project review in which your team discusses their accomplishments as well as in what areas they could have done a better job. You work with them to complete the sentence, “If I had to do it all over again, I’d change….” This exercise has the potential to be extremely beneficial to everyone on the team; however, in most cases, these meetings gather only subjective feedback and do not address essential lessons or how these lessons can be integrated into the next project. How can you be sure that the information gathered during this meeting will increase the success of your next project? You will have a better chance if you keep the same team together, and this team works with the same technology and business problem. But what if you want to ensure that these best practices are adopted by all teams within an organization? If you are not interested in larger-scale process improvement initiatives, harvesting best practices from your projects is a good place to start initiating change. You can use a few techniques to make this process more concrete- techniques that allow you to extract more value from the review process and more easily integrate your lessons learned into project delivery. Review your projects throughout their lives rather than only at their completion. If you wait until your projects are finished before you review them, you can affect only future projects. Try to perform project reviews in the transition between project iterations or phases if you can so that you can integrate any changes to your software development practices before the start of the next iteration.
When you are conducting a review session with your team, treat the lessons you learn as project requirements so that they can be expressed, recorded, tracked, and implemented as any other project-level requirement would be. Using this method ensures that you can assign responsibility for these new best practices and gives you the opportunity to integrate resulting task assignments into your project schedule.
Of course, you and your team must evaluate the impact of each of the lessons learned you want to gradually work into your project, because they could cause your project more harm than good. Just like any change to requirements during a project, integrating lessons learned may create a ripple of changes throughout your project. Some of these changes may increase your team’s efficiency, but some of them may have the exact opposite effect. For example, let’s say that your team is making a large number of manual code changes because of significant code revision. Halfway through the project, you realize that using a code generation engine to generate your business object code would have been a better choice. Switching to a code generation engine halfway through a project, however, is probably not a best practice because it will introduce a great deal of rework and significant restructuring of your project’s source code, and you would doubtfully see any benefit from this change in the current project. With this said, you must evaluate every change you introduce to your project, including those changes that represent best practices. Don’t forget that if you change how your team works, you will need to revisit all your estimates to ensure they all still make sense.
Improving Your Software Development Process Over Time
Instead of improving your development processes one project at a time, you may want to create a process improvement initiative that exists independently of any specific project. Of course, this is not a new concept; it has been happily happening within Project Management Offices (PMOs) for decades. Again, CMMI provides an excellent roadmap for you to follow if you are a large organization looking to gradually improve your processes. However, many organizations do not want to use CMMI because it has a very steep learning curve and can be overly complex and structured.
| Note | For more information about CMMI, refer to Appendix A, “Capability Maturity Model Integration (CMMI).” |
Many organizations want to improve their software development processes without the complexity and ceremony of CMMI-based improvement processes. These organizations want to start with a structured yet common-sense approach to their development processes but might be left with a “there are lots of things I can improve upon, but I don’t know where to start” feeling. This book introduces a process improvement framework that is less complex than CMMI and relies on a more chaordic (chaotic, yet organized) approach to process improvement.
We are not discouraging the use of CMMI in any way; rather, we are proposing an alternative method to process improvement that is easier to adopt yet inspired by many aspects of CMMI.
A Lightweight Process Improvement Framework
A key to developing a great organization is to build a framework and cultivate a mindset on which all decisions are based. The same is true for a process improvement framework. The following sections present some of the critical mindsets important to the success of any process improvement process.
Focus on the Goal Improving your software development processes is much more like a never-ending journey than it is a destination. But never-ending journeys do not seem very exciting if there aren’t some specific stops, and for this reason, process improvement should identify specific goals your team can achieve along its way. This means that process improvement is less about doing work than it is about accomplishing goals. When working with your team to plan out process improvements, it is important to first identify team goals such as being able to measure the quality of software as it compares to the velocity of your team. How you choose to accomplish these goals is secondary to the goals themselves. In fact, from the perspective of the team, goals should be absolute reference points, and you should provide whatever flexibility is needed to achieve them; ultimately, these goals are crucial to process improvement, not the tasks you complete to achieve them.
Get Support from the Business Absolutely no process improvement initiative can be successful without the full support of the entire organization. Process improvement activities may initially take team members away from their primary responsibilities, because members will need to plan and execute process improvement–related activities. Team members’ work will be slowed as a result, which could have a negative effect on other areas of the business. Process improvement cannot happen overnight, nor is it accidental, and for these reasons, the entire organization must realize that effort, time, and resources will be required to produce long-lasting results. It also should not happen in a vacuum or focus on the needs of a particular group within the organization such as software developers and testers. All process improvement activities must support the needs of the business from a holistic perspective. The plans and activities generated as a result of process improvement must also reflect the constraints of the organization, which will likely include allocations of time, budget, resources, existing commitments, and schedules. The success of the process improvement exercise should not be measured by the increased efficiency of your software engineering teams but by the value those efficiencies bring to the entire organization.
Embrace Change Such as it is with any Agile process, the lightweight improvement scenario should expect and adapt to change. When planning your process improvement roadmap, ensure that the team understands that you will need to revisit the plan after every phase of the process to allow for necessary adjustments because of changing technology, teams, or business conditions.
Strive to Achieve Success When planning for process improvement goals, it is very easy to try to accomplish more than is possible. Always make each goal easily achievable every step of the way, especially in the beginning of the process improvement process when it might be tough to build momentum and acceptance from your team. Otherwise, you risk discouraging team members or the organization. Never risk success. If you or your team feels that a particular goal is unrealistic, rethink your objectives and your plan because failure in any respect will have a greater impact on your team than success. With every team achievement, celebrate with your entire team and ensure that each success resonates throughout the organization.
Work as a Team of Peers Process improvement will affect your entire team and probably the entire organization in one way or another. The team you select to help guide and implement process improvement activities must realize that everyone is working for a common set of goals. They must work together as equals to bring about change. A business analyst’s process improvement should not take precedence over the needs of developers and testers. In a similar way, developers have no dominion over the sales and account management teams. Everyone’s opinion must be heard and count equally and objectively.
Treat Process Improvement as a Project Process improvement activities should be managed similarly to other types of projects in your organization. Each process improvement project should have a specified set of roles and be managed by a project manager. Projects should have budgets, schedules, resources, deliverables, plans, and people assigned to them. Your organization must consider process improvement projects when considering resource management and work allocations across all employees and projects. If you ensure that a process improvement project is treated in the same way as every other project in your organization, you minimize the risk that process improvement activities will be treated as higher priorities than other projects and thus lead to ongoing organizational change.
Learn from the Experience of Others You are not alone. Many organizations have either gone through or are going through process improvement and will be more than willing to share their experiences. There are many proven practices that are available to you regarding ways to improve your software development practices. Empower your entire team to search for reference material or advice from others. Consider hiring an outside organization that specializes in process improvement to jump start and guide your team’s activities, help get everyone into the right mindset, and act as a coach as the process improvement practice grows and continues.
 |
In Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Prentice Hall PTR, 2003), David Anderson suggests that the Software Engineering Institute’s Software Capability Maturity Model (CMM) is inadequate for Agile approaches to project management and conformance to quality as well as human factors. From this perspective, Anderson introduced a maturity model that is more aligned with all types of software development business, which he calls The Learning Organization Maturity Model. This new maturity model is summarized in Table 6-1.
| Stage | Capability |
|---|---|
| Stage 0 | Analysis Ability Decompose system input into basic units of measurement. |
| Stage 1 | End-to-End Traceability Implement system for capturing and monitoring measurements. |
| Stage 2 | Stabilize System Metrics Demonstrate basic statistical process control, and show that system is stable against a target and within a tolerance. |
| Stage 3 | System Thinking and a Learning Organization Focus on continuous improvement. |
| Stage 4 | Anticipated ROI and the Failure Tolerant Organization Encourage risk taking. Focus on throughput of process, not production quantity. |
Open table as spreadsheet As you can see, like CMMI, this model also has five levels and is compatible with any Agile method or rigorous software methodology.
|
Overview of the LPI Framework
The Lightweight Process Improvement (LPI) framework suggested by this book provides simple-to-use guidelines you can use to begin the ongoing discipline of perpetual process improvement. LPI’s goal is to allow you to begin process improvement with minimal effort and is designed to produce value to your entire team early and often. LPI takes an iterative approach whereby iterations are further grouped into one of four phases: Initiate, Plan, Execute, and Review. These phases are very similar to the PMBOK-inspired practices already discussed throughout this book. The LPI framework promotes a continual life cycle model, meaning that after the review phase of the life cycle, the LPI project continues by entering the planning phase once again, as shown in Figure 6-1.
Figure 6-1: The LPI Framework life cycle
Similar to the Initiate process group specified by PMBOK, the primary goal of LPI’s Initiate phase is to align the team members and business sponsors so they can produce a project charter document and hold a team kickoff event. The project manager is responsible for most of the work and deliverables produced during the Initiate phase and works with the project sponsors to establish a clear business case for process improvement, which typically evolves from the need to increase productivity, reduce waste, provide better estimates, be better positioned for innovation, and ultimately increase profit and profit-earning potential.
The Plan phase of LPI begins with an assessment that scrutinizes the strengths, weaknesses, threats, and improvement opportunities of the existing software development processes. It is in this phase that you must continually reinforce the needs of the business to help align your team. To provide input to the assessment, you must involve all the key members from all major disciplines including product managers, project managers, software architects, software developers, software testers, and business analysts. The assessment phase should quantify your current state and identify a desired state to help provide direction and focus for planning activities. After the assessment is complete, your team uses assessment results to construct a goal-focused action plan that will guide it throughout the process improvement life cycle. The resulting plan should take into account different perspectives of the improvement process such as process management, project management, engineering, and support.
During the Execution phase, the team will work together to achieve the goals outlined in the Plan phase. This phase is similar to the traditional execution and monitoring in which the team works together, and it requires the same level of project management and governance as a non-process improvement project. The Execution phase should be broken down into a series of iterations to ensure that the team has time to regularly synchronize and adjust to changing circumstances or priorities. Iterations will also help to focus the team’s delivery cycle and allow for execution milestones to be created. Each process improvement goal achieved during the Execution phase needs to be clearly identified and celebrated.
The Review phase begins when the final iteration of the Execution phase ends. During this phase, you and your team will take time to reflect on the results of the Execution phase. Did your team meet all its goals? Did you encounter any major issues that could have been prevented with better planning? What were your accomplishments? What are some of the outstanding goals you would like to focus on next? Were there any lessons learned during the execution phase that will make subsequent phases more successful? The results of the Review phase will be used as inputs to the Plan phase discussed earlier.
Continual improvement represents moving from the Review phase back to the Plan phase of the LPI framework and is usually required, because rarely is a single pass through the LPI life cycle enough to cause your software development practices to mature. You must embrace process improvement as an ongoing repetitive process. Process improvement should be like the heartbeat of a software development organization, continually pumping new life and vitality into it as it grows and matures.
Roles Involved with the LPI Framework
Process improvement needs the dedication of people to be successful. Rarely can a single individual effectively guide process improvement across all aspects of the software development skills spectrum. Recognize that for the most part, most of your team members already have a great deal of understanding of and insight into how certain processes can be improved. For this reason, successful processes for process improvement involve a wide breadth of individuals from differing disciplines. Table 6-2 summarizes the roles and responsibilities on a LPIbased project.
| Role | Responsibilities |
|---|---|
| Business Sponsor | Clearly articulate business objectives of the process improvement initiative. Establish project constraints such as budget, time, resources, and people. |
| Project Management | Facilitate all aspects of an LPI-based project. Gather business objectives and project constraints. Produce the project charter. Manage timelines, budget, resource allocation, and commitment to work. |
| Team Leads | Act as representatives of their teams or divisions during all phases of the project. Gather information that will be used during the assessment of current processes from their team. Contribute to the process improvement plan. Lead activities specified in the process improvement plan to help the team reach their goals. |
| Remainder of the team: Software and IT Architects Developers Development Managers Build Engineers Testers Test Managers Quality of Service Specialists Release Managers Product Managers Business Analysts | Provide insight into the current software engineering practices and tools. Carry out assigned tasks specified by the process improvement plan. Provide continual feedback and open opinion on the LPI project. |
| Process Improvement Coach(Optional) | This role is typically played by an external consultant who has extensive experience with helping software development teams and organizations improve their processes. Plays the role of a facilitator and coach throughout the duration of the process improvement project. |
|
Finding outstanding people should be the primary focus of any company. The “First Who…Then What” concept is promoted by Jim Collins in Good To Great: Why Some Companies Make the Leap...and Others Don’t (HarperCollins Publishing Inc., 2001)
Collins argues that companies that progress from good to great recognize that their biggest constraint is their ability to attract and keep enough of the right people, beyond constraints that might be imposed by markets, technology, competition, or products. Collins goes on to say that organizations should put their best people on the biggest opportunities, not the biggest problems. It’s also been well accepted that some software developers are higher producers than others-best-of-breed developers have been documented to outperform average developers by 10 to 20 times (see Sackman, Erikson, and Grant: “Exploratory Experimental Studies Comparing Online and Offline Programming Performance,” Communications of the ACM, January 1968). So you should be extremely diligent about how you compose every team, including your process improvement team.
|
Initiating Process Improvement
The Initiate phase of the LPI framework is very similar to Initiating activities specified by PMBOK. In this phase, the focus is on establishing the scope and objectives of the process improvement project by trying to establish the business value that can be achieved as a result of the project. The Initiate phase also establishes the constraints of the project that must be taken into account during ongoing project planning such as budget, time, and level of team commitment. For example, the organizational sponsor for the project may specify that the first phase of process improvement should take place during the months of the year the business is least busy. It could also specify that employees involved in the process improvement project can spend no more than 25 percent of their time over a given month on process improvement activities. The project manager creates a project charter to capture the business objectives and constraints on which the project will focus, helping to establish a clear set of success criteria the project will target.
During this phase, the project team is also selected from different functional areas across the organization such as project managers, software and IT architects, developers, development managers, build engineers, testers, test managers, quality of service specialists, release managers, and business analysts. The participants of this team will be responsible for providing guidance and feedback and for participating in process improvement workshops and reviews. Some team members may also be responsible for collecting information such as current process definitions or existing process metrics that will be used during the planning phase. This phase will culminate with a kickoff to align the entire project team with the project charter produced during this phase. During this meeting, the project manager is responsible for educating the team about the structure of the project and expected commitment and responsibilities. This phase is further summarized in Table 6-3.
| When can you begin? | Commitment obtained from the organization to move forward with the initiative. Budget allocated. Time set aside for team members on existing projects. |
| How do you know when you have finished? | Project charter complete and accepted. Team assigned and time allocated. Kickoff meeting held. |
| Typical activities | Assign a project manager. Meet with project stakeholders to gather business objectives and constraints. Create project charter document. Form team. Schedule kickoff meeting. |
| Deliverables | Project charter. |
| Note | You may want to consider using Visual Studio Team System to help manage and track the process improvement project just as you would any other software development project. |
Planning Process Improvement
Before you can begin any planning activities, you need to first assess where you are today. A simple way that you can gather this information is through a standard Strengths, Weaknesses, Opportunities, Threats (SWOT) Analysis. One of the most effective ways you can perform a SWOT analysis with your team is through a series of facilitated workshops. In these workshops, your entire process improvement team comes together to analyze how they develop software by identifying what they do well (strengths), practices that the team does not perform well (weaknesses), areas that they can improve upon (opportunities), and aspects of their environment that may prevent them from achieving their goals of process improvement (threats). Prior to the SWOT workshop, your team should spend some time creating an inventory of the processes and tools currently used to create software. This information could include a list of tools developers and testers use to perform their job, bug-tracking tools and processes, and any existing process-related documentation or document templates.
The SWOT workshops should be very focused and assess each aspect of the development process individually. For example, you might choose to categorize how your team develops software into the following: Program Management, Architecture, Development, Testing, Release and Operations, and User Experience. To stay focused, you should conduct a SWOT analysis on each of these categories individually. Each time you identify a strength, weakness, opportunity, or threat, your team should also assign an associated level of impact and priority. Using this technique will allow you to help better quantify your results and help drive decisions and direction. For example, Table 6-4 demonstrates a number of weaknesses and their relative impact and priority.
| Impact | Area | Description |
|---|---|---|
| High | Project Management | Customers are not involved throughout the project life cycle. |
| Medium | Project Management | Not all development work performed by the team can be traced back to requirements. |
| Medium | Project Management | Risk, not activity, managed throughout the project. |
| Medium | User Experience | No formal training in the design of modern user interface designs. |
| High | Testing | No automated build process. |
| High | Testing | Not enough test cases created to cover all known requirements. |
| High | Testing | Lack of automated testing tools. |
| Tip | You can use a numeric scale (for example from 1–9) to represent impact if you prefer because this will give a greater ability to fine-tune SWOT prioritization. |
SWOT workshops such as these have the possibility of getting out of control. To compensate for this, ensure that your team members understand that they are there to gain perspective on the current software development model, not to engage in heated debate or establish blame. Meetings should last no longer than two hours to ensure focus and productivity, and a facilitator needs to be on hand to help maintain that focus. Also, prior to each SWOT workshop, consider allowing time for your team members to harvest their own thoughts regarding the SWOT analysis so that their time in the workshop is as fruitful as possible.
When you have identified and ranked all strengths, weaknesses, opportunities, and threats, the next step is to decide on actions for each issue. For example, if one of the weaknesses you identified during your SWOT workshop was that your team lacked automated testing tools, actions that can be taken to resolve this weakness could include conducting research on available testing tools on the market, setting a budget for the purchase of testing tools, purchasing the tools, and providing training for using the tools. Produce an action plan that will address each weakness, opportunity, and threat you identified during your SWOT analysis. You do not need to create an action plan for your strengths unless you believe you must take specific actions to ensure that you remain strong in an identified area.
The next step in the Planning phase is to bring together the results of the SWOT with the corresponding action plans into a single plan that will guide the Execute phase of the process improvement framework. Again, the best way to accomplish this is in a group setting in the form of a workshop. When establishing a plan for process improvement, you should take into account four different perspectives. The first is the perspective of Process Management, in which goals and tasks are directly related to continual process improvement activities and governance. The next perspective is Project Management, in which the goals and activities are related to the facilitation and oversight of the process improvement project. Technology is the third perspective, whose goals and activities relate specifically to software design, development, construction, testing, and deployment. The final perspective is Support, which deals with all goals and activities that support the other three perspectives. Support may include ordering hardware or software or even finding space for the process improvement team to work. Note how the sample planning grid shown in Table 6-5 breaks the plan into perspectives, iterations, and then further into goals and tasks.
| Perspective | Iteration 1 Goals | Iteration 1 Tasks | Iteration 2 Goals | Iteration 2 Tasks |
|---|---|---|---|---|
| Process | Adopt code quality processes. Adopt design quality standards. | Integrate Testing and Uniting into Planning for new projects. Plan reviews for Requirements and Architecture for new projects. | Establish quality gates. Establish daily project feedback. | Develop release checklists. Trial run daily team meetings. |
| Management | Approve Team System budget. | Work with team to determine Team System costs. | Establish feedback mechanisms. | Facilitate daily team meetings. Facilitate gathering of lessons-learned information. |
| Technology | Adopt code quality processes. | Research code standards. | Implement Team System. | |
| Support | Prepare for Team System. | Get trained on Team System. Order Team System hardware/software. | Establish Project Learning Center. | Use Microsoft Windows Share-Point Services to establish repository for all project lessons learned. |
The goals of the plan are kept separate to ensure that all team members know when they are complete. The goals and tasks you will use to populate the grid will come from the results of the SWOT analysis. Simply take the action plans you created for the highest priority weaknesses, opportunities, and threats, and work them into the plan with your team into iterations. The length of each iteration will depend greatly on your organizational constraints such as impact on other corporate commitments and service outages. Table 6-6 summarizes the Plan phase of the LPI framework.
| Topic | Description |
|---|---|
| When can you begin? | Project charter accepted by business stakeholder. Resources and team allocated. Kickoff meeting held. |
| How do you know when you are finished? | Assessment results document completed and distributed to the team. Process improvement plan created and approved. Resources secured for plan execution. |
| Typical activities | Collect information on existing processes and technologies. Conduct one or more assessment workshops. Conduct one or more planning workshops. Review/approve the plan. |
| Deliverables | Assessment results document. Process improvement execution plan. Risk assessment. |
|
Sometimes the assessment and planning workshops described in this chapter bring out only a negative view of an organization’s ability to develop software. For this reason, it is important that the strengths of the organization be considered first. With this in mind, however, you want your entire team to talk openly about their feelings and opinions on your existing processes, and you should be prepared to hear things you may not want to hear. You must acknowledge every team member’s opinion equally because you do not want to establish any barrier that may prevent your team from hearing all of the cold hard facts that will help drive good decision making.
|
Executing and Monitoring Process Improvement
Simply put, during the Execution and Monitoring phase of the LPI framework, your project team will work toward achieving the goals and performing the activities decided on by the previous planning phase. This phase will end when you have achieved all your goals or time has run out. Just as in other projects, it is a good idea to segment the Execute phase into fixedduration iterations. In a process improvement project, activities usually do not get performed with the same velocity as they might on regular projects because a process improvement project is typically run at the same time as normal projects. Therefore, iterations usually last at least 20 working days. The lengths of each iteration do not need to be the same, and you and your team should use common sense when deciding length.
As with regular projects, your process improvement team should meet regularly to review the progress of the project. In these meetings, the team raises any blocking issues or conditions that may require the project plan to be modified and the team to refocus. Don’t be afraid to change your plan if changes will increase your chances of success.
The team should maintain the following mindsets during this phase of the project:
-
Expect to make changes to your process improvement plan.
-
Maintain momentum on all activities even though it is sometimes difficult because of other day-to-day responsibilities of team members.
-
Try to achieve results early and often.
-
Celebrate every achievement.
-
Don’t set yourself up for failure; keep the scope of the project under tight control, making sure not to take on more than your team can handle. If one part of the project needs to increase in scope, you should consider reducing scope in other areas.
Table 6-7 summarizes LPI’s Execute phase.
| Topic | Description |
|---|---|
| When can you begin? | Process improvement execution plan created. Resources secured. |
| How do you know when you are finished? | Goals and activities achieved or the end of the phase reached because of budget and schedule constraints. |
| Typical activities | Activities will vary from project to project and will depend on the results of the process improvement execution plan. |
| Deliverables | Deliverables specified by the process improvement execution plan. |
Reviewing and Continuation of Process Improvement
The Review phase marks the transition between an Execute phase and the Plan phase of the LPI, when you will essentially start all over again. During the Review phase, the team and sponsors meet to take a peripheral look at the activities performed and goals achieved during the Execute phase. The team comes together to assess progress, and they plan to repeat the process.
As with all previous phases of the LPI framework, conduct a facilitated review workshop with your team to objectively reflect on the success of your project and each planned goal and activity. During the workshop, you should take a close look at the team’s progress and record any learned lessons that should be incorporated into future Plan and Execute phases. The review session must be facilitated by a member of your team to stay focused on the following aspects of your project:
-
Changes made to process, team models, and underlying tools and infrastructure.
-
Comparison of the planned process improvement tasks and goals to actual results.
-
The impact of the results towards the needs of the business.
-
Team productivity improvements.
-
Team morale and working condition improvements.
The project manager, in conjunction with the process improvement team, also schedules a planning workshop that will lay the framework for the next iteration of process improvement. More details on this phase are provided in Table 6-8.
| Topic | Description |
|---|---|
| When can you begin? | After the completion of the Execute phase. |
| How do you know when you are finished? | Planning phase meetings are scheduled and organized. |
| Typical activities | Review workshop. |
| Deliverables | Lessons learned document. |
|
From a project manager’s perspective, one of the key objectives is to improve a team’s ability to estimate effort and schedule. From a process improvement perspective, one of the only ways you can effectively accomplish this might not be obvious. Many organizations think that by recording the differences between estimated effort and actual effort on projects, they can adjust their future estimates accordingly. Unfortunately, this doesn’t work for many different reasons, such as different team dynamics and ever-changing technologies. The best way to improve your team’s estimating ability is to decrease the amount of unknowns on your project to increase the certainty of the estimates and by ensuring that the estimates reflect all aspects of a project. For example, most of the time developers will provide an estimate that includes only the time required to write the code for a solution. These estimates do not take into account the time required for developer testing, integration of the features into the product, the establishment of unit tests, deployment considerations, and so on. Make an estimating checklist to ensure that your team addresses each of these areas when providing an estimate.
With regard to reducing the unknown, start by emphasizing activities that increase the quality, not the velocity, of your projects. For example, asking a project team “How many bugs will you have in your next project?” would probably generate some blank stares. The answer to this question is impossible to even guess. However, asking your project team “How long will it take to write unit tests for this feature?” would likely yield a good estimate. So, if writing unit tests during the development of software reduces the unknown with respect to the time required to fix bugs, you should probably spend more time unit testing. This activity might be perceived as slowing the team down because fewer features can be developed in the same period of time, but you should do it anyway. Including activities in your project that increase the quality of requirements, designs, code, deployment packages, or even documentation increases the certainty of your estimates.
Technology change is a very important aspect of a project that tends to decrease overall certainty of estimates. For example, a developer may be quite certain how to write a particular function in Microsoft Visual Studio 2003 on version 1.1 of the Microsoft .NET framework but be uncertain of how long this same task will take using Visual Studio 2005 and version 2.0 of the .NET framework. This problem is compounded by the dramatic change of all aspects of technology. You can increase certainty, however, by ensuring that your team has easy access to abundant technical resources and is well educated about future technology in addition to current technology. For example, you could form centers of excellence in your organization that facilitate the sharing of experience and knowledge to decrease the amount of technical uncertainty your team experiences on a project. However, if there is a single ultimate truth that you should embrace with regard to estimation, it’s that you can never get good estimates from bad requirements.
|
EAN: N/A
Pages: 93