• There are too many applications for the manager to make decisions on individual application enhancements. Instead, the manager must delegate this to product owners who have responsibility for specific applications.
• Enhancements would optimally be prioritized by expected return on investment (ROI), but ROI is difficult to calculate especially for comparisons between applications.
• Development teams are available for making these enhancements and need to be kept busy.

I have seen a number of strategies used for budget allocation that encounter difficulties:

• Allocate by historical spending. This is based on the immediately prior budgeting period . For example, assuming a 6 month budget, the amount spent per application from January to June would be the basis for allocation in July to December. The most serious difficulty this approach runs into is that it assumes that future work per application will match past needs, which is not always true. Some applications will have spikes of need driven by business changes that this allocation strategy does not take into account. Another difficulty with this approach is that it encourages each applications to spend all of their enhancement budget even if the return on investment is low (or negative) so that their budget is not reduced the following period.
• Allocate by application criticality and longevity. A common practice in application portfolio management is to assess each application according to its importance to the organization and expected lifespan, and then allocate budget accordingly. One difficulty with this approach is that the more critical and longer-lifespan applications may be very stable and require very little in terms of enhancements, whereas newly-built applications, irrespective of criticality or longevity, often have a higher volume of enhancements needed.

I propose a different strategy - allocating budget based on the backlog of work available for each application. This strategy avoids the disadvantages of the above approaches and makes it much easier to keep development teams busy since the money is being allocated to where the work is. Another key advantage of this approach is that it provides strong motivation for product owners to maintain backlogs. This helps provide insight to stakeholders (like the development team) within the organization regarding the future direction of the application, and makes it much easier to do activities like release planning.

Like all strategies, allocation by backlog can lead to some issues revolving around the backlog. Product owners may create overly large backlogs, typically padded with items that are either very low-value or that represent vague ideas that no one (including the product owner) would know what to do with. One possible refinement to the strategy to help avoid these issues is to only count clearly defined backlog items when allocating budget. One easy definition of "clearly-defined" is items that the development team can start working on immediately.

I will note in conclusion that any allocation strategy should not be used blindly - flexibility should be maintained to allow for budget adjustments both initially, at the start of the budget period, and over time as new information comes to light.

To be clear, I am not talking about process certifications for individuals like the popular Certified ScrumMaster and Project Management Professional. I view these certifications as recognition of a person achieving a certain level of knowledge with a particular process - what the person does with this information is entirely up to them. (The value of these certifications is a completely separate debate I do not want to get into today.)

So what is my key issue with organizational process certification? It stems from my passion for continuous improvement. In my mind there is a fundamental mismatch between a true culture of continuous improvement, such as I have read about regarding Toyota in books like The Toyota Way by Jeffrey Liker, and the requirement to comply with a particular process to maintain certification. Continuous improvement may identify activities or aspects of the process that can be altered or eliminated due to lack of value (waste, in lean terms), but if these aspects are required by the certification, then the certification itself becomes an impediment to change.

One example comes from software development teams starting with Scrum and then inspecting and adapting their process as they proceed (which is a key aspect of Scrum). Some teams end up with an arguably different Agile process such as Kanban that can no longer be called Scrum, and other teams end up with some hybrid version of Scrum that may or may not be as effective, but may be more achievable given the limitations of the organizational context. (Jeff Sutherland, co-creator of Scrum, derisively labels limited adoptions as "ScrumButt".) The frequent debates that occur as to whether such teams are really doing Scrum are lively but largely irrelevant to the more important question of whether such teams are as effective and successful as they can be. This dynamic would look completely different if a team or organization was required to use Scrum via formal certification (something, fortunately, I have not heard of happening.) Then the question of effectiveness would take a back seat to the question of compliance.

The Asian philosophical concept of yin-yang seems to be the source of inspiration for the Japanese attitude that avoids this mismatch between process compliance and continuous improvement. This viewpoint holds that a process represents the best way known at this point in time to accomplish an objective, but to always search for a better process via continuous improvement. In my readings regarding Toyota and lean thinking, it appears that continuous improvement is the ultimate priority which all processes are subordinate to.

