How Would I Know How Badly We Are Losing Out Through Sub-Optimal Software Development?

Scope of this Report

Every company wants to maximize its profits while meeting its customer expectations. The primary purpose of software delivery is to provide a product to the customer that will validate a business idea, and ultimately provide value to the end-user. There must be feedback between the customer and the business, and this iterative process must be performed quickly, cheaply and reliably.1 The real question is how does an organization know whether its software delivery is performing at optimal levels?

This report considers the following topics:

  • What is sub optimal software development?
  • How would you know if your performance is sub optimal?
  • How do we measure for optimal development?

What is Sub-Optimal Software Development?

The purest definition of sub-optimal is “being below an optimal level or standard”. However, in the information technology (IT) organization, the development life cycle is characterized by multiple facets, each having its own ‘optimal level or standard’. Sub-optimal software development delivers less value than possible. Unfortunately sub-optimal, like beauty, is in the eye of the beholder and therefore can be very different based on context.

A sub-optimal development lif cycle is generally characterized by one of more of the following: cost overruns, poor time to market, excessive and/or critical defects, or low productivity. To any particular organization, one or more of these factors would signal sub-optimal software development.

How Would You Know if Your Performance is Sub-Optimal?

A sub-optimal software delivery process can manifest itself in a variety of ways. The most evident from an external perspective is customer satisfaction whether this is based upon an emotional response to the success or failure of the delivered software or an objective assessment based on testing or value for money. Mediocre quality or time to delivery will surely cause a response on the part of the consumer or client regardless of the reasons for the mediocrity. However, from an internal perspective, it has been observed that there are at least three scenarios that apply.

First we have the organization that doesn’t recognize that their software delivery process is sub-optimal. An example of this would be a company who is experiencing a solid bottom line and reasonable customer satisfaction. Or, a company leading the current technology wave and doesn’t see an immediate decline in their near future. In either case, while they may not be ‘sub-optimal’ in the usual sense of the meaning, they may not be the ‘best that they can be’. Since the first step towards improvement is to recognize there is an improvement to be made, there is a level of awareness that much be reached before this type of organizational environment can progress. In these two companies, the “awareness” may be to simply gain or keep the competitive advantage.

This next dynamic shows itself, not so subtly, when management doesn’t really want to address the software delivery process at all; they simply want the software delivered when they want it delivered.

How many times have we seen a situation where senior management has requested a software solution that has a fixed delivery date already attached to it? And they really aren’t interested in any type of response from the project manager unless they are told what they want to hear. In this type of management environment, the IT organization doesn’t invest much time in their delivery process because they don’t realize the power of good governance as a vehicle to properly manage the project and/or their customer’s expectations.

This third perspective involves an organization that wants to improve its software delivery capability but is unwilling or unable to make the resource investment to make necessary improvements.

Experience shows that lifecycle contributing factors can be numerous: an unrealistic schedule, ambiguous user requirements, the availability of appropriate resources, excessive defects and/or testing, etc. However, in this scenario, the visible issues may seem overwhelming or the root causes too obscure to be able to come up with a viable solution.

Regardless of how the sub-optimal performance manifests itself, the best way to determine if it exists or how pervasive it is, is by executing a benchmark. According to Financial Executive, benchmarking is one of the highest used and most successful management tools used by global senior executives. The purpose of a benchmark is to improve decision making and resource management in order to quantifiably impact a company’s bottom line.

“Benchmarking is the process through which a company measures its products, services, and practices against recognized as leaders in its industry. Benchmarking enables managers to determine what the best practice is, to prioritize opportunities for improvement, to enhance performance relative to customer expectations, and to leapfrog the traditional cycle of change. It also helps managers to understand the most accurate and efficient means of performing an activity, to learn how lower costs are actually achieved, and to take action to improve a company's cost competitiveness.”2

According to C.J. McNair and Kathleen H.J. Leibfried in their book, “Benchmarking: A Tool for Continuous Improvement”, some potential "triggers" for the benchmarking process include:

  • quality programs
  • cost reduction/budget process
  • operations improvement efforts
  • management change
  • new operations/new ventures
  • rethinking existing strategies
  • competitive assaults/crises

Any of the triggers above could certainly have been influenced by sub-optimal development.

In IT benchmarking, there are several options, any of which would be appropriate in addressing sub-optimal performance depending on the causal analysis desired. Horizontal benchmarking (across multiple teams), vertical benchmarking (across certain processes or categories), infrastructure benchmarking (data centers, networks, end-user support) or strategy benchmarking (information technology strategy or business-technology alignment) are some of the types used. The most common benchmark is the ADM software development benchmark.

The key factors that are addressed in an ADM benchmark are cost, time to market, quality and productivity. While benchmarking will identify good practices and successes, it is most beneficial at highlighting sub-optimal activities. These include inefficiencies and problems in methodology, staffing, planning, productivity, cost or capability across sizes, types & technologies. In addition, improvement actions are proposed. In many cases, a benchmark can also identify the probability of successful delivery against time, budget & quality targets – and propose alternative scenarios with higher likelihood. Other measures typically provided are your internal rate of return/ return on investment (ROI) and estimated tech debt – how much is being spent on the ratio of development to maintenance. Either can be key indicators of sub-optimal performance.

There are other benefits of benchmarking (listed below). Benchmarking …
... provides an independent, measurable verification of a team’s capability to perform against time and cost parameters by an objective 3rd party;

... signals management's willingness to pursue a philosophy that embraces change in a proactive rather than reactive manner;

... establishes meaningful goals and performance measures that reflect an external/customer focus, foster innovative thinking, and focus on high-payoff opportunities;

... creates organizational awareness of competitive disadvantage; and

... promotes teamwork that is based on competitive need and is driven by concrete data analysis, not intuition or gut feeling.

In summary, benchmarking would:

  • show you how you stack up against others and how you are performing internally;
  • act as a catalyst for change by setting realistic improvement targets; and
  • provide a path for the company toward optimal software practices.

How Do We Measure for Optimal Development?

Ultimately, the benchmarking exercise is to enable executive management to improve the performance of your software development using data-driven decisions to prioritize improvements. While the benchmark provides an evaluation of existing methods and outcomes against industry standard best practices, it also produces a gap analysis, producing recommendations for maximum return on investment (ROI).

