The Mythical Man-Month

The Mythical Man-Month

In the seventh essay of The Mythical Man-Month, Fred P. Brooks begins to tackle the concept of estimating. While there are many estimating techniques, Brooks’ approach is a history/data-based approach, which we would understand as today as parametric estimation. Parametric estimation is generally a technique that generates a prediction of the effort needed to deliver a project based on historical data of productivity, staffing and quality. Estimating is not a straightforward extrapolation of has happened in the past to what will happen in the future, and mistaking it as such is fraught with potential issues. Brooks identified two potentially significant estimating errors that can occur when you use the past to predict the future without interpretation.

Often the only data available is the information about one part of the project’s life cycle. The first issue Brooks identified was that you cannot estimate the entire job or project by just estimating the coding and inferring the rest. There are many variables that might affect the relationship between development and testing. For example, some changes can impact more of the code than others, requiring more or less regression testing. The link between the effort required to deliver different types of work is not linear. The ability to estimate based on history requires a knowledge of project specific practices and attributes including competency, complexity and technical constraints.

Not all projects are the same. The second issue Brooks identified was that one type of project is not applicable for predicting another. Brooks used the differences between small projects and programming systems products to illustrate his point. Each type of work requires different activities, not just scaled up versions of the same tasks. Similarly, consider the differences in the tasks and activities required for building a smart phone app compared to building a large data warehouse application. Simply put, they are radically different. Brooks drove the point home using the analogy of extrapolating the record time for 100-yard dash (9.07 seconds according to Wikipedia) to the time to run a mile. The linear extrapolation would mean that a mile could be run in 2.40 (ish) minutes (a mile is 1760 yards) the current record is 3.43.13.