Some standards claim to be process-neutral in the sense that they do not require a specific process. For example CMMI specifies many process areas with objectives that must be met (the what), but allows you to specify the process that meets the objective (the how). However, the requirement to meet the objectives and to produce the evidence necessary to demonstrate that the objectives have been met both introduce significant constraints on what your processes are. In addition, in my experience the CMMI appraisers / consultants seem to have a bias towards particular processes being used. As a result pursuing such standards tends to push organizations towards a certain set of practices that may or may not be appropriate.

Just because I do not like process certifications does not mean I do not like the underlying standards. There are a lot of good ideas embedded in standards like ITIL and CMMI. But there are also aspects I think are often inappropriate depending on the context. Certification prevents you from intelligently picking and choosing - the full standard is forced upon you.

I have faced this problem yet again recently and wanted to share two approaches that I have found useful: swarming and reserves.

Swarming

The basic idea behind swarming is to throw extra people at the outstanding work necessary to meet the milestone. In project management terms this typically involves sacrificing effort (budget) to save time (schedule). Effort is typically sacrificed due to two factors. First, more than the optimal number of people are working on one piece of work and some effort is lost through extra coordination. Second, people get involved doing work outside their normal expertise and thus require more time than normal.

An example of swarming is a scrum team pulling together at the end of an iteration to finish their committed stories. Developers could pair up to more quickly resolve the remaining defects. Once done testing their own functionality testers could jump in to help test other features they are unfamiliar with. Business analysts can delay working on future requirements to help test.

There are a couple of guidelines to swarming effectively. The first is to focus on the critical path - the activities that are predicted to take the longest and drive what the final completion date will be. This is typically accomplished by pulling people off of non-critical-path activities, but you have to be careful that you do not inadvertently slow down something else so much that it then becomes critical path.

The second guideline is similar: focus on work necessary for completing the milestone instead of non-milestone-related work. This may seem obvious, but in practice it is surprising how people will tend to choose the more interesting tasks over more tedious but necessary tasks (for example, updating end-user documentation prior to release). One way of achieving this focus is to clearly define what is part of the milestone versus what is not. One team I know uses a task board with post-it notes colored by release to visualize this.

Swarming only works when you have people on the team who are available to swarm - i.e. not all busy on critical path and/or milestone work. This leads us to the topic of reserves.

Reserves

The basic idea behind reserves is to hold back a portion of some type of resource so that it is available if an unforeseen situation arises - usually a problem, or sometimes an opportunity.

One very common approach is to set aside a period of time in the schedule as contingency. This may be an extra iteration per release, an end-of-release iteration to finalize the software for release, or simply extending the original estimated schedule by a certain percentage.

Another approach is to ensure that the team members are working normal hours - i.e. no overtime. If a time crunch does occur, then a short burst of overtime acts as a reserve. You have to be careful using this approach, as too much overtime is dangerous. You need to allow time for recovery afterwards, once the milestone is met, or risk disengagement, reduction in productivity, burnout, and loss of personnel.

A more advanced version of this approach is to ensure that each person is not normally 100% busy, as espoused by the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. It is suspected that this is one of the reasons that companies such as Google provides 20% time for each employee to pursue personal projects. The first benefit of slack is that this minimizes time to completion by reducing delays due to work waiting in queues (as per lean theory). This thus reduces the chance of needing to struggle to meet a milestone in the first place. The second benefit is that, like overtime, people have the capacity to increase their efforts if a milestone is threatened

A related approach that has worked well in my own experience is to have some project members normally be assigned part time with flexibility in how they spend their non-project time. During crunch periods they can then easily increase the percentage of time they spend on project work.

I would like to hear your experiences regarding swarming and maintaining reserves - please share by leaving a comment.

As I often do, I found myself reflecting at the end of these days as to whether I had properly prioritized my time. I could have been resolving tricky technical issues and advancing progress towards our desired future state in terms of architecture, technology, and development practices. But I am only one person. I realized that the focus on growing our group of solid Java developers and architects would pay off in the long run by increasing the overall capacity of problem-solving and progress-advancing.

Another consideration is that the implementation of the improvements that I wanted to see happen are limited by the capabilities and knowledge of the developers who actually put these things into practice. In the past, I have experienced problematic developers who inadvertently introduce issues that others are stuck resolving and use older technologies and/or less-effective practices through lack of awareness or poor habits. Hiring highly capable developers, in contrast, makes it much easier to make progress on these improvements. So for a limited short-term investment of my time, focusing on hiring has staggeringly immense long-term benefits.