The next step in the solution to software process optimization includes using a structured road map which includes the development of strategic goals based upon the benchmark results, and team analytics that are mapped to and support the strategic goals. From the road map exercise, scorecards and dashboards are developed for feedback to management.

The scorecard will combine an organization’s overall business strategy with the strategic goals set by the road map. These factors and the targets associated with them will reconcile to the desired state and alerts can be set up to identify situations whereby targets will not be met to enable future proactive actions. Generally, the scorecard is used to focus on long term solutions.

The formal definition of dashboards includes the identification and management of metrics within an interactive visual interface to enable the continual interaction and analysis of data. A dashboard is suited to a shorter cycle, or snapshot approach by providing varying types of visualizations to enable quicker decision making by showing charts, graphs, maps and gauges, each with its own metrics. A dashboard may be the visualization of the scorecard, or there may be hybrids of both.


Benchmarking and metrics modeling are the primary tools in recognizing and addressing sub-optimal development delivery to enable a company to become or stay competitive. By using the road map approach, the measurement and presentation of data for management use is key to recognizing and supporting optimal development processes.


  • 1Dave Farley on the Rationale for Continuous Delivery; QCON London 2015, March 8, 2015.
  • 2Reference for Business,
  • “Benchmarking: A Tool for Continuous Improvement,” C.J. McNair and Kathleen H.J. Leibfried, 1993.
  • “Measuring Success - Benchmarking as a Tool for Optimizing Software Development Performance”, DCG Software Value (formerly David Consulting Group), 2015.  “A Closer Look at Scorecards And Dashboards”, Lyndsay Wise; April 27, 2010.
  • “Why Can’t We Estimate Better?” David Herron & Sheila P. Dennis, 2013.
Written by Default at 05:00

Why Should I Have More Than One Technique for Retrospectives?

Scope of This Report

Retrospectives are part of most methodologies, even though there are many different terms. For instance, most waterfall frameworks call them post implementation reviews or postmortems. Each methodology focuses on different nuances. Agile, as a macro set of frameworks, has more aggressively embraced retrospectives than waterfall or iterative frameworks.   

Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese for improvement, often interpreted as continuous improvement). They should be focused on discovering what will make the team or organization deliver more value.  

Brian Wernham, in Agile Project Management for Government noted the UK DirectGov project used retrospectives to mold how the worked in order to maximize delivery productivity. While many retrospective techniques posit the questions “what worked well” and “what did not work,” the real reason to do any retrospective is to identify, agree on and plan for what can be done better.  
The exact process any team uses is a reflection of the technique the team wants to use, what works in the organization and the specific team situation. For example, the timing of retrospectives varies significantly depending on the framework and the organizational culture.  Most waterfall projects do a retrospective at the end of the project (or release), while Agile projects typically do retrospectives at the end of every sprint, at each release, at the end of the project and occasionally on an as needed basis.  In Agile, retrospectives occur when change can actually be applied to the project to impact the current delivery.


The power of a retrospective to improve a team’s ability to deliver business value is hard to deny. Given the demonstrable power of the technique, why does it occasionally fail to live up to expectations? 


Ritualization can dramatically affect the value of retrospectives. Ritualization can cause the team or organization to enter a downward spiral of disillusionment that will inevitably end with the abandonment of the technique.