A significant portion of this essay is a review of a number of studies that illustrated the relationship between work done and the estimate. Brooks used these studies to highlight different factors that could impact the ability to extrapolate what has happened in the past to an estimate of the future (note: I infer from the descriptions that these studies dealt with the issue of completeness and relevance. The surveys, listed by  the person that generated the data, and the conclusions we can draw from an understanding of the data included:

  1. Charles Portman’s Data – Slippages occurred primarily because only half the time available was productive. Unrelated jobs meetings, paperwork, downtime, vacations and other non-productive tasks used the remainder.
  2. Joel Aron’s Data – Productivity was negatively related to the number of interactions among programmers. As the number of interactions goes up, productivity goes down.
  3. John Harr’s Data- The variation between estimates and actuals tend to be affected by the size of workgroups, length of time and number of modules. Complexity of the program being worked on could also be a contributor.
  4. OS/360 Data- Confirmed the striking differences in productivity driven by the complexity and difficulty of the task.
  5. Corbatoó’s Data – Programming languages affect productivity. Higher-level languages are more productive. Said a little differently, writing a function in Ruby on Rails requires less time than writing the same function in macro assembler language.

I believe that the surveys and data discussed are less important that the statistical recognition that there are many factors that must be addressed when trying to predict the future. In the end, estimation requires relevant historical data regardless of method, but the data must be relevant. Relevance is short hand for accounting for the factors that affect the type work you are doing. In homogeneous environments, complexity and language may not be as big a determinant of productivity as the number of interactions driven by team size or the amount of non-productive time teams have to absorb. The problem with historical data is that gathering the data requires effort, time and/or money.  The need to expend resources to generate, collect or purchase historical data is often used as a bugaboo to resist collecting the data and as a tool to avoid using parametric or historical estimating techniques.

Recognize that the the term historical data should not scare you away.  Historical data can be as simple as a Scrum team collecting their velocity or productivity every sprint and using it to calculate an average for planning and estimating. Historical data can be as complex as a pallet of information including project effort, size, duration, team capabilities and project context.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?

1127131620a_1

There are many levels of estimation including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes at higher levels of estimation. As you get closer to the core of the planning onion the case for the #NoEstimates becomes more compelling.

03fig01.jpg (500×393)

Planning Onion

 

Budgeting is a strategic form of estimation that most corporate and governmental entities perform.  Budgeting relates to the strategy and portfolio layers of the planning onion.  #NoEstimates techniques doesn’t answer the central questions most organizations need to answer at this level which include:

1.     How much money should I allocate for software development, enhancements and maintenance?

2.     Which projects or products should we fund?

3.     Which projects will return the greatest amount of value?

Budgets are often educated guesses that provide some approximation of the size and cost of the work on the overall backlog. Budgeting provides the basis to allocate resources in environments where demand outstrips capacity. Other than in the most extreme form of #NoEstimate, which eschews all estimates, budgeting is almost always performed.

High-level estimation, performed in the product and release layers of the planning onion, is generally used to forecast when functionality will be available. Release plans and product road maps are types of forecasts that are used to convey when products and functions will be available. These types of estimates can easily be built if teams have a track record of delivering value on a regular basis. #NoEstimates can be applied at this level of planning and estimation by substituting the predictable completion of work items for developing effort estimates.  #NoEstimates at this level of planning can be used only IF  conditions that facilitate predictable delivery flow are met. Conditions include:

  1. Stable teams
  2. Adoption of an Agile mindset (at both the team and organizational levels)
  3. A backlog of well-groomed stories

Organizations that meet these criteria can answer the classic project/release questions of when, what and how much based on the predictable delivery rates of #NoEstimate teams (assuming some level of maturity – newly formed teams are never predictable). High level estimate is closer to the day-to-day operations of the team and connect budgeting to the lowest level of planning in the planning onion.

In the standard corporate environment, task-level estimation (typically performed at the iteration and daily planning layers of the onion) is an artifact of project management controls or partial adoptions of Agile concepts. Estimating tasks is often mandated in organizations that allocate individual teams to multiple projects at the same time. The effort estimates are used to enable the organization to allocate slices of time to projects. Stable Agile teams that are allowed to focus one project at a time and use #NoEstimate techniques have no reason to estimate effort at a task level due to their ability to consistently say what they will do and then deliver on their commitments. Ceasing task-level estimation and planning is the core change all proponents of #NoEstimates are suggesting.

A special estimation case that needs to be considered is that of commercial or contractual work. These arrangements are often represent lower trust relationships or projects that are perceived to be high risk. The legal contracts agreed upon by both parties often stipulate the answers to the what, when and how much question before the project starts. Due to the risk the contract creates both parties must do their best to predict/estimate the future before signing the agreement. Raja Bavani, Senior Director at Cognizant Technology Solutions suggested in a recent conversation, that he thought that, “#NoEstimates was a non-starter in a contractual environment due the financial risk both parties accept when signing a contract.”

Estimation is a form of planning, and planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When with will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopted the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.

 

A framework is just a framework without planning!

A framework is just a framework without planning!

Personal Scrumban establishes a framework for conquering the chaos that day-to-day life can throw at you. However having a structure, even a structure with multiple classes of service, does not get the most important pieces of work in the queue when they need to be in the queue. Planning is required. Weekly and daily planning exercises, similar to sprint planning and the daily stand-up, are useful for taming the backlog and adapting to the demands of real life.

I begin all weekly planning sessions with a quick backlog grooming session (note: when new items are added to the queue during the week, grooming can be performed). In personal Scrumban, the goal of backlog grooming is not get team consensus (no need for the Three Amigos). Rather the goal is to ensure each backlog item that might need to be tackled in the next week has been broken down so that there are one or two immediate next steps identified. The first step in backlog grooming is to ensure that all work items (or stories) have been classified by class of service. For example, if one of the work items was “Review cover art for the Hand-Drawn Slide Saturday Ebook,” the work item should be classified in the Podcast/Blog class of service. Classes of service act as a macro prioritization and assigns the work to the relevant time slice in any given day. The second step is sizing, just like in Scrum, the immediate next steps should be of a size that can be accomplished in a single sitting. The information gathered in execution will used as part of daily planning or during the next weekly planning session.

Weekly planning is comprised of getting work items in priority order and then deciding which needs to be dealt with during the upcoming week GIVEN what is known when planning occurs. If you have not already established a work-in-process limit (WIP), set one for each class of service. A WIP limit is the amount of work you will allow yourself to start and actively work on at any point. Work is only started if there is capacity to complete the task. Prioritize up to the WIP limit or just slightly past the limit in each category. Remember if as you complete tasks in a category (and you have time) you can refresh the backlog by prioritizing new items. I generally do my weekly planning every Sunday evening so that I am ready to begin the when I roll out of bed on Monday.

Daily planning is exactly like a daily stand-up meeting, with two minor twists. In Scrum, the daily stand-up meeting starts the day with each team member answering the three famous questions:

  • What did I complete since the last meeting?
  • What will I complete before the next meeting? and
  • What is blocking progress?

The three questions provide a framework to make generate laser focus on what is done and what needs to be done. The twists

In personal Scrumban, as in normal Kanban, completed work items would have been moved to the completed column of the Kanban board as soon as they done, however this is a good time to ensure that has occurred. The twists relate to how new items are dealt with and time allocation. During planning, work items that will be accomplished during the next 24 hours should be moved to in-progress. Given the nature of daily planning, if new work items have been discovered and prioritized into the backlog, they then become part of the standard planning process. The stand-up also provides time to reflect on anything that will block accomplishing the planned work items. A second twist to the stand-up process is a reassessment of the time slices being provided to each class of work. For example, if a critical work product needs to be completed, time from a more discretionary class of service can be reallocated and the work items in this category can be put on hold.

A weekly planning session provides a stage to address the week. To paraphrase Helmuth von Moltke the Elder, no weekly plan stands first contact with Monday. The daily stand-up provides a platform to re-adjust to the nuances of the week so that you can stay focused on delivering the maximum value possible. Without planning, all personal Kanban is a framework and a backlog of to-do items.  Planning puts the energy into the framework that provides the guidance and reduces stress.

 

Forewarned is forearmed!

Forewarned is forearmed!

Testing is an important set of tools for influencing the quality of the functionality that gets delivered. The term testing can cover a wide range of activities ranging from reviews to user acceptance testing with a nearly infinite number of stops in between. Some organizations expend up to 60 – 70% of project effort just on testing (this is abnormally high), often with the intention of “testing in” quality. When the effectiveness and efficiency of testing has been derailed there are five typical root causes.

  • Planning
  • Involvement
  • Organizational Management
  • Capability
  • Process

Planning is the first of the root causes. Poor planning will yield poor results. Test planning defines the approach a project will use to verify and validate the deliverable they are creating. There are several inputs that impact and shape a test plan. The inputs are:

  1. Risk – Risk is a reflection of possibilities that might impact the project if they occur. Some projects will inherently have a bigger impact on the organization if things go wrong. Testing can be tuned to act as insurance that risks do not become issues. Agile projects use a wide range of techniques to incorporate risk into how testing is approached. Planning techniques include release planning, sprint planning, tools like the definition of done, techniques such as test first development (including test driven development) or classic test planning documentation.
  2. Test Goals – Test goals reflect an organization’s business strategy and needs. Test goals can be as simple as ensuring software is defect free (this is not only simple, but a simplistic) to improving the product’s delivered quality (as compared to a standard or a baseline).
  3. Test Policy – A policy defines a course of action that supports a long-term purpose. A test policy describes the type of behavior without defining the ends, means or approach. Good policies are aligned with the business strategy and the test goals. Test policies must be agreed upon (at least passively) by all of the stakeholders.  Policies that the involved parties don’t agree with will potentially generate poor behavior as stakeholders struggle against what they perceive as artificial constraints. For example a policy that requires all applications to be stress tested even if they are standalone, one person applications will not be perceived as fitting the environment.  The policy will be ignored when practitioners don’t think it applies which opens the door for failure if something is not stress tested that should be.
  4. Test Strategy – At an organizational level, a test strategy represents a broad outline that will orperationalize the test policy.At a project level, a test strategy will define the how the project will conform to the test policy and meet the test goals. The strategy operationalizes the testing goals and policies based on the business and project risks.

The typical image painted when discussing test planning is an omnibus document that defines how a project will approach testing, sometimes in mind-numbing detail. While that level of detail might be important in some scenarios, in most Agile projects the adoption of standard techniques provides the policy, strategy and guidance to ensure a good test planning. Agile techniques that improve planning include:

  1. Well-formed user stories (including acceptance criteria),
  2. Test first development (such as test driven development or acceptance test driven development), and
  3. A solid definition of done.

Planning is requirement for any activity development activity, testing included.  Good planning is a requirement for good testing.

The schedule is not the enemy when used correctly.

The schedule is not the enemy when used correctly.

I recently asked a group of the Software Process and Measurement listeners why they hated schedules. The focus of the question was not on plans, which are documents that provide strategic direction but rather schedules which are more task oriented. The respondents were a mixture of scrum masters, project managers, process improvement leaders and change leaders primarily in software development, enhancement and support. I should note that by being readers of a process blog and/or listeners to process-related podcast the respondents marked themselves as lifelong learners and perhaps a bit outside of the norm (in a good way). However, the top five answers were:

  1. They are generally wrong. Schedules, especially anything over a longer time horizon, establish an expectation. These schedules reflect best guess and best intentions and rarely standup to what as teams wrestle with delivering value. There are all sorts of techniques to try to anticipate schedule drift, like adding padding. These techniques are tacit admissions that the schedules are generally wrong.
  2. Schedules prescribe how a problem is to be solved. A detailed schedule is the embodiment of a solution; listing the tasks that specify what is to be done and when it needs to start and be completed. However, as most projects progress, the solution as it was originally conceived, evolves. This renders a detailed schedule moot.
  3. Schedules are someone else’s idea of what should happen. Project managers or tech/test leaders are often tasked with creating schedules (this even happens on Agile teams when someone else breaks tasks down and assigns the work). Schedules are created with input or buy-in from the team doing the work yielding animosity and stress from the team. Release and iteration planning are Agile’s solutions to these problems.
  4. Schedules reduce team behavior. One attribute of an Agile team is supportive behavior. Teams commit to work and then, when needed, swarm to tasks and features so that the team can meet its commitment. Detailed project schedule commits team members to performing specific tasks in a specific order.  The schedule gets in the way of team members being able to use self-organizing techniques like swarming.
  5. Detailed schedules take a huge amount of upkeep. One respondent suggested that for any project scheduled to take more than a year to complete, one person should be allocated to maintaining the schedule. That included chasing team members for updates, resolving conflicts and in general being a pain. Other respondents were less specific, but indicated that the cost of the schedule was more than the value.

The question generated responses that were oriented detailed project schedules typically found in projects managed using classic project management techniques.  A few respondents pointed out the value of detailed project schedules. Some of the benefits included the ability to distribute and direct work across distributed teams and to facilitate a discussion of when the project would deliver. It should be noted that these responses came from more command and control oriented organizations. Respondents with a background in Agile tended to point out that while they did not feel that a classic project schedule made sense, the combination of product backlog and sprint level task list was a necessity.

 

A map is a plan.

A map is a plan.

All projects should have some sort of plan. Whether that plan is a classic project plan and schedule or a prioritized backlog and a release plan. A plan helps answer stakeholder questions and, perhaps more importantly, it reflects the philosophy of the project. In order for a plan of any type to be helpful, the plan and philosophy must be possible. Bob Ferguson (Listen to SPaMCAST 240) said that there were ways to detect a plan what was not possible. Several of the rules of thumb that Bob suggested (augmented with a few of my own) are:

  1. Difficult work is done late. This is on both of our lists. Teams that avoid addressing difficult or technically complex stories backload risk, which can impact a project’s ability to deliver value. Conceptually this problem should be harder in Agile, assuming stories or features are prioritized in value order and the inter-relationship between features is factored into the value discussion.
  2. Learning is not explicitly planned. Any project that is creating new features or a new product should have prototyping built into the process used to gather requirements and build a backlog. Experiments/prototypes also can and should be used to prove solutions that are complex or cutting edge (at least for the team). This item was on Bob’s list and not on mine; it is now.
  3. Rate of story completion is not feasible. If the plan can’t be completed given the team’s (or teams’) level of velocity or productivity, then it is a bad plan. Plans that specify the amounts of functionality to be delivered, the date of delivery and the budget to be spent have credibility problems, however when they are developed using wishful thinking productivity rates they enter into the impossible range. This one is on my list and not Bob’s (in your face Bob).
  4. Belief that the plan — is THE Plan. A plan, schedule or backlog that does not change for a project of any moderate or large size is wrong or if it actually works is  the reflection of sheer dumb luck (Harry Potter reference – reread Harry Potter and the Philosopher’s Stone.). Anyone that falls into the trap of absolute belief that any project deliverable can be created once and referenced forever will find delivering value difficult at best.
  5. Not involving the business. The real product owner(s) must be part of the product to act as an active conduit of business acumen into the team to minimize wait and search time. All too often business stakeholders have been taught treat the boundary between IT and the business as a demilitarized zone where information hand-offs occur on a periodic basis. This behavior makes planning and maintaining any sort of plan difficult at best which slows the project down. IT teams often elect proxy product owners from inside the IT boundary leading to the same result (I heard this termed all of the responsibility and none of the authority). Proxy product owners can’t provide the level of feedback on priorities and the plan that the business can.

Plans have value only if they are current and only if maintaining plans, schedules, backlogs and the release plans do not become the goal of the project. Planning helps teams to develop a strategy for delivering value, but they must be allowed to change. Change is inevitable because we are learning both personally and about our project everyday. Not using what we learn is silly!

 

Does the raft have a peak load?

Does the raft have a peak load?

Peak load is an engineering concept that has found its way into software development and maintenance conversation.  Peak load is a spike over a specific period of time and not a sustainable level of performance. When applied to a software team, the peak load is how much additional work a team can do for a short period of time. Before we concluded with the admonition; “The idea of pushing a team to a peak load should be used judiciously.” To which Assaf Sternberg asked “Tom, how do you square this away with another thing that differentiates good software engineering from assembly line work – the ability to refactor/reengineer the solution in anticipation of future work to make the latter easier/faster/less risky? Over the long run, this should make it possible for the ‘functional point’ count per sprint to continue to rise (while these items would require less effort)”

Refactoring, also known as code refactoring, is the process changing or restructuring code to be simpler, more effective or more efficient without changing the code’s functional behavior. Refactoring can also be done to make code be more maintainable or extensible. The need to refactor can be inferred from the Agile principles of simplicity and emergent design. Refactoring is an integral part of development in most implementations of Agile.  For example, in test driven development the final step in process is to refactor both the code and design.

In order for refactoring to be effective, it needs to be planned part of work and needs to done in pursuit of an overall goal that can be tested. During sprint planning teams need to identify tasks for refactoring just as they do for other development activities.  Refactoring is just another task that requires time and uses the team’s capacity. When the team plans for refactoring, it is reflected in the team’s velocity and productivity. When a team adopts the technique of refactoring it will initially reduce their functional output, thereby reducing velocity and productivity. But, over the long run, data I have collected as an Agile coach shows that that productivity and velocity increase (about 5% year over year). When productivity goes up more functionality is delivered for less effort. Refactoring is at least partially responsible for this increase.

Refactoring is done to attain a stated goal.  For example, a team recently I worked with focus their refactoring efforts on maintainability (the team had developed standards for maintainability). Given that they had to implement, maintain and enhance the code as a team maintainability improves their overall efficiency (reflected in velocity and productivity changes over time).  The team developed the goal, then agreed on how to pursue the goal and finally agreed how they would know if they were successful.  A goal is important to ensure that team members do not act in an ad hoc manner.

How does or should refactoring impact a team’s a sustainable pace and by extension their peak load? Refactoring does not extend the day, there are same number of hours in your work day. What it does is help the team be more efficient and effective over time. Therefore refactoring increases velocity and productivity.  This is only possible if refactoring is planned as part of the teams normal activity and focused on achieving a goal.

Do I budget, estimate or plan the number of crawfish I am going to eat?

Do I budget, estimate or plan the number of crawfish I am going to eat?

Software project estimation is a conflation of three related but different concepts. The three concepts are budgeting, estimation and planning.  These are typical in a normal commercial organization, however these concepts might be called different things depending your business model.  For example, organizations that sell software services typically develop sales bids instead of budgets.  The budget to estimate to plan evolution really follows the path a project team takes as they lean about the project.

Budgeting is the first step.  You usually build a budget at the point that you know the least amount about the project. Looking back on my corporate career, I can’t tell how many late nights were spent in November conceptualizing projects with my clients so that we could build a budget for the following year.  The figures we came up with were (at best) based on an analogy to a similar project.  Even more intriguing was that accounting expects you to submit a single number for each project (if you threw in decimal points they were more apt to believe the number).  Budget figures are generated when we know the least, which means we are at the widest point of the cone of uncertainty.  A term that is sometimes used instead of a budget is rough order of magnitude.

The second stop on the estimation journey generally occurs as the project is considered or staged in the overall project portfolio.  An estimate generally provides a more finite approximation of cost, effort and duration based on deeper knowledge. There is a wide range of techniques for generating an estimate, ranging from analogies to parametric estimation (a process based on quantitative inputs, expected behaviors and past performance).  The method you use depends on the organization’s culture and the amount of available information.  Mature estimation organizations almost always express an estimate either as a range or as a probability.  Estimates can be generated iteratively as you gather new information and experience.

The final stop in the decomposition of the from the budget to the estimate is the plan. A plan is the work breakdown structure for the project (generally with task estimates and resources assigned) or a task list. In order to create a plan you must have a fairly precise understanding what you are building and how you are going to build it.  Good planning can only occur when a team is in thinnest part of the cone of uncertainty. Or, in other words, where you have significant knowledge and information about what you are planning.  Immature organizations often build a plan for a project, sum the effort and the cost and then call the total an estimate (this is called bottom-up estimating) which mean they must pretend to know more than the really can. More mature organizations plan iteratively up to a short-term planning horizon (in Agile that would be the duration of a sprint) and then estimate (top-down) for periods outside the short term planning window.

Short Descriptions:

  • Budgeting: Defines how much we have to spend and influences scope.   A budget is generally a single number that ignores the cone of uncertainty.
  • Estimating: Defines an approximation of one or more of the basic attributes that define the size of the project. The attributes include of cost, effort, duration. An estimate is generally given as a range based on where the project is the cone of uncertainty.
  • Planning: Builds the task list or the work breakdown so that resources can be planned and organized. Planning occurs at the narrowest part of the cone of uncertainty.

Estimating means many things to many people.  In order to understand the process and why some form of estimation will always be required in any organization, we need unpack the term and consider each of the component parts.  Each step along the continuum from budgeting to planning provides different information and requires different levels of information ranging from the classic back of the napkin concept (budget) to a task list generated in a sprint planning session (plan).  Having one does not replace the need for the other.

Plans are your guide to where you want to go.

Plans are your guide to where you want to go.

(Part of the Simple Checklist Series)

The simple Measurement Readiness Checklist will be useful for any major measurement initiative, but is tailored toward beginning a measurement program.  The checklist will provide a platform for evaluating and discussing whether you have the resources, plans and organizational attitudes needed to implement a new measurement program or support the program you currently have in place.

I have divided the checklist into three categories: resources (part 1 and 2), plans, and attitudes.  Each can be leveraged separately. However, using the three components will help you to focus on the big picture. We will address each component separately over the next several days.

Here we continue the checklist with the section on plans and planning.  If you have not read the first two sections of the checklist please take a moment see (Measurement Readiness Checklist: Resources Part 1 and Measurement Readiness Checklist: Resources Part 2).

Plans

Planning for the implementation or support of a measurement program can take many forms — from classic planning documents, to schedules, Kanban boards or even product backlogs.  The exact structure of the plan is less germane here, rather having an understanding of what needs to be done is most important. There are several plans that are needed when changing an organization. While the term “several” is used, this does not mandate many volumes of paper and schedules, rather that the needs and activities required have been thought through and written down somewhere so everyone can understand what needs to be done. Transparency demands that the program goal is known and that the constraints on the program have been identified (in other words capture the who, what, when, why and how to the level required).

Scale and Scoring

The plans category of the checklist contributes up to eighteen total points. Each component contributes up to 6 points (6, 3, 1, 0).

Organizational Change Plan

The Organizational Change Plan includes information on how the changes required to implement and/or support the measurement program will be communicated, marketed, reported, discussed, supported, trained and, if necessary escalated.  This level of planning needed to include tasks such as:

  • Develop activity/timeline calendar
  • Identify topics newsletter articles
  • Create articles
  • Publish articles
  • Identify topics for education/awareness sessions
  • Schedule sessions
  • Conduct sessions

6 – A full change management plan has been developed, implemented and is being constantly monitored.

3 –An Organizational Change Plan is planned, but is yet to be developed.

1 – When created, the Organizational Change Plan will be referenced occasionally.

0 – No Organizational Change Plan has or will be created.

Support Note: Even when a program reaches the level of on-going support, an overall organizational change and marketing plan is needed.  Adding energy to keep the program moving and evolving is necessary, or entropy will set in.  Any process improvement will tend to lose energy and regress unless they continually have energy added.

Backlog

The backlog records what needs to be changed, listed in prioritized order. The backlog should include all changes, issues and risks. The items in the backlog will be broken down into tasks.  The format needs to match corporate culture and can range from an Agile backlog, a Kanban board to a Microsoft Project Schedule.

6 – A prioritized backlog exists and is constantly maintained.

3 – A prioritized backlog exists and is periodically maintained.

1 – A rough list of tasks and activities is kept on whiteboard (but marked with a handwritten “do not erase” sign).

0 – No backlog or list of tasks exists.

Support Note:  Unless you have reached the level of heat death that entropy suggests will someday exist, there will always be a backlog of new measurement concepts to implement, update and maintain. The backlog needs to be continually reviewed, groomed and prioritized.

Governance

Any measurement program requires resources, perseverance and political capital. In most corporations these types of requirements scream the need for oversight (governance is a friendly code word for the less friendly word oversight). Governance defines who decides which changes will be made, when changes will be made and who will pay for the changes. I strongly recommend that you decide how governance will be handled and write it down. Make sure all of your stakeholders are comfortable with how you will get their advice, counsel, budget and, in some cases, permission.

6 – A full-governance plan has been developed, implemented and is being constantly monitored.

3 –A governance plan is planned, but is yet to be developed. .

1 – When created, the governance plan will be used to keep the process auditors off our back.

0 – Governance . . . who needs it!

Next  . . . Attitude. You have to have one and you have to manage that attitude to successfully lead and participate in organizational change.

Use tools to keep the whole team engaged.

Use tools to keep the whole team engaged.

Distributed Agile planning is not any different from non-distributed in terms of its goal and process.  What should be different are the techniques and amount of facilitation.  Before we go further, I do not think there is any reason planning can’t be done amongst a distributed team. I do not believe there is any need to change the time parameters.  However, both of these statements are true only if the team stays engaged and the Scrum Master provides active facilitation.  The single biggest hurdle when a distributed team is involved in planning is keeping everyone engaged.

Visualization is a powerful tool to help foster engagement.  There are two types of visualization that are important.  The first and simplest is that all team members should be able to clearly see what is being discussed.  For example, I recently participated in an internal sprint planning meeting.  We used a screen sharing software that everyone on the team used.  As a story was discussed and planned, we brought it up on the screen so that everyone in the session could refer to the same set of words. Tasks, as they were identified, were typed directly into a shared document on the screen.  A second form of visualization relates to the team.  Use video on top of any screen sharing tools.  Seeing people as they discuss a point or talk about a story imparts significantly more information that just hearing them.  Think of how different the typical experience is when listening to radio compared to television.

IT personnel tend to be gadget and tool aficionados.  While a good tool for seeing the backlog or Kanban board is critical (emphasis on good, there are some re-purposed waterfall tools I would avoid like the plague . . . actually I might consider the plague first), the process needs to be simple enough that the set up time does not eclipse the planning time.  Tools like mind mapping software can be very useful to quickly capture and organize information. I personally use several including FreeMind (free and open source).  Another simple tool is Mountain Goat Software’s planning poker site at www.planningpoker.com.  I strongly suggest Scrum Masters (or coaches) walk through the tool suite they will use during planning before “going” live.  A simple check list of tools I use is:

  1. Screen Sharing Software: Tool examples include Webex or the like
  2. Video: Software examples include Skype Pro and OOvOO.
  3. Backlog/Kanban Boards: Examples include LeanKit, Kanbannery and Trello.
  4. Mind Mapping Tools: Examples include iTHoughts, FreeMind and Astah.
  5. Planning Poker Tool: www.planningpoker.com
  6. Egg timer (or sometimes the timer on my phone)
  7. DECENT PHONES

The last item is capitalized because all bets are off if team members can’t hear each other.

Once the team has gotten over the hurdle of using the communication tools, the final problem is one of facilitation.  The Scrum Master needs to facilitate the process with special emphasis on making sure everyone participates and stays engaged.  They also need to pay attention to pace.  I use an egg timer to remind everyone of both the overall time box and the time box needed for planning each unit of work.

In distributed Agile, the planning process does not change.  However, keeping everyone engaged might be more difficult. The Scrum Master can make engagement more likely by making the process as easy as possible and making the process as personal as possible.  Planning is still a whole team sport, make sure that the whole team participates, no matter where they are.