The above logic regarding my personal limits apply just as equally to my direct involvement with hiring. As much as I may like to personally interview each applicant, I simply do not have the time, especially during hiring booms. So my objective in working on the hiring process is to put a system in place that can, if need be, operate without my involvement while obtaining the same results.

I received feedback recently from one director that the new hires we have brought on since my involvement in hiring have been almost entirely working out just fine. This is very rewarding to hear and is confirmation that my efforts in building an effective hiring system have indeed paid off.

What is it about the spreadsheet that is so alluring? There is some value to studying it - I think of it as uploading the numbers into my subconscious to get an intuitive feel for where there might be obstacles or challenges that the team is facing now or will face shortly in the future. But the value of doing so quickly drops off and yet we keep staring. Part of the temptation I feel is to find ways to bump that daily or weekly burndown just a little higher by finding that task that is actually complete or is over-estimated. This is especially true if progress has not been good.

So what can we do to stop starting at the spreadsheet?

1. Remember that identifying obstacles is no good unless they are dealt with. Focus on removing or mitigating the obstacles instead.
2. Ask yourself what activity you can do that will best accelerate the team's progress. This might be helping a developer that is stuck on a technical issue, freeing up the time from a tester who has become a bottleneck, or clarifying requirements for upcoming work. More studying of the spreadsheet is never the answer. This is especially useful when the team's progress has been lower than expected.
3. Remember that minor errors in the spreadsheet are inconsequential in the grand scheme of things. Forgetting to burn down a task or two is dwarfed by the innate inaccuracies of the estimates you are using to track progress. If you miss updating a task this week, you will likely catch it next week.
4. Remind yourself that the spreadsheet is merely a tool, and that you are the master of the tool - not the other way around.
5. Throw away the spreadsheet and use a simpler approach - perhaps a paper burndown chart on the team wall. Just ensure you do not then start staring at the wall.

In one prior project as we approached the planned deadline for starting user acceptance testing (UAT), I warned the project manager that the code quality was poor and only limited testing had been done so UAT would likely be a disaster. My advice was to miss the deadline and ensure good quality prior to entering UAT. Unfortunately, the manager decided the milestone was more important than getting the software to a working state. The code went into UAT and was soon thereafter rejected as being too buggy and unstable.

On another project a number of factors including excessive bureaucracy and externally-driven requirement changes caused delay after delay. After a few years (yes, multiple years) of delays, everyone from the project sponsor down to the project team members were so tired of the project dragging on that scope was massively cut and it was essentially rammed into production in a mostly non-functional shape, leaving the maintenance team to pick up the pieces.

Instead of focusing primarily on the plan, I propose to focus primarily on the goal - the real objectives. Progress should be evaluated as much as possible in terms of achieving objectives. I expect a common objection from plan-driven proponents would be goals are at too high a level for tracking progress. The solution is to decompose goals into the smallest possible objectives that retain meaning. In software development this means decomposing requirements or features into the smallest possible size that is still business-meaningful. Ron Jeffries calls this the minimum marketable feature (MMF) and views the delivery of working software that achieves MMFs as the fundamental unit of progress for software development.

Focusing on the goal means that a change in objectives should result in a change in action as soon as possible. Plan-driven methods seek to limit change, often explicitly, in order to stay aligned with the plan. This leads to misalignment with the goal, which over time leads to unhappy customers/users or effort wasted on pursuing the wrong direction. Most software development projects involve continual learning by both the business and by the developers about the problem domain, the solution domain, and the technical implementation of the solution. This inherently leads to objectives changing over time.

I do believe in planning, but it must remain subordinate to the objectives. The plan must remain flexible and easy to adjust based on how the objectives are being met and how they are evolving over time. Dwight D. Eisenhower is reported to have said "Plans are worthless, but planning is everything." This quote captures the essence of my philosophy. The act of planning is critically important - determining the correct course of action based on current understanding - but plans based on old and likely outdated knowledge are not.

Here are ten specific warning signs you can look for, expressed as questions to ask of yourself, your management, and your organization as a whole.