The ritualization of retrospectives occurs when the process becomes more important than (or at least as important as) the results.  There are two typical reasons that cause ritualization: overcommitted teams who don’t have time to reflect and boredom (wake me up when it's over). Gil Broza in The Human Side of Agile notes that” Works Well and Needs Improvement format gets really old quickly.” Teams that are so overburdened and can’t find a mechanism to get un-overburdened will always stay that way (a “Catch 22”). The ritual of the retrospective will usually be fulfilled so that they team can start planning the next sprint or iteration.  In essence, they need to check the process box so they move to the next step.  

The Scrum Master or coach needs to help the team address the root cause of the problem, whether that is team-driven over-commitment (taking too much work) to being told to take too much by management.  If a team is in an over-committed position more than occasionally, the Scrum Master may be part of the problem. That means that outside coaching is needed. If the root of the problem is technique boredom, the Scrum Master or another team member should learn another technique (such as timelines, the Sailboat, de Bono’s Thinking Hats or the 4 L’s).  All Scrum Masters should know at least nine techniques for retrospectives. 


A basic process for a typical Agile, end-of-sprint retrospective:

  • Set Up: First, create a safe atmosphere (review Norm Kerth’s Prime Directive with the team). Then ground the team by focusing on the current sprint’s results (for example review the Burn-down Chart or have the team develop an annotated sprint timeline). Time box this part of the retrospective to no more than 20 minutes for a two week sprint.
  • Idea Generation: Encourage the team to dig in and capture the details.  For retrospectives focused on process or flow, use sticky notes to brainstorm, followed by mute mapping to group (affinity diagraming). For team or personnel issues, use storytelling. For example, have subsets of the team describe a fictional scenario based on real life problems and how they would solve the problem. Consider direct discussion as an alternative. This step should be time boxed to 30 minutes for a two week sprint.
  • Insight Development: Once the idea generation step is completed, the team reviews the data and comes to a consensus about what it means. One method of analysis is to look for patterns and to determine if there are trends in this stage.  The goal is to recognize if there is a problem so you can start to resolve it.
  • Identify An Improvement Objective: In many cases a team might have identified a number of ideas for improving their productivity. Focus on the top one or two actionable big wins. The rational for not fixing everything is first that the time need to fix the problem will come from the team’s capacity to deliver business value (there is only so much capacity that the team has at its disposal).  Secondly, if the remaining issues are really problems after the one or two most important have been dealt with then the team can decide to address them during the next iteration. Also, trying too many changes at once makes it hard to track cause and effect.  This continuous incremental process improvement is one reason team productivity, aka velocity, typically increases from iteration to iteration.  After the team selects the issue (or issues) to be tackled, have them add it to the next sprint backlog so that it gets addressed.  This step should be time boxed to 30 minutes for a two week sprint.
  • Wrap-up: Spend 5 – 10 minutes reviewing the session so that the next retrospective will be even more effective.

Retrospectives are a tool that the team uses to identify what they can do better.  The basic process - making people feel safe then generating ideas and solutions so the team can decide on what they think will make the most significant improvement - puts the team in charge of how they work.  When teams are responsible for their own work, they will be more commitment to delivering what they promise. The retrospective process is focused on increasing the team’s capacity, rather than trying to generate lessons learned for the next project.

Even though there are many different techniques for executing retrospectives, many teams find one or two techniques they like, and then they ride that horse until it collapses.  Every Scrum Master and team should have a broad array of retrospective techniques, such as the sailboat technique, the Four L’s or the timeline.  This provides at least two benefits. First, knowing many techniques means that you can match the technique to the particular teams. For example, many techniques use physical sticky notes, which are difficult for distributed teams. So, the Scrum Master needs to know that you can substitute an on-line mind-mapping tool for sticky notes.  Second, having a wide range of techniques (and using them) is a formula for beating technique fatigue and the resulting obstacles. 

List Generation Techniques

List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  We discussed the basic Affinity Diagraming technique above.
Another technique in the listing category would be the “Sailboat” technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  We discussed the basic Affinity Diagraming technique above.

Another technique in the listing category would be the “Sailboat” technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it encounters resistance which slows its progress. Examples of resistance might include conflicts for needed resources or conflicting organization goals. Here is the process:

Set-up: Start by drawing a picture of a sailboat in the water on your white board or flip chart. Explain to the team that some things push forward, like the wind, and some things slow your progress down, like an anchor.

Idea Generation: Ask the team to identify what those items were.  List one item per sticky note, which are then placed on the boat.  As a facilitator, continue to tweak the seed questions you are using to keep the team thinking about the sprint from different angles.  You are done when the team is done.

Insight Development: Have the team review the data and group ideas based on how they see the relationships between individual ideas. Techniques like Mute Mapping (grouping without talking) help to maximize team participation while minimizing the chance of a single person dominating.  Once the grouping is done, ask the team to name each group. This helps to cement the group’s understanding of the groupings of ideas that they have generated.

Identify An Improvement Objective: Select a group or specific idea to fix.  There are a number of techniques to select the improvement objective. Discussion followed by group consensus is one method (use this when it is apparent that the group is close to consensus).  Another method is to vote using dots or post-it flags. In this method give each member a fixed number of flags and then ask them to vote (they can use all votes on one item or spread them).  The item or group with highest number of votes gets fixed first.

Examples of other listing techniques include:

The Four Ls – Use four categories: liked, learned, lacked, and longed for to generate ideas. Write these titles on four flip charts and place around the room.  Have each person silently generate ideas based on those categories.  When the team is done (i.e. everyone stops writing) have the team place their ideas (written on sticky notes) on the appropriate flip chart. Once the team has come up with their lists, identify the improvement objective, usually from the lacked or longed for category.

What Went . . . – Use four flip charts, put one of the following titles on each flip chart: what went well, what did not go well and what should we do more of and what should we do less of.  Brainstorm ideas to put on each flip chart.  Put one idea or statement on each sticky.  Depending on the group, this method can be done non-verbally (everyone puts their ideas on a set of “stickies” like the Four L’s) or have the team write ideas down and then shout them out (more akin to classic brainstorming). Insight development and identifying the improvement objective would follow a similar path to what was described above.

There are many other listing techniques each using a different set of seed questions (e.g. What worked well? or What would you like to do more of?) or different metaphors (e.g. sailboat, motorboats or trees). The questions or metaphors exist to help the team focus their discussion.  The metaphor or seed questions that are used need to make sense to the team’s culture, and also solicit areas that they are concerned about or can be improved. The Scrum Master or facilitator needs to use their observations about the team to select the retrospective technique that will provide the greatest benefit. All of these techniques can work, selecting which you will use is matter of team culture.

Other Techniques

There are other, more specialized techniques like the Timeline Retrospective, which is useful for long-running releases or in projects were a retrospective has not occurred in recent memory. These techniques deal with more complex issues than can be tackled using simple lists.  These more complex methods can also be used to spice up a more basic fare of listing techniques to keep teams involved and interested in the retrospective process.

These techniques are more complex to execute.  Let’s explore a few examples of this class of retrospective.

The Timeline Retrospective uses the following process:

Goal: The Timeline Retrospective technique develops a visual overview of the events that occurred during the period under investigation.  This technique identifies and isolates the events that impacted the team’s capacity to deliver over a set period of time. It uses distinct colors to identify events (avoid typical red – green colors as color blind participants may have difficulty).

When To Use:  The Timeline Retrospective is useful for refreshing and re-grounding the memories of team. Other circumstances in which this may be a useful technique:

  • If there have not been any intermediate retrospectives;
  • To provide context to program-level (i.e. multiple projects) retrospectives;
  • If the team has not been working on the project over the whole life cycle, and
  • An end of project retrospective.

Set Up: Draw a timeline that represents the period since the last retrospective on a white board (or several pieces of flipchart paper).  Make sure there is room above and below the line.  Secure dry erase markers in a few colors and sticky notes in three colors.  The three sticky note colors will represent:

  • Blue represents good events;
  • Yellow represents significant events that are neither good nor bad, and
  • Red represents problem events.

Use the colors that you feel the most comfortable with and that you have in sufficient supply.

The process is as follows:

  • Have each team member silently write down on sticky notes the major events, from their perspective, using the color code from above.
  • Have each team member put their events on timeline chronologically, placing positive events above the timeline, neutral on or near the timeline and negative events below the timeline
  • Throw out duplicates.
  • Have the team select someone to walk through the final timeline.
  • Using the dot voting technique (provide each team member with three dots) rank the event that slowed the project down the most to date.
  • Identify tasks and actions that could be taken to solve the problems. Pick the top two or three.
  • Have the team tell the story of the project for the next sprint or release, if they took the identified actions. This will help validate the choice of the proposed changes.

Another example of non-list retrospectives is the 6 Thinking Hats Retrospective (based on De Bono’s Six Thinking Hats).  Use this type of approach when the team has experienced significant challenges, has not established norms on how to interact or tends to be dominated by one or two personalities.  In this technique, the team uses a structured approach to discuss the period since the last retrospective.  The team “wears” one of De Bono’s “hats” at a time, which means all participants talk about a specific topic area at a time. Each hat represents a particular way of thinking.  Using the hats forces the team to have a focused discussion (this is called collective thinking in the literature). Until you are comfortable with this type of technique, use a facilitator. The facilitator should ensure that the comments are appropriate to the “hat” that is currently being worn. Here is the order of the “hats”:

1. Blue Hat (5 minutes) – focus on discussing session objectives.
2. White Hat (10 minutes) – discuss or identify FACTS or information since the last sprint (e.g. we had a hurricane during this sprint).
3.  Yellow Hat (10 minutes) – talk only about the good things that happened since the last retrospective.
4. Black Hat (10 minutes) – talk only about the bad things that happened since the last retrospective.
5. Green Hat (10 minutes) – talk only about ideas to solve the identified problems or ideas that would add more significant value in the Product Owner’s perception.
6. Red Hat (5 minutes) – Have each team member come to the white board or flip chart and write two emotive statements about the project during this period. Do this fast and with very little preparation. You want gut reactions.

Finally, have the team review the emotive statements to identify clusters of comments or trends that can be combined with the issues in green group.  From the identified issues pick one or two actions that will improve the ability of the team to deliver to add to the backlog for the next sprint.

Other techniques in this class include:

Emotional Trend Line – This is many times combined with the Timeline technique. It provides an estimate of the team’s emotional state since the last retrospective.

Complexity Retrospective – Draw a complexity radar plot with at least five axes. Engage the team to determine what each axis should be labeled (e.g. data, workflow, code, business problem) and then engage the team to rate each axis.  If an axis is rated as complex ask the team to identify actions to reduce complexity.

Non-list based retrospectives are generally more complicated to apply due to the formal structure they use to guide teams toward discovery.  For example the De Bono’s Six Thinking Hats will require active facilitation (at least until everyone is comfortable with the process).  These techniques are generally used to address special or specific circumstances.  The structure of the techniques has been designed (or in some cases these techniques were adopted from other disciplines) because they help to focus the retrospective participants on a type of problem. The goal of any retrospective, list or non-list, is to help the team to discover how they can learn to be better during the next iteration.

Coaching a Retrospective

Facilitation skills, choice of technique and the tools that are used, in that order, will impact the effectiveness of retrospectives. The degree of team distribution will cause the degree of importance of the attributes to vary. For instance, distributed teams will have to lean on communication tools to a greater extent.

At their heart, all retrospectives are social exercises. Even in well-honed teams it is an ongoing challenge to keep team member talking and sharing in a manner that will convey information without damaging relationships. As Naomi Karten pointed out in her interview on the Software Process and Measurement Cast, there are a relatively high proportion of introverts in IT who need help in order to be drawn out. The facilitator’s skill at getting people to interact is more important as the degree of team is distribution increases. In distributed teams, the facilitator needs to find ways to make the team’s interactions more personal. For example, making sure everyone talks and that location bias does not set in. An interesting technique to defeat this issue is to pair individuals from different locations as homework for the retrospective. In one example DCG facilitated, a Scrum Master asked each pair to collaborate and identify five ideas to improve collaboration, while another time (with different sets of pairs) the Scrum Master asked the groups to do a five minute overview on an upcoming local holiday. The goal was to make sure the locations were talking and that the whole team was exposed to the different cultures on the team, which fosters deeper communication.

Different retrospective techniques will evoke different responses from participants. For example, a timeline retrospective will focus on events. A classic list generation-based retrospective will focus on process. Picking the right type of retrospective gives a facilitator the chance at opening up the team. The technique selected for a retrospective is generally a balance between the focus and technique satisfaction (i.e. how many times you have used the technique as over use causes boredom). When coaching long-term projects, teach the team a variety of techniques and then let them select the technique that they want to use. Remember to add techniques or remove techniques from the team playbook as the situation warrants.


Every retrospective requires some sort of tool. Tools can be as simple as a white board and markers or as complex as mind-mapping and screen-sharing software. When a team is distributed, screen sharing and teleconferencing/videoconferencing tools are necessities. The combination of technique and level of team distribution will influence tool selection. Likewise, tool availability will influence technique selection. For example, use a mind mapping tool and screen sharing when executing a listing retrospective for a distributed team so that each location can see the ideas and participate. If the distributed team could not use those tools, you will have to find a different approach. Generally the technique defines the toolset, but that is not always the case. When everyone is in the same room sticky notes are great but when team members are teleconferencing into the retrospective electronics are required.

The retrospective can’t become ritualized to the point that it lacks meaning.  Each retrospective needs to provide a platform for the Agile team to reflect on their performance and to determine how they can achieve more. This is a team activity that requires a free flow of conversation and ideas in order to maximize effectiveness. That means someone needs to facilitate the process and police the boundary.  No team is perfect and all teams can learn and improve on a continuous basis.  Most obstacles to effective retrospectives are solvable with a bit of coaching and education, if you recognize the obstacles before you abandon the technique. Facilitation skills, retrospective techniques and tools are all important for an effective retrospective. The technique is driven by needs of the team. The coach/facilitator needs to be aware of the needs of the team and the proper tools to facilitate the technique. If they are not available, pick another technique. However once the retrospective begins, facilitation skills are always the most important factor. Even with the best technique and tools, retrospectives are all about the people.


  • Agile Project Management for Government, Brian Wernham, Maitland and Strong, 2012, P 195
  • Norm Kerth’s Prime Directive,
  • The Human Side of Agile, Gill Broza, 3P Vantage Media, 2012, P. 172
  • The Agile Mind-Set, Gil Broza, 3P Vantage Media, 2015, 149
  • De Bono’s Six Thinking Hats,

Download this Trusted Advisor report here.

Written by Default at 05:00
Categories :

Digital Transformation of the Enterprise for SMAC: Can Scrum Help?

Scope of this Report

In this paper, we consider the impact of the digital transformation on software development and whether the Agile Scrum approach being used by many organizations to help the software development teams respond more effectively and quickly to business demands can be used more widely in the organization for digital transformation.

We focus on what has been termed “SMAC.”  The acronym derived from the names for what many believe to be the driving forces of the latest wave of digital transformation:

  • Social media
  • Mobile
  • Analytics (or “big data”)
  • Cloud

It is our belief that Agile principles and methods can be applied throughout an organization to deliver effective digital transformation. 

Why do we need to change our approach for Digital Transformation?

Today’s software development, heavily influenced by SMAC, is being driven much more by the needs and capabilities of customers (users) who have been empowered to install, try out and accept or reject incremental functionality throughout their day, inside and outside of work.  This is the critical change we see in enterprise software development compared with the last 10 years or more.

Historically, IT has not been focused on delivering value to its customers and though that’s a little harsh, we can certainly say that software development has often been driven by technology and completion date.  Put another way, prioritization decisions within IT departments have been more based on: How difficult is the project?  How many and which resources will the project require?  Who is shouting the loudest to get it?

Organizations don’t have a choice.  As an HMG Research blog post in August 2015 pointed out, “As external customers continue to increase their use of digital touchpoints to research and acquire products, companies need to be where their customers are and provide them with the types of experiences that delight customers and keep them coming back.” It’s simply no longer possible to avoid the need for organizational agility in order to recruit and retain customers.

For digital transformation, software development organizations must prioritize their projects, stories and task by customer value.  They have started to do this.  It is not easy but there are ways to make it easier (e.g. Value Visualization).  HMG quoted Red Hat’s CIO Lee Congdon, "The world is shifting from an industrial age to an information age. It's no longer enough to produce great products. Today, companies need the skills and capabilities to connect with their customers. They need the ability to manage their supply chains in real time. Traditional companies are becoming digital companies, and that's a fundamental change,"   Charlie Asaujo in a private conversation with the authors takes this point further, “… In 5-10 years, 80% of what is in-house today will move out.  The transition will be hard work.  IT as we know it is dead.  Managing the value supply chain will be the future for developers wanting to stay in the business.”

The software development teams in organizations have been able to respond to the need to deliver incremental value to their customers quickly and continuously by adopting the principles of agile and the methodology of scrum.  To quote Alan Cameron of DCG, “… scrum can cut through the ambiguity cloud surrounding many traditional projects to provide a clear, frequently renewed focus on value delivery and customer satisfaction.”  

However, the biggest challenge of implementing Enterprise Agile for software development is the need to change the organization outside software development, so that the whole body becomes focused on customer needs and demands.  Some of the need for change on the periphery of software development, we already knew about.  Something as fundamental to Scrum as daily builds require a significant rethink in some organizations.  In early –stage scrum implementations it’s not unusual to be told that the IT team require, say, 3 weeks notice to set up the hardware for a new test environment.  

How can Agile help Digital Transformation?

So what are the principles that drive an Agile business? We have suggested elsewhere that the Agile Manifesto can be adopted for digital transformation with small changes. Therefore, with due deference to the authors of the original (see “Sources” for attribution), we have amended the manifesto (in italics below) in a way that can be applied to digital transformation, while keeping as much of the original wording as possible:

Manifesto for Agile Digital Transformation
We are uncovering better ways of delivering digital transformation by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working customer value over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There are twelve principles that support the Agile Manifesto.  These too can be modified for applicability to digital transformation:

1. Our highest priority is to satisfy the customer through early and continuous delivery of customer value.
2. Welcome changing requirements, even late in the transformation journey. Agile processes harness change for the customer's competitive advantage.
3. Deliver working customer value frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and digital transformation agents must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a digital transformation team is face-to-face conversation.
7. Working customer applications are the primary measure of progress.
8. Agile processes promote sustainable digital transformation. The sponsors, digital transformation agents, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to customer value and best practice enhances agility.
10. Simplicity – the art of maximizing the amount of work not done--is essential.
11. The best digital transformations emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

We have discussed this topic before on our website and there has been some justifiable push back against taking too simplistic a view of adapting a methodology developed to solve a set of challenges in one context to solve a different set of challenges in a different context.  For example, on our blog, Ally Gill said, “…When we start talking about business transformation we're onto a whole different topic and a completely different set of people's needs which must be addressed. More importantly, the complexity of an organization needs to be considered as a critical factor - something that is less of an issue in developing software.”  We agree and Arpan Pal has highlighted six areas of complexity (in the context of the “internet of things”) where the needs of digital transformation initiatives overlap with but extend beyond the considerations of simply developing the solution software: 

  • Scalability
  • Privacy
  • Affordability
  • Context-Awareness
  • Ease of Development
  • Security

We believe that the modified manifesto is a valid statement of intent that can be used to drive digital transformation, despite the acknowledged difficulties pointed out above.

Why Scrum?

While the agile philosophy puts customer satisfaction and the delivery of customer value among the highest priorities for the development team, scrum is a great technique for ensuring that things can actually be delivered quickly and often in a changing environment.  This is how the scrum teams in software development can help whole organizations to make these changes.  

Scrum succeeds by establishing a disciplined process around solving just enough of the customers’ needs to enable the customer to give more feedback and who better to coach and mentor the teams doing the transformation in the rest of the organization than the software scrum teams themselves.  

In our current world where customers are continuously exposed to new ideas and new capabilities, the digital transformation within any organization must be driven by fast responses to customer feedback.  Scrum, within the context provided by the agile manifesto, is the ideal controlled, disciplined but highly responsive methodology to implement digital transformation.

Most elements of Scrum can be applied to transformations outside software development.  Product Backlogs (or maybe Transformation Backlogs?), tightly time-boxed Sprints (or iterations), Product
(Transformation?) Owners, Scrum Teams, Sprint Reviews and Sprint Planning Meetings are all pretty much essential.  Daily Standups can be overkill on more strategic initiatives but certainly some sort of progress and impediment reporting is appropriate on a regular schedule during the sprint (weekly on a 4-week sprint works well).  Scrum Masters can be a less important role perhaps combined with Product Owner depending on the team.

For us here at DCG, this is no theoretical proposal because we use scrum techniques ourselves for implementing strategic initiatives.  We use scrum in our consulting contracts to help our clients manage their own transformations.  For example, for a client needing to introduce better IT Governance and Measurement, we used an agile approach to help the senior management team identify and prioritize a program backlog.  We were happy when they concluded that the value delivered in the first six transformation sprints was sufficient and that no further sprints were needed.


Applied with care, digital transformation initiatives can benefit from an approach based on the, slightly modified, principles of the Agile Manifesto and Scrum.  Agile tells us to deliver
working customer value frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  Scrum establishes a disciplined process around solving just enough of the customers’ needs to enable the customer to give more feedback.   

Customer value-focused organizations, which are Agile throughout are best placed to meet the challenges of digital transformation in the age of SMAC.


  • Value Visualization,
  • HMG Research,
  • Alan Cameron, blog post Monday May 18, 2015,
  • Ally Gill May 19, 2015 - responding to Alan Cameron blog post of previous day, cited above.
  • Arpan Pal, writing in IEEE’s IT Pro (May/June 2015)
  • Better IT Governance and Measurement,
Written by Default at 05:00

What is a Product Owner and Why Do I Need One?

Scope of this Report
“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone.” - Ken Schwaber, “Scrum Guide”

Scrum defines three basic roles1 within a Scrum team: developers (including testers), a scrum master/coach and product owner. Each of these roles is critical for delivering value effectively and efficiently. The product owner role is deceptively simple. The product owner is the voice of the customer; a conduit to bring business knowledge into the team. They define what needs to be delivered to support the business (or at least finds out), dynamically provides answers and feedback to the team and prioritize the backlog. From a business perspective, the product owner is the face of the project.
This essay will highlight the role of the product owner and why something that seems so easy is generally the hardest role on an Agile team.

The job description of a product owner is fairly straightforward. Their job is to act as the voice of the customer, prioritize the backlog, answer or get answers to the team’s questions and accept/reject the work that the team generates. However the devil is in the details. Understanding the nuances of applying the role is important to successfully function as part of an Agile team.

The Role: Leader or Drill Sergeant?
A leader directs and coordinates activities based on their vision of the future. In Agile projects the product owner provides their vision to the team what they aren’t is drill sergeants. Leaders also need to ensure that a team’s goals stay undiluted by extraneous priorities. A drill sergeant is colloquially viewed as a micromanager who trains team members by drilling them on exactly how each task is to be accomplished. The role of product owners evolved out of the roles of project manager, business subject matter expert (SME) and project sponsor from the waterfall environment. In the waterfall model of projects, each of these roles provided different levels of direction, management and leadership. The project manager is the administrator. The SME provides information on what is done today and what they will need in the future. The sponsor’s role includes providing resources, framing the scope of the project, providing direction as the project moves forward and to demand that the project delivers. The sponsor and the project manager are generally the outsiders that exhort the team into action . . . they act as drill sergeants. While classic project management techniques often include a role similar to a drill sergeant, Scrum and other Agile frameworks actively eschew this role. The Agile principle that states that “the business and developers must work together daily” suggests shedding the approach of an outsider exhorting the team, and implementing the concept of the product owner as leader within the team.

In an Agile project the product owner’s roles include:

  • Owning and prioritizing the product backlog,
  • Providing product vision2,
  • Involving customers, users, and other stakeholders, and
  • Collaborating with others on the team.

The qualities of a product owner are very different from the attributes of the screaming stereotypical drill sergeant. The most critical behavior is often collaboration with others in the business and with the development team: the act of working together to produce or create an outcome. The behavior of collaboration requires the product owner to abandon the role of drill sergeant and focus on being a leader.

The product owner leads by shaping the backlog and collaborating with their fellow team members. The product owner will be more successful if they embrace the principle of the business and developers working together in collaboration, making them more of a leader than a drill sergeant.

If not a drill sergeant then perhaps the product owner is a tour guide. If you have ever visited a major tourist site you have seen tour guides shepherding groups of camera-toting tourists. It is easy to see the tour guide role as that of a leader. A typical tour guide plans the logistics of the tour, herds the tour group ensuring everyone is moving in the same direction and implements the vision of the tour planner to deliver value. The goal of our tour guide is to make sure the team begins and ends together, that no one gets lost and the goal of the tour is accomplished. The role provides administrative and tactical leadership to the tour group. But, the tour guide is not playing the role of the product owner. The whole team acts as its own tour guide in Agile based on the principles of self-management and self-organization. In Agile projects the product owner provides visionary leadership. Tactical leadership and administration, the tour guide role, is generally diffused across the entire team.

The arrangement of roles is facilitated by the application of two Agile Principles3. The first principle directs the business and IT personnel to work together on a daily basis. The second principle in play here is that of self-organizing teams. For example, one mechanism that spreads the role of tour guide across the team is the backlog prioritized by the product owner. The backlog represents the vision in bite-sized chunks that the team can then plan and execute. Another example of tactical leadership that the team drives is the standup meeting, in which the whole team acts as cat herders. So, on an Agile project, who is the tour guide that herds the team toward the product owners vision? The answer is that role is spread across the team and that Agile techniques facilitate making sure that we start and end in the correct place.

As we have noted, Scrum calls for three macro roles on every Agile team. The concept of a stable team is important in Agile (and should be in EVERY framework and method) in order to build collaborative capability and trust. Members of the team must be part of a team on a consistent basis to
value delivered from the team. Product owners are no different when it comes to team membership and cohesion.

Product Owners Are Part of the Team: Embed Them
The twelve principles of the Agile Manifesto provide the basis for interpreting and implementing any Agile technique. One of the hardest principles for many organizations to adopt is: Business people and developers must work together daily throughout the project.

Many implementation approaches have been designed to minimize the organizational inconvenience of this principal, such as using proxies for the business or abandoning the principle altogether. The goal is to involve the business users (also known as the product owner in Scrum) so they can act as voice of the product. Fully embedding business personnel into the project team is often considered the most radical approach. However, is embedding really an absolute, radical solution or just an extreme statement used to generate a conversation? Embedding is a powerful tool, that changes the balance of power inside of an Agile team and brings business personnel inside the boundaries of IT as active participants rather than just sponsors or reviewers. The change required to embed product owners means changes in both IT and in the business department the product owner typically works in. The benefits need to outweigh the costs.

Embedding removes the product owner from their normal job and makes them part of a project team. This has an organizational cost, which includes the cost of replacement even if replacement just means that other colleagues have to pick up the slack. A second and more personal cost occurs on long-term projects. Embedded business personnel need a return path back to the business, or a path into the more technical world, or they risk career failure. Other costs may well include opportunity costs for work or projects that the product owner might have been involved with if they were not on a project team. For example, in an organization DCG reviewed in the recently, a lead sales person participated on a critical product development project as a product owner. During the period he was involved, sales from his territory were “off” by more than 50%. The cost of his participation was lost revenue.

The costs of embedding can be high, but the benefits are generally equally large. The benefits of embedding the product owner are generally a reduction in development time as the team waits for answers, a greater focus on delivering important functions and features earlier, a reduction in rework based on faster feedback and often a better connection to the business. The benefits on embedding can be summarized as reducing the cost of development, faster time-to-market, improved quality and customer satisfaction.

Should every project have embedded business personnel? No, not every project requires embedded business personnel, however, most important projects should. Striking the balance between cost and value is part of the art of implementation. While this technique should be the default in most organization, programs and projects, DCG would not suggest that it be applied without an evaluation of the cost and benefits.

Getting the balance wrong or failing to implement the product owner role has real consequences.

Why Agile Projects Fail: Lack of Product Owners
Failure to correctly address the product owners role creates a myriad of problems for Agile projects, each of which can and often have led to project failure. The product owners role can be difficult to implement. The potential problems4 include: not adequately integrating business representatives into the team, reinforcing the perceived divide between IT and the business, and substituting proxies for business involvement. Each Agile team needs a product owner, or they risk delivering the wrong functionality.

Not integrating business knowledge and decision-making capacity (i.e. the product owner) into the project will lower productivity, velocity and the quality of any project. Just think of the best projects in which you ever participated. Generally, one of the reasons was that a sponsor, lead subject matter expert or super-user, was always around providing input and making decisions. In effect, they were acting as a product owner. Project teams make many decisions, large and small, on a day-to-day basis. The choice that the team has is either 1) to make the decision using the knowledge at hand and risk being wrong, or 2) to wait until they can gather more information. The pressure to deliver now means that most teams will absorb the risk and the rework. Having a product owner close at hand makes development quicker and increases quality.

