This article discusses the seven principles of software testing by breaking them into two groups, Why Can't We Catch Every Bug? and Where We Find Defects.
Tom Cagley examines the role of commitment in Agile.
In this article, Tom Cagley explains how you define whether a project, framework or methodology is Agile.
What characteristics make a framework or methodology Agile? Find out in this article from Tom Cagley.
There are any number of reasons why IT organizations execute a formal customer satisfaction survey. Regardless of the reason, the goal is to transfer measurement of customer satisfaction from a post-facto critique into a proactive process improvement tool. Read how DCG helped a key client measure customer satisfaction as a measure of process improvement.
Presented at the 13th Annual International Software Conference on Quality, this presentation discusses the various process improvement and productivity models and how to extract value from whichever model you choose.
Have you ever been presented with a set of requirements and been asked to size and estimate the project? This paper presents a set of semantic techniques for converting software requirements into function points (size) much earlier in the development lifecycle than thought possible.
This paper provides a path for incorporating the use of function points into Agile estimation techniques. The process will yield an estimation process that combines one part functional metrics and one part parametric estimation techniques with two parts agile estimation (heavily influenced by Mike Cohn).
Learn how to use estimation in an Agile environment.
Learn how the implementation of Agile processes allows you to avoid spending significant time analyzing risks, while making it very difficult for an unseen risk to sneak up on your project.
Learn how combining the discipline of functional metrics with the collaborative approaches found in Agile parametric estimation has proved to be an effective way to estimate in an Agile environment.
This presentation discusses how to implement best practices for mitigating risk in an Agile environment.
In 2012, the IT department at The Carlyle Group (TCG) decided to embrace Agile after a number of false starts. TCG and the David Consulting Group decided on an immersive approach to implementing Agile, rather than a "train them and they will come" approach.
The presentation provides context for how Agile was embraced at TCG and where the company stands today. These "lessons learned" can be leveraged by any organization.
Troubled projects have been part of the IT environment since the beginning. When a project is big enough to require a formal project turnaround rather than just jumping in to fix things, it is critical to recognize that the work to recover the troubled project is itself a project. Transparency is required to understand what is wrong and decisions must be made based on the certain knowledge of what has been completed. Once the project has been re-defined, re-estimated and re-planned, the project must then be focused on the newly agreed upon work to ensure that the new expectations are met.
Combining Agile management and testing techniques have proven to be a powerful method for addressing troubled projects by providing the intimacy and transparency that siloed techniques generally cannot.
Learn how to assess and leverage your organization's current development processes, establishing a set of best practices for moving forward.
This presentation discusses advanced practices of the Function Point Metric used by organizations worldwide to accurately size systems in an effort to meet customer demand on time and within budget.
Model-based process improvement typically centers on a single model or framework as the lynchpin to control software process improvement within an organization. The use of a model or framework is an excellent means of reducing random activity; unfortunately, one model does not cover the whole organization. Process improvement has matured to a point where the span of control needs to be extended, which suggests the use of more than one model (e.g. CMMI, ISO, ITIL). This presentation discusses how to manage process improvement in a complex, multi-model environment.
Sizing quickly and early in the lifecycle creates a scenario for estimators and project managers where they can turn early requirement WORDS into NUMBERS. How easy is that! Learn why sizing is important and how you can use Quick and Early Function Points.
Benchmarking provides a roadmap to lower the cost of performance measurement, thereby helping you make better decisions using less data. Less is more! This presentation outlines a path for incorporating this practice of targeted performance measurement at a much lower cost.
Learn more about Tom Cagley and Murali Chemuturi's contribution to the Software Project Management body of knowledge. This presentation discusses concepts from their book, "Mastering Software Project Management: Best Practices, Tools and Techniques."
A presentation by Tom Cagley on functional metrics for application development and how early estimation can foster improved portfolio management.
Preparing your organization for the cultural and technical change that a portfolio management system brings is a challenge. Whether you are implementing a tool or creating a newprocess, there are best practices that can support your success before you buy or start. This presentation reviews the best practices in portfolio management preparation.
Effective measurement requires fewer measures! But to make it so, the selected measures have to link to organizational goals, or they have no value. This presentation discusses how to make sure what you are measuring will lead to better decision making for you and your organization.
Learn how to achieve Agile Estimation through the use of Functional Metrics.
Can lean principles be applied to Software Development? What would plant floor waste minimization, just in time systems teach software artists about being more productive? This presentation provides a fascinating perspective to these questions.
Has Agile really taken hold and improved delivery and quality as promised? Have you started, then stopped, then fallen back to old patterns? Are you really doing SCUMFALL, as opposed to leveraging Agile methods that will work for you? These slides provide a briefing on DCG's Agile JumpStart, giving your Application Development leadership an approach to accelerate Agile adoption for real gains in change and productivity.
CMMI and Agile can work together - here's how.
Estimation and software measurements are interrelated concepts but they are not the same. This paper examines the potential impact of adopting a #NoEstimates approach for estimation on software measurement.
To assess the value of function points (any variety), it is important to step back and address two questions. The first is “What are function points (in a macro sense)” and secondly “Why do we measure?”
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.
Scrum defines three basic roles 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.
Estimation is one of the lightening rod issues in software development and maintenance. Over the past few years the concept of #NoEstimates has emerged and has become a movement within the Agile community. Due to its newness, #NoEstimates has several camps revolving around a central concept of not generating task level estimates. The newness of the movement also means there are no (or very few) large example projects that can be used as references . Finally there are no published quantitative studies of results comparing the results of work performed using #NoEstimates techniques to other methods. In order to have a conversation we need to be begin by establishing a shared context and language across the gamut of estimating ideas whether Agile or not. Without a shared language that includes #NoEstimates we will not be able to compare the concept to classical estimation concepts.
This report investigates how changes to the SDLC (Software Development Life Cycle) can improve the delivery of demonstrable value to the business. We consider how we might measure “demonstrable value” in a way that the business will understand. We review the theory of “Lean Software Engineering” and we suggest some ways that the theory can be applied to optimize different SDLC’s. Finally, we discuss the importance of Value Visualization – requiring each story or requirement in the SDLC to have a demonstrable and highly visible set of business value criteria to drive tactical decision making.
To answer this question with a yes or no answer we will need to look beyond the hyperbole of the question and address three separate questions. The questions that must be address begin with whether all types of testing can be automated followed by whether automated testing is sufficient and finally whether developers can replace testers.
The discussion of whether estimates based on historical data are better than estimates from subject matter experts (SME) is a difficult question. We suggest that as SMEs are actually repositories of historical data (their memory – as good or bad as that might be – assuming that they are ever informed about actuals) the question is a false dichotomy. Rather the question is more a reflection of whether a tool based estimate is better than a SME/expert based estimate.
This report is intended to show where Agile project integration and acceptance testing fit in the overall flow of Agile and why they are integral to effective Agile.
This paper seeks to clarify how the TMMi works and what it contains.
This Trusted Advisor report explores the genesis of Agile, current best practices and the three future trends clearly seen in today's marketplace.
This report examines the purpose functional metrics play in newer development frameworks like Agile.
The transition to Agile, or the evolution of Agile within the organization, is just one of the changes that an IT Manager finds on her plate today. In order to get the biggest bang for the buck from Agile, an IT Manager must have a basic understand of Agile. This report examines the need-to-know characteristics of Agile.
In some circumstances, Agile can be used to rescue troubled IT projects. Learn when to use Agile as a tool and how to employ it for success.
The average cost to fix a defect at the end of the lifecycle is 400-800 times greater than if it were addressed earlier. On average, poor requirement practices account for 60 percent of a project’s time and budget. Organizations with well-defined, closely managed, and effectively measured quality activities succeed and continuously improve. Yet, in a recent survey, 77 percent of managers reported that bad decisions have been made due to a lack of accurate information.
This presentation outlines the TMMi model, the de facto international standard to assess and improve test maturity, featuring independent best practices from more than 14 quality and test models. It explores how TMMI can be used in conjunction with the GQM model to ensure that upper management is provided with the information they need to make informed business decisions.