1. Given the choice between delivering service requested by a customer in variance with a defined process versus following the process and leaving the customer unhappy, what is the normal choice?
2. How would management react to the deviation from process above?
3. Can processes be easily changed when improvements are proposed, or is this difficult due to the need to pass audits involving the process.
4. Is the focus of most process improvement on addressing audit non-conformities and passing the next audit, or is the focus on improving business-meaningful objectives?
5. What percentage of management activities such as communicating in team meetings or providing direction to subordinates consists of instructing people to follow processes with the primary rationale being to pass audits.
6. Does management provide special directions to subordinates immediately prior to an audit?
7. Immediately prior to an audit, do teams spend time ensuring documented evidence is up-to-date, or worse forge it, in order to pass the audit?
8. Are teams routinely producing documentation solely for the sake of producing audit-able evidence?
9. Do teams regularly complain about certain portions of an audited process? Do they provide feedback that they do not see the point of a specific portion of the process (or all of it)?
10. Do you find yourself frustrated with a particular audited process? Do you find yourself daydreaming about how to change it or eliminate it?

To those with a bureaucratic mindset process and audits are the answer to every problem: if something goes wrong, add more process and then audit to ensure it is followed.

Audits serve a purpose, but they do have drawbacks. Over-reliance on audits can actually cause negative consequences to the organization which are often not taken into account by those pushing for more auditing. Audits should be designed to minimize these drawbacks, and the organization should introduce additional mitigations as necessary. In fact, I would go as far as saying that the use of audits should be kept to a minimum.

So what are these drawbacks? I have organized them into the following categories which are explored in detail in the remainder of this article.

• Reduces Productivity
• Harms Organizational Culture
• Limits of Assessment

Reduces Productivity

I define productivity as the amount of value produced for stakeholders based on the effort expended. In other industries such as manufacturing with more concrete notions of value it is possible to effectively measure productivity. In I.T., however, this is difficult to do, and I have never heard of an I.T. audit that evaluates productivity, value produced, or even effort expended. Audits typically instead measure compliance to documented processes based on historical documentation regarding the work that was done. This disconnect inevitably leads to a reduction in productivity in the following ways:

Do work to pass audit rather than deliver value

Auditing documented evidence of following documented processes causes people to produce documentation, whether or not it provides value, in order to pass the audit. This is especially true when the work becomes about producing the documentation instead of producing value.

Assessing quality after the fact is wasteful

Two important concepts from lean thinking are that any time delay in a process is waste, and that quality should be built into the process to avoid the waste associated with undetected quality problems remaining in the work-in-progress. Performing an audit long after an activity has been performed violates both of these concepts. In some cases I have seen audits are performed months after the activity has been completed - for example, an audit of a software enhancement that has already been deployed to production. If problems are found, it is too late for that activity. And the follow-up to determine if the problem has been resolved typically does not happen until the next audit, which is an even longer delay.

Harms Organizational Culture

An organization in which formal audits are a common occurrence risks, in my opinion, serious harm to the organizational culture by shifting the culture towards a more bureaucratic, stagnant, and confrontational atmosphere. This can happen in a number of ways:

Shift of focus away from organizational objectives

People generally have difficulty focusing on more than one or two priorities at a time. When the focus is placed on passing audits, attention is diverted away from achieving the organization's objectives or purpose. This is similar to the problem faced by traditional project management - making scope, schedule, and budget the goal runs the risk of not actually meeting the business needs.

Compliance mindset rather than improvement mindset

Formal audits, especially when they are treated strictly by management, tends to lead to a fear-based compliance mindset. The unspoken message is "pass the audit, or else...". This is inimical to a mindset of continuous improvement, specifically the attitude of being willing to change the process when a better approach is found. In theory a process-centric mindset and a continuous improvement mindset can coexist - Toyota seems to be successful at this. But adding audits into the mix adds a rigidity or bureaucracy to processes that impedes continuous improvement. Worse is when people blindly follow process rather than question whether there is a better way.

Attitude of confrontation rather than collaboration

Formal audits almost always involve separate auditors external to the group being audited, and sometimes external to the organization. And these auditors are trained and motivated to find non-conformities - deviations from process. Auditors are not engaged to work with the group to understand what they have done and to help them do better. In fact, they are often instructed to remain aloof in order to remain impartial. This tends to lead to an attitude of confrontation rather than collaboration - an us-versus-them mentality - which means that any useful feedback that the auditors might have is at risk of being denied or ignored.