Not implementing the product owner role reinforces the divide between IT and the business, thus reducing the efficiency of communication. There are many excuses for why organizations implementing Agile don’t involve the business in projects, but the one that DCG sees the most often is that the project team doesn’t ask. Excuses for not asking we have heard include: “the business won’t participate because they are too busy,” or “they are not interested” or “they don't want to have anything to do with us”. Remember that the goal of any project (or at least any project that should be done) is to deliver tangible value based on a need stated by the business. Therefore business personnel have a concrete reason for participation; they should make sure their investment pays off. The first step in the process to involve the business as a product owners is to ask the potential product owners and their managers to participate, making sure they understand the role and why involvement is so important.

The use of proxy product owners is a copout, and in most cases represents a firm signal that Agile should not be used. Proxy product owners are rarely the right answer, because they can’t commit and make decisions for the business slowing the development process to a crawl. One DCG client implemented a hard and fast rule that if a project did not have a product owner, then the project was put on hold until it could be started using a standard project management framework. Without the infusion of business involvement in the day-to-day operation of the project, the organization decided that a classic deliverable-based framework was more appropriate.

The product owner role is critical to linking Agile development teams to the business. Product owners bring business acumen to the development team. That reduces rework and increases the overall acceptance of the product. Choosing not to implement the concept of product owners or to use proxies is rarely the right answer. Bite the bullet and talk to the business users about how they can integrate into the process. Appeal to the fact that it is their money being spent and their involvement would maximize value. If the business can’t commit to participating as product owners, consider not using Agile mechanisms (like Scrum) and instead begin the lean to Agile transition with techniques like Kanban. Kanban is a flow based method that does not require any process changes (at least initially) or role changes.

The Product Owner Is A Role Unto Itself: Don’t Share It!
The role of product owner is critical for ensuring that the rest of the business and the IT team work together effectively. It also requires significant effort on a daily basis. The product owner provides vision, mentors the team, answers questions, makes decisions about the product, communicates with the broader organization, negotiates resource contentions, coordinates business interaction and serves as a liaison to leaders. In short, the role is difficult and complex. So much so that it has been suggested on more than one occasion that it is the most challenging role in Scrum. The product owner should not play any other role on an Agile team5. There are many potential pitfalls in Scrum, however potentially the most destructive and easiest to avoid is the overworked product owner. Overworked product owners are less effective.

What happens when someone is overworked? Sooner or later they will neglect something and cut corners. Some work gets jettisoned as they try to bring their life back to equilibrium. Overworking the product owner may result in non-attentiveness to the team, neglect of grooming the product backlog, and unavailability or missed meetings. It is possible that the product owner will neglect their day job, however, basic psychology suggests that people tend to focus first on that portion of their job that is most important to their long-term career. Unless product owners are focused specifically on a project they will tend to neglect the product owner role (pleasure/pain response6).

The product owner role is challenging; to perform it in a manner that is effective requires effort and focus. Organizations need to ensure that product owners have enough of their time allocated to the product owner role. Work generally needs to be taken off their plate. The rest of the team needs to support the product owner so that obstacles are minimized. Avoid Overworked-Product-Owner Syndrome and make sure the person that is playing the product owner role has the time needed to focus on the project rather than view the project activities as work they can avoid.