Discourages context-based expert judgement, creativity, and initiative

The Dreyfus model of skill acquisition explains the difference between beginners and experts. Having a clearly defined, step-by-step process to follow is essential for beginners, but has been demonstrated to actually reduce the performance of experts, who use their judgement based on the context at hand to determine what to do and how to do it.
Enforcing adherence to a common process also discourages creativity, initiative, and innovation. This can happen in a bureaucratic environment without audits, of course, but I believe that a regime of formal audits will exasperate the problem.

Limits of Assessment

Audits at their essence are about assessing a group with respect to some standard. This assessment has certain fundamental limitations due to the nature of audits, and over-reliance on audits risks developing an incomplete or inaccurate picture of reality. These limitations include:

Cannot assess intangibles

Audits only assess concrete items that are documented and completely ignore intangible aspects of work such as motivation, creativity, and initiative. (Some of these intangibles can be assessed by other 'formal' mechanisms - e.g. assessing motivation through surveys.) The corollary to the adage "you get what you measure" is that you risk not getting what you don't measure. This would not be a problem if the intangibles were not important. But software development is knowledge work, and the research is clear that people are by far the most significant factor determining productivity, far ahead of process. So relying on audits, which typically only look at process, ignores the more intangible, people factors.

Assessment is twice removed from objectives

Each group or organization has a purpose for existence, and objectives by which it tries to achieve that purpose. Audits do not assess this. Organizations put processes into place to support meeting these objectives. But audits, strictly speaking, do not assess this either. Audits assess the historical, documented evidence that the processes were followed. This means they are twice removed from the true objectives, which makes them an incredibly weak tool for helping an organization meet its objectives.

Audit results may be invalid

Audits suffer from four failure modes which can cause them to report invalid results:

1. The group is actually following the process being audited, but is not correctly producing the evidence.
2. The group deliberately deviates from the process in order to meet organizational objectives or in order to be more effective.
3. The group produces the documentation used as evidence for following the process without properly following the process. They will pass the audit, but there is a hidden problem. Rubber-stamping, where a review or approval is given without any actual check or thought, is an example of this.
4. The group properly follows the process and produces the evidence, but fails to achieve organizational objectives.

In conclusion, be very careful in how you use audits and watch out for the drawbacks. Maybe you should audit your use of audits :)

Achieving the full definition of done for a feature or release (often called being done-done) is surprisingly difficult. You may have heard the anecdotal rule of thumb that it takes 80% of the time to achieve 80% complete on a feature, and another 80% time-wise to achieve the remaining 20%. This is not due to using a strict definition of done. Anyone who has worked on an undisciplined waterfall project that has 'finished' coding the functionality and is now in test knows that sinking feeling of having defect after defect reported with no end in sight – and hence no predictability.

Using an imprecise or overly-simplistic definition of done will definitely impede predictability because you have only a vague idea of what the current state of your software is, and hence have high uncertainty regarding your progress to date.

Using a specific definition of done combined with the lean principle of minimizing work-in-progress greatly improves your knowledge of the current state of your software and hence your progress. Most of the uncertainty has been driven out by forcing work to done-done. This is not enough, however, to improve the predictability of your budget or schedule estimates for your outstanding work. You need to ensure your planned tasks and estimates include everything required to get to done-done.

On my last project, we tried just tracking coding tasks in the sprint plan. The remaining effort to get to done-done was treated as part of the general overhead that was used to calculate our velocity. This provided poor predictability in terms of both budget and schedule, especially as a feature neared code-complete. The estimate on the remaining coding tasks approached zero, but the time required for reviews, testing, and fixes remained roughly constant, thus exceeding what could be accounted for by velocity.

We then started to track most checklist items from our definition of done as individual tasks for each feature in addition to the regular coding tasks provided by the developer(s). This worked better, but we still suffered predictability problems as the feature went through review and test. Defects discovered had to be fixed, impacting the schedule and budget for the feature.

The next tweak we made was to allocate time up front for these fixes by adding an entry titled "Anticipated Issues" to each feature that provided an allocation of effort (budget, from which schedule was derived) that could be used to address defects, review corrections, poorly estimated tasks, and discovered work. The amount of effort allocated to this item was estimated per feature based on the size and complexity of the feature and the experience and quality level of the developers working on the feature.