Product owners are an integral part of most Agile teams. They bring their business acumen to the team and act as the voice of the customer. Teams without a product owner who is close at hand will either make decisions based on their knowledge of the situation or wait until they can talk to the product owner or other stakeholders. Time is money both in terms of waiting for a decision and delay in getting feedback. Product owners provide vision and leadership to an Agile team. Vision and leadership are not improved by distance or scarcity, so keep your product owner close at hand.

Product owners are an integral part of most Agile teams. They bring their business acumen to the team and act as the voice of the customer. Teams without a product owner who is close at hand will either make decisions based on their knowledge of the situation or wait until they can talk to the product owner or other stakeholders. Time is money both in terms of waiting for a decision and delay in getting feedback. Product owners provide vision and leadership to an Agile team. Vision and leadership are not improved by distance or scarcity, so keep your product owner close at hand.

1, August 20, 2015
2 Mike Cohn,, August 20, 2015
4, August 20, 2015
5, August 20, 2015

Written by Default at 05:00
Categories :

Why Do We Never Have Time to Test?

(You can download this report here.)

Scope of this Report

This paper discusses the time constraints of testing, its impact on several testing stakeholders, and possible ways to mitigate this problem. It includes:
Statistics on testing length.

  • Who are some of the stakeholders for software testing?
  • What kinds of delays do testers frequently face?
  • Making more time to test.

Testing Length

The following estimate of an average testing length is drawn from The Economics of Software Quality, by Capers Jones and Olivier Bonsignour, which is based on the authors’ clients average test cases per function point and time per case. The calculation is based on the types of tests used by 70% or more projects, and provides the following average for a 100 function point project. This assumes a thorough test of the system using an appropriate number of test cases for the size of the project.

Testing Times

Therefore, between one or two months might be spent for the testing of the sample project. Note that a 100 FP project is relatively small. Projects of ten thousand function points or more, especially for new software, are not uncommon. Testing these larger projects to the same degree could take a year or more, assuming testing time increased in a linear fashion. Testing time actually increases faster as the project grows larger. To completely test all combinations of possible processes for very large projects will take far more time than is available. For practical purposes, exhaustive testing is impossible for such projects.

The above calculation uses only a tenth of the total number of testing types. For example, integration and system testing were not included in the list of four most common testing types but are still quite common (listed as used in 60% and 40% of projects, respectively). The more testing methods applied, the better the final software quality but they will require still more time. Again, the potential testing time starts to exceed practical reasonableness. As a result, risk analysis and other measures must be applied to determine how much testing is enough.


Any software project will have a number of stakeholders, each with potentially very different needs that can actively conflict with one another. Several stakeholders, with example goals, are presented here.