Our most recent adjustment was to the front-end of feature development. Over several sprints, we noticed a trend that when developers started a new feature, especially one that was significantly new, they often had a day or even two where they did not make the expected progress on their tasks. We eventually determined that developers consistently had to spend time familiarizing themselves with the feature, especially learning the requirements and getting clarifications regarding how the feature was to be implemented, and that they virtually never allocated time in their tasks / estimates for this. So we added a new task to each feature named "Feature Clarification" to make this explicit.

By planning for all the components of our definition of done, we have achieved much better predictability. While our variance from our estimates per feature remained fairly high, the average variance across features was much closer to the original estimate, rather than being consistently over. As progress is made on a feature, we have much better estimates and better visibility into the outstanding work.

One solution to this problem that I have worked with and now recommend is to use a feature done checklist to track the completion of the definition of done for a specific feature. At its essence the checklist consists of the major elements of the definition of done listed as rows in a table with additional columns for the person verifying the completion of the item to enter their name and date. Here is a simple example:

You need to decide whether to use digital or printed checklists. I prefer using paper-based checklists for several reasons:

• I find it more meaningful to sign a piece of paper than to add my name electronically, so I tend to treat the completion of the checklist more seriously than I would an electronic form. This attitude may be due to my engineering background.
• A paper copy is more tangible and real. It can be waved around at a team meeting to celebrate the completion of a feature or posted on a team wall. It can be placed on a coworker’s keyboard in order to focus their attention on an outstanding item.

Evolving the Checklist

I have found it useful on occasion to evolve the basic feature done checklist beyond the team’s definition of done to provide support for the team’s development process. This is usually done as part of continuous improvement to resolve issues identified during retrospectives. Here are some examples:

• On one project we had issues with developers rushing into coding new features without fully understanding the requirements, so we added an initial checklist item for feature clarification to focus attention on the activity.
• For each item you can specify the role (e.g. developer, tester, architect) responsible for signing that it is done. I strongly recommend doing this for two reasons: it minimizes confusion over who signs off each item, and it minimizes the problem of having the developer of the feature quickly sign off all the checklist items without doing the necessary checking so they can say the feature is done.
• You can specify dependencies between the items. On one project we had a problem with people treating the items as a linear sequence of activities, so we defined dependencies to explicitly show that some activities could be done in parallel.
• You can add a feature start date to indicate when work began on the feature. This in combination with the feature done date allows you to calculate the duration of time spent on the feature. In lean terminology, this gives you the cycle time for the feature, which you want to minimize. When aggregated across the team, this defines the team’s overall throughput in completing features.

Checklist Challenges

I have encountered a number of challenges when using feature done checklists. Some of these issues are due to the actual checklists, but many are actually due to using a strict definition of done – the checklists just make the issue visible.

1. The checklist needs to be meaningful to the team - you must avoid the risk of it just becoming a form that people sign without doing the necessary work / checking that the item entails. (This is sometimes called rubber-stamping or pencil-whipping.) I have used many strategies to mitigate this risk:
   • Use a paper-based checklist rather than electronic.
   • Keep the checklist to a single page with as few items as possible for each role to complete.
   • For items involving ‘checking’ activities, assign these to roles / people whose primary responsibility is checking, separate from the developers doing the coding.
2. Extra effort is involved in getting a feature fully complete. This is often not accounted for in estimates, particularly if the estimate is provided by the developer. The time required for checking by other roles can be accommodated by having separate estimated tasks for these activities. What I find particularly challenging is accounting for extra time needed by the developer to resolve issues found in reviews or testing.
3. Having a through definition of done with multiple hand-offs of the feature to various roles will typically extend the duration of time required to complete the feature. The mitigation is to allow as many items as possible to be done concurrently. The best example is using pair programming as the means for doing the peer code review.
4. A single role / person with multiple review items per feature can end up becoming a bottleneck that ends up delaying feature completion. This is especially problematic if you are using a methodology like Scrum which focuses on getting features (user stories) done within the iteration – you tend to get a backlog of checklist items forming at the bottleneck near the end of the iteration which jeopardizes their completion.
5. One problem with using paper-based checklists is that they can get misplaced, or you end up looking for who has a form. This can be addressed by defining a location for checklists to be returned to. One option I like is to post them on a team wall, which provides the additional benefit of visibility.