A goal of a software tester is to ensure that the application being tested is as free of defects as possible. As noted above, for any large project this is at best a lengthy and expensive goal, at worst an unobtainable one. At a certain point, further testing will not be practical. Some testers may naturally want to be more thorough than is necessary while others may fear reprisal if a defect is missed. Either way, the testing can easily become overlong because of these goals.


Developers want the project to be done and out the door so they can move on to the next one, or in Agile, to finish the current sprint. Testing, or having to return to the program to remove defects, delays this goal. As for the testers, this can become an even greater problem for developers penalties are imposed for defects in the code.


Customers want the application to be perfect out of the box for a low cost. The software must work without defect on all hardware combinations (especially for home users) and fulfill all requirements. Most customers realize that this is not going to happen but that is the goal. Software that does not meet the ideal will be well known in the community very quickly. This can put pressure on the business, which puts pressure on the manager, and finally on the development and testing teams.


Like the customer, the manager wants the program to be good quality and low cost, and most likely also wants a short development time. Improving any one of these goals (reducing cost, increasing quality, reducing time) requires a sacrifice in one or both of the other two. To decrease time and cost, testing may be cut or reduced. The process of solving a problem (development) is often, from the manager’s point of view, more clearly important than the process of preventing one (testing). Ultimately, management must make the decisions on how much time can be expended on any part of a project, and testing is often sacrificed in favor of the more visible development.

Delays, Delays

There is always the potential for any work to run into delays. Unforeseen problems with the software, changing personnel, and damaged equipment are all potential problems. There are too many possibilities to list here, but two will be presented: human factors and changing requirements.

Human Factors

However well-planned the software testing portion of a project might be, there is always the possibility that attitudes and habits of the development team can get in the way of completion. Distractions, attitudes towards testing, and politics can all cause delays.

Software teams, clearly, must work on computers much of their time, and computers are rife with potential distractions: social media, games, e-mail, and so on. These pursuits can sometimes improve efficiency in various ways, but they are still a lure to waste more time than is appropriate.

A number of testing types, including Subroutine and Unit testing (included in the time estimate above), are often most appropriately performed by the developers. Additionally, and pre-test defect removal will also involve the developer. Sometimes, developers do not believe that their time is properly spent on such activities. Further, even if the developers do relatively little testing themselves, a separate group of testers sending back the work due to defects, especially if this happens multiple times, can cause friction and further delays.

Changing Requirements

Most projects are going to have requirements evolve over time. Except with very small applications, as the work progresses, new features will be desired, a better view of current features will be available, and some requirements may actually be removed as unnecessary. Priorities will also shift, even if the requirements remain relatively stable. This increases both the development time and the testing time, as adaptions are made, but in this case testing is more likely to be sacrificed than development.

Making More Time for Testing

Defect Prevention

Traditionally, testing has been done after all development tasks are finished but before deployment. This means that for a small project an extra two months (according to the earlier testing time estimate) would be added to the end of the project, increasing the likelihood that the testing will be cut short. Finding defects throughout the development process (as in Figure 1) may increase the efficiency of removing defects, making the testing needed after the coding phase shorter.

Finding Defects

Test Driven Development

Test driven development (TDD) comes from Agile practices. It is a discipline in which development does not start with code, but with the development of a test case, which in turn is based on a requirement. The code is then written to pass the test case. If the code does not initially pass, it is returned to the backlog and attempted once again until it succeeds. This means that the testing is spread throughout the development process and the tests are ready at hand. However, studies of the technique show inconsistent benefits to costs: the process often costs more than other testing methods.

Test Maturity Model integration

TMMi is similar to Capability Maturity Model Integration (CMMI). It is a set of criteria that are used to determine the fitness of an organization’s testing processes. It does not dictate how the testing is done, rather it gives guidance in making improvements. It has five levels: Initial, Managed, Defined, Measured, and Optimizations. Each level except Initial has a set of requirements for an organization to be certified to it. The model is growing in popularity, as it gives a map to continuous improvement of testing systems. While not all organizations will need to obtain the highest level of TMMi, even the lower levels can lend insight to testing. Indeed, under TMMi, it is perfectly acceptable to be operating at several different levels simultaneously if those levels reflect the goals of the organization.


So, why is there never enough time for testing? Part of this is perception. All stakeholders want, to greater or lesser extents, an error-free application. Unfortunately, the exhaustive testing that this would require takes too much time to be possible in all but the smallest projects. As long as the goal is finding and fixing all defects, there can never be enough time to test. Proper risk assessment and prioritization is necessary before testing to reduce this problem.

Written by Default at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!