7/30/2019 Attendee Manual
1/160
Module 1: Introducing ApplicationLifecycle Management
Table of Contents
Module Overview 1Lesson 1: The Business Case for ALM 2
Lesson 2: What is ALM? 5
Lesson 3: Supporting ALM with VSTS 13
Module Review 26
7/30/2019 Attendee Manual
2/160
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or
should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft
makes no representations and warranties, either expressed, implied, or statutory, regarding these
manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or
product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third
party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of
any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not
responsible for webcasting or any other form of transmission received from any linked site. Microsoft is
providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of
Microsoft of the site or the products contained therein.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
2007 Microsoft Corporation. All rights reserved.
Microsoft are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners
7/30/2019 Attendee Manual
3/160
Module 1: Introducing Application Lifecycle Management 1
Module Overview
This module introduces Application Lifecycle Management (ALM), and explains the
business rationale and business benefits of ALM. The module explains how an
organization can get started with ALM. It also introduces VSTS as Microsofts solution
to support ALM through tooling and process enactment.
Objectives
After completing this module, you will be able to: Describe the business case for ALM.
Explain what ALM is.
Explain how VSTS supports ALM.
7/30/2019 Attendee Manual
4/160
2 Module 1: Introducing Application Lifecycle Management
Lesson 1: The Business Case for ALM
This lesson presents the business rationale for ALM. Business and technology executives
including CTOs, CIOs and IT managers are being asked to do more with less.
Maintenance of legacy systems and current technology support consumes vast amounts
of a typical enterprise software budget. This leaves precious few resources to develop
new, standards based, adaptive applications that meet the core needs of the business.
Managing complexity, aligning IT with the business, and enabling agility are top
priorities for CIOs who are under pressure to do more for the business with fixed or
diminishing budgets.
So how can you measure the real value of IT? How can you ensure that it helps you
effectively run your business? Your core business and your IT departments must coalesce
and your software initiatives must deliver measurable business benefits. To help achieve
this, a common lifecycle management solution is needed to help you track, balance, and
communicate the systems that are being created to effectively run your business.
Application Lifecycle Management (ALM) provides such a solution by addressing the
overall alignment and synchronization of business goals and IT investment priorities. It
relies on automation, integration and a coordinated approach to optimize the software
development process. Acquiring tools to support ALM, such as Microsoft Visual Studio
Team System (VSTS) is straightforward. Introducing and driving an ALM strategy
within your organization, and understanding the necessary changes required within your
business is more difficult.
Objectives
After completing this lesson, you will be able to:
Describe the business case for ALM.
7/30/2019 Attendee Manual
5/160
Module 1: Introducing Application Lifecycle Management 3
Software Development The Last Ten Years
How have software projects been doing over the last 10 years? How successful have they
been and are they getting any better? According to industry data the track record for
reducing costs is fairly impressive. You can see from the left hand graph that 200% cost
overruns have been reduced to around 50% cost overruns between 1994 and 2004. While
still not great, things have improved.
However if you take the same data and look at it differently as shown by the right hand
graph, the succeeded bars (the green lines) are stuck at around 30% indicating that only
about one third of projects actually succeed. In virtually every other industry this wouldnot be acceptable. Why should it be an acceptable state of affairs for software
engineering?
So the good news is that cost overruns are down by 100%. The bad news is that still only
30% of software projects succeed, which is not a good story. The bottom line is that it
now costs less to fail!
7/30/2019 Attendee Manual
6/160
4 Module 1: Introducing Application Lifecycle Management
Key Business Issues
Business and technical decision makers generally face a number of common issues with
their IT and software initiatives. These issues are highlighted on the slide.
The predominant issues, common to most development organizations today are:
Lack of visibility into project status. This is a primary project management issue
that can also include the inability to enforce responsibility, accountability, sign-offs
and checkpoints. The inability to enforce stakeholder involvement, to perform
accurate estimation, and to adjust project schedules accordingly are also symptomatic
of project management issues.
Ineffective team communication. Coordinating efforts across functional, geographic,
and organizational boundaries is a particularly challenging communication issue.
Balancing business demands with project risk. Poorly defined and changing
requirements, scope creep, unreliable estimates, unclear business objectives and
complex and rapidly evolving technology compound this issue and increase risk.
Unpredictable delivery times and quality. Balancing quality of service
requirements, functional requirements, budget and schedule is a tough challenge.
Eleventh hour bugs found during test and in production are all too frequent
occurrences.
There are many different areas and factors that can contribute to these core issues and
discovering and addressing the underlying issues is non-trivial. Additional demands
include having to balance new project requirements with the financial burden of
maintaining existing applications and the need to meet ever more stringent compliance
requirements.
7/30/2019 Attendee Manual
7/160
Module 1: Introducing Application Lifecycle Management 5
Lesson 2: What is ALM?
This lesson defines ALM and its principles, and how multiple roles (from both the
business and technical groups within an organization) are involved in ALM. It also
presents an approach and a process for getting started with ALM.
This next set of topics introduces ALM. To begin, consider what you may already know
about ALM. How does your organization manage software development? How does it
gather the data necessary to manage software development? Does your organization need
to change the way it manages software development? Why would that be, and what is the
goal of the change?
As you learn about ALM, you will find it does not offer a single solution to any question.
In the end, the best solution is the one that works for the team and adds value to the
business.
Objectives
After completing this lesson, you will be able to:
Explain what ALM is.
7/30/2019 Attendee Manual
8/160
6 Module 1: Introducing Application Lifecycle Management
What is ALM?
Forrester Research provides a definition of ALM that you may already know. ALM
describes methods to manage software development and IT initiatives by automating the
process from end to end, and integrating the information from the various steps.
Integration provides consistency and accuracy and also introduces opportunities for
automation.
Application Lifecycle Management (ALM) aligns the three capabilities of the
organization -- Business, Development and Operations -- by integrating the organizations
tools and activities. Aligning these three capabilities can produce applications that meetbusiness demands and while making the development process more manageable.
Microsofts vision of ALM is to look at the broad landscape of application development
and the software development lifecycle. Using Visual Studio Team Foundation Server as
a driving platform, Microsofts goal is to drive business governance, infrastructure
management, operations and support so that software teams can focus, be productive and
add value to the business.
7/30/2019 Attendee Manual
9/160
Module 1: Introducing Application Lifecycle Management 7
What is ALM?
Application Lifecycle Management (ALM) aligns the three capabilities of the
organization: Business, Development and Operations by providing integration between
the various tools used and activities performed within each of these capabilities.
Aligning these three capabilities results in applications that meet business demands and
that are better manageable.
The three core pillars of ALM are:
Traceability of relationships between artifacts. This is traditionally a laborintensive, manual process, where the effort varies with the number and size of
projects, the varying size and scope and the number of artifact interdependencies.
Compliance requirements make traceability a necessity.
Automation of high level processes. Development organizations commonly use
paper-based approval processes to control handoffs between functional areas. ALM
solutions improve efficiency by automating these handoffs and by providing central
storage for all associated documentation. Automated and executable process models
are used by ALM solutions to ensure process adherence.
Reporting to increase visibility. Most managers have limited visibility into the
progress of development projects. What visibility they have is typically gleaned fromsubjective testimonials, and not objective data. The lack of proper reporting also
hinders opportunities for process improvement. The ALM reporting functions benefit
from integration and automation to provide real time status information and deep
analysis of all activities.
7/30/2019 Attendee Manual
10/160
8 Module 1: Introducing Application Lifecycle Management
ALM Practices
VSTS supports the three core pillars of ALM by providing:
Traceability of relationships between artifacts. VSTS provides traceability
between artifacts primarily through its work item tracking capability. Work items can
include scenarios, quality of service requirements, tasks, bugs and risks. Individual
work items can be linked. For example you can relate specific tasks to specific
scenarios or QoS requirements and in this way track their progress throughout the
lifecycle. Work item history is also provided to provide an audit trail, which is
important for compliance.
Automation of high level processes. VSTS enables you to avoid paper-based
approval processes to control handoffs between functional areas. VSTS provides
central storage for all associated documentation. It also provides process templates
which enable you to enact key processes and automate specific practices to help
ensure process adherence.
Reporting to increase visibility. VSTS provides an extensive range of reporting
options to help you view and track the current status of your development efforts.
This enables you to use objective data to ascertain project progress rather than relying
on subjective input. VSTS reporting provides real time status information and deep
analysis of all activities.
7/30/2019 Attendee Manual
11/160
Module 1: Introducing Application Lifecycle Management 9
The Business Benefits of ALM
Introducing ALM to organizations has accomplished the following business benefits:
Increased ROI from your IT spending.
Increased accountability, enabling stricter compliance to governance initiatives.
Increased collaboration between business and IT better alignment of the business
with IT.
Improved project management, including better estimation, better tracking, and better
reporting through a single, unified view of the project. The improved integration
stems from the use of tools that work together rather that disparate tools, poor
integration and duplicated data.
Quality improvements, so the final application meets the requirements of your
customers, and meets quality of service requirements.
Shorter development cycles and improved productivity through shared best practice
and process learning and improvement.
Increased ability of the IT department to rapidly build and adapt applications to
support dynamically changing business requirements.
The net result of these benefits is increased synchronization between IT and yourbusiness to deliver improved business value to your customers and to provide an
additional competitive advantage.
7/30/2019 Attendee Manual
12/160
10 Module 1: Introducing Application Lifecycle Management
ALM Roles and Responsibilities
Many different roles are involved throughout the application lifecycle. Roles include
development executives, project managers, business analysts, architects, UI designers,
DBAs, developers, testers and operations. Note that roles are fluid, and are a set of a
responsibilities, and not simply a job title.
7/30/2019 Attendee Manual
13/160
Module 1: Introducing Application Lifecycle Management 11
A Process for Introducing ALM
Introducing an ALM strategy takes time and your focus should be on practices and
process improvement -- and not simply introducing tools. You should aim to implement
ALM iteratively, for example by phasing in new practices over time. When drawing up
your implementation plan, you should also make sure that it is aligned with your key
business drivers.
A key requirement when getting started is to first understand your organizations current
strengths and weaknesses when it comes to application development and IT delivery. If
you know the current strengths and weaknesses, and where your organization is today,you can determine how it needs to adapt in order to realize the true benefits of ALM.
Microsoft provides resources that can help evaluate your organizations ALM needs and
determine solutions. Start by readingApplication Life-cycle Management (ALM) for
Software Teams at http://msdn2.microsoft.com/en-us/teamsystem/bb400737.aspx. You
can also complete an in-depth assessment to learn more at
https://www.microsoft.com/almAssessment.
The primary objective for ALM is to turn your IT function from a basic cost center that
delivers brittle, unconnected applications and platforms into a strategic asset capable of
delivering a service oriented application platform that supports your business functions.
7/30/2019 Attendee Manual
14/160
12 Module 1: Introducing Application Lifecycle Management
Discussion: Moving Towards ALM
During this discussion, you should consider to what extent your current organization has
adopted ALM practices. You should reflect on where your organization is now in terms
of its processes, team roles and development practices. Consider what would need to
change to move towards a more integrated ALM approach.
7/30/2019 Attendee Manual
15/160
Module 1: Introducing Application Lifecycle Management 13
Lesson 3: Supporting ALM with VSTS
This lesson explains how VSTS provides the integrated tooling to help support your
ALM initiatives.
This lesson starts with a top level overview of the VSTS/TFS landscape and then explains
how different VSTS features help support the three key pillars of ALM -- traceability,
process enactment, and visibility.
Objectives
After completing this lesson, you will be able to:
Understand how Visual Studio supports traceability, process enactment, and visibility.
7/30/2019 Attendee Manual
16/160
14 Module 1: Introducing Application Lifecycle Management
ALM and VSTS
ALM is a discipline as well as a product category. ALM doesnt support specific
lifecycle practices, but rather it keeps them in sync manual processes can be more
efficient and effective through tool integration. Development efforts can still fail even if
separate development activities are done correctly. ALM ensures the coordination of
these activities. An ALM solution is therefore the integration of lifecycle tools, not
merely a collection of those tools. Furthermore ALM is labor intensive without the
integration of lifecycle tools, in other words, automation is necessary.
VSTS is a process platform, where you adopt and adapt practices accordingly. It enablesyou to take overhead out of what people do, while not dictating what they do. VSTS is
designed to facilitate the ALM discipline and process your team chooses.
7/30/2019 Attendee Manual
17/160
Module 1: Introducing Application Lifecycle Management 15
The Visual Studio Team System / Team Foundation Server
Landscape
VSTS provides an integrated set of tools, processes and guidance to support ALM. The
Team Foundation Server (TFS) component provides a centralized repository for all
project artifacts such as project work items, workflow settings and status, requirements
and design documents, source code with versioning, branching and merging, and test and
build results. Reports are driven from a centralized data warehouse. All artifacts are
linked to each other where necessary to achieve high degrees of integration.
VSTS is licensed in four different editionsTeam Edition for Software Architects, TeamEdition for Software Developers, Team Edition for Database Professionals, and Team
Edition for Software Testers. Each edition of Visual Studio Team System is configured to
deliver tools and solutions out-of-the-box. However, each edition is highly extensible and
can be customized as necessary to fit the needs of each organization. Further extensibility
is available by joining the Microsoft Visual Studio Industry Partner (VSIP) program. This
enables a licensee to access the VSTS APIs, letting you integrate virtually any tools you
have into the VSTS Integrated Development Environment.
Team Foundation Server is the "team" in Team System. Without it, the other components
of VSTS are standalone components that run on a client machine. Once TFS is installed,
the various client pieces work together as a cohesive unit.
7/30/2019 Attendee Manual
18/160
16 Module 1: Introducing Application Lifecycle Management
Supporting ALM with VSTS
Software development processes are complex, involving many levels of interdependent
activities. Processes are generally available in documentation form but are not enforced
by tools. This makes it difficult for your development teams to learn and follow the
processes consistently. Project managers might use a variety of different tools for project
management, requirements management, bug tracking, or review management and they
are often not integrated in any way.
By using different tools you make it difficult to enforce a consistent implementation
methodology across multiple projects and to generate consistent reports with commonunderstanding. This makes process analysis unreliable, which makes it difficult to
identify process improvements over time.
VSTS provides an integrated environment that supports most of the process activities
involved in a software development project. It implements software development
lifecycle methodologies by using process templates. If the supplied templates are not a
good match for your teams development process you can create a new process template
or modify an existing template. The following topics demonstrate VSTS and its support
for processes and reporting.
7/30/2019 Attendee Manual
19/160
Module 1: Introducing Application Lifecycle Management 17
Traceability with VSTS
The basic unit of measurement in project management is the work item. To accommodate
this, VSTS/TFS provides project wide work item tracking and reporting; and work items
are at the heart of VSTS -- it uses work items to track all planned, active and completed
work for the team. The detailed history of the changes made to work items provides
important data about the actions and decisions taken regarding the work.
Different types of work items can be recorded and tracked in VSTS, including scenarios,
Quality of Service (QoS) requirements, risks, bugs, and tasks. Visual Studio supports
viewing and managing work items using a number of different applications, includingVisual Studio Team Explorer, Sharepoint Services, Excel and Microsoft Project.
7/30/2019 Attendee Manual
20/160
18 Module 1: Introducing Application Lifecycle Management
Process Enactment with VSTS
VSTS/TFS provides two software development project wide process templates. These
templates are based on the Microsoft Solutions Framework implementation of CMMI and
Agile processes.
However, VSTS supports more than MSF based processes. Using third party templates,
or by building and customizing your own process templates, other processes can be
utilized. The next topic provides more details about these resources.
Regardless of the template you choose, the VSTS provided process templates are
customizable so that your businesses specific processes can be accommodated.
7/30/2019 Attendee Manual
21/160
Module 1: Introducing Application Lifecycle Management 19
What About My Processes
VSTS supports more than MSF based Agile or CMMI processes. Depending on the
development management process used by your organization, you can add third party
templates for other processes, such as SCRUM. Consistent with the VSTS provided
templates, third-party templates can be customized to suit the needs of your specific
organization.
For more details see: http://msdn.com/process.
7/30/2019 Attendee Manual
22/160
20 Module 1: Introducing Application Lifecycle Management
Visibility with VSTS
VSTS provides extensive and flexible report creation. The process template used in
creating the team project determines which reports are available by default, but you can
also add your own custom reports. The content and use of each report created by the
process template is explained in the process guidance for that template.
Team Foundation Server is built on SQL Server 2005 and uses SQL Server to store data
about work items, quality attributes, testing, test results, and build results. Team
Foundation Server then uses SQL Server Analysis Services to aggregate and analyze the
data and drive reporting. The reports that are created by the process template or byindividual team members using Microsoft Excel or Visual Studio 2005 Report Designer
are made available through SQL Server 2005 Reporting Services and the team report site.
For more information see: http://msdn2.microsoft.com/en-
us/library/ms194922(VS.80).aspx
The following slides highlight some of the reports Team Foundation Server can produce
to help managers measure productivity, development practices and quality. Each of these
reports will be presented in greater detail later in the course.
7/30/2019 Attendee Manual
23/160
Module 1: Introducing Application Lifecycle Management 21
Reports About Productivity
Team Foundation server can produce a standard productivity report that shows how much
work is being completed over a certain period of time.
It can also mine its warehouse of data and produce reports that show how much work has
been added since the original work estimates were made. This latter report allows
managers to get a handle on their teams work estimation skills and improve them for
future iterations and projects.
7/30/2019 Attendee Manual
24/160
22 Module 1: Introducing Application Lifecycle Management
Reports About Development Practices
Team Foundation Server can generate standard reports showing how effectively the
development team is finding, fixing and closing bugs.
Because code check-ins are tracked and related to bugs and work items, Team
Foundation Server can determine how much of that development work is having to be
redone.
7/30/2019 Attendee Manual
25/160
Module 1: Introducing Application Lifecycle Management 23
Reports About the Quality of the Software
Team Foundation Server can generate reports showing how productive the Test team is.
Using multiple metrics, Team Foundation Server can produce a report that helps to
estimate the quality of the software.
7/30/2019 Attendee Manual
26/160
24 Module 1: Introducing Application Lifecycle Management
Demonstration: VSTS Process Templates
This demonstration will show how VSTS uses process templates and associated process
guidance to help apply process governance. The demonstration looks at what you get
when you create a new team project based on a project template. Items highlighted by
this demonstration include:
Process guidance.
Initial default work items.
Initial project areas and iterations.
Reports.
Default Team portal site with SharePoint doc library and contents.
7/30/2019 Attendee Manual
27/160
Module 1: Introducing Application Lifecycle Management 25
Return on Investment Customer Evidence
Microsoft provides case studies about the adoption of Visual Studio Team System so that
managers have quantitative data regarding return on investment. Twenty-one studies are
available detailing the experience of customers such as Dell, EDS. Additional resources
detail Microsofts experience using VSTS/TFS to plan, manage, and develop Microsoft
software. Return on Investment studies, Technical Case Studies and other customer
adoption information is available at http://msdn2.microsoft.com/en-
us/teamsystem/bb676820.aspx.
7/30/2019 Attendee Manual
28/160
26 Module 1: Introducing Application Lifecycle Management
Module Review
ALM can deliver a number of key business benefits
Increased ROI, increased accountability, improved compliance and increased
responsiveness to business needs.
ALM relies on integrated toolsets that support and unite lifecycle activities including:
Requirements management
Design/ modeling
Development
Testing
Configuration Management
VSTS supports ALM by establishing systems and processes. VSTS allows greater
visibility of project activities, enables collaboration and communication, and helps to
ensure software quality using advanced tooling.
7/30/2019 Attendee Manual
29/160
Module 1: Introducing ALM
Student Group Exercise: Moving Towards ALM
In this exercise, consider to what extent your current organization (or anorganization you have experience of) has adopted ALM practices. The objective is foryou to consider where your organization is now in terms of processes, team rolesand development practices, and to think about areas of weakness and what youthink needs to change to move towards a more integrated ALM approach.
Use the following questions to help guide your thinking and subsequent discussion.Feel free to consider and discuss additional questions.
What would you say are your organization s key strengths and weaknesses
with regard to s/w development and IT delivery?
What are its main strengths and why?
What are its main weaknesses and why?
How effective would you say your current processes are?
How well defined are your processes?
How do you enforce process to ensure consistency?
Do your teams and processes help foster a culture of continuous
improvement?
How well defined are your team roles and development practices?
What tools do you use to manage the s/w development process?
Who are your customers? Who are your other stakeholders?
How would they variously answer these questions?
How do you know theyd answer like that?
7/30/2019 Attendee Manual
30/160
Module 2: Value-Up SoftwareDevelopment
Table of Contents
Module Overview 1Lesson 1: Moving from Work-Down to Value-Up
Practices 2
Lesson 2: Supporting Value-up Practices with VisualStudio Team System 15
Module Review 22
7/30/2019 Attendee Manual
31/160
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or
should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft
makes no representations and warranties, either expressed, implied, or statutory, regarding these
manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or
product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third
party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of
any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not
responsible for webcasting or any other form of transmission received from any linked site. Microsoft is
providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of
Microsoft of the site or the products contained therein.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
2007 Microsoft Corporation. All rights reserved.
Microsoft are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners
7/30/2019 Attendee Manual
32/160
Module 2: Value-Up Software Development 1
Module Overview
This module introduces the notion of value-up software development. It compares and
contrasts core value-up principles and practices with conventional work-down
approaches. The latter have proved over the years, largely ineffectual for team-based
software development and are part of the reason why only 30% of software projects
succeed.
After completing this module, you will be able to:
Explain the benefits of a value-up approach to software development.
Describe how Visual Studio Team System (VSTS) supports and encourages value-up
practices.
7/30/2019 Attendee Manual
33/160
2 Module 2: Value-Up Software Development
Lesson 1: Moving from Work-Down to Value-UpPractices
This lesson compares and contrasts work-down and value-up practices and explains the
main benefits of a value-up approach to software development.
Objectives
After completing this lesson, you will be able to:
Explain the benefits of a value-up approach to software development.
7/30/2019 Attendee Manual
34/160
Module 2: Value-Up Software Development 3
The Driving Forces
So why do things need to change in the way software development is approached? The
answer to this question provides the motivation for value-up practices.
There are three primary driving forces that need to be reconciled and this cannot happen
without a paradigm shift in the way the software lifecycle is approached. The three
driving forces are:
Agility. Agile software development methods have become mainstream. Agile
methods are seen as a lightweight alternative to traditional software engineering
management practices, such as CMMI (Capability Maturity Model). Today, you can
think of agile as a term that represents approaches and practices that work.
Outsourcing. There are many pressures on teams related to financial resources.
Primary management issues related to managing costs of software development are
global competition and outsourcing. Outsourcing is a result of the excessive
development costs associated with traditional development. Increased economic
freedom, increased communications bandwidth, and a highly skilled labor force in
emerging markets makes outsourced software development to lower-wage countries
profitable.
Compliance. Increased attention is required to address regulatory compliance.
Management of publicly traded companies have come under increased scrutiny as
more investors have purchased shares and fiscal accounting has become more and
more complex. In the United States, federal law, specifically the Sarbanes-Oxley Act,
holds business executives criminally liable for financial misrepresentation. Software
and systems that process financial information are subject to a high level of scrutiny
and audit.
7/30/2019 Attendee Manual
35/160
4 Module 2: Value-Up Software Development
Modern economics demand agility with accountability. To reconcile these different
forces requires a shift in the way software is developed and new approaches to both the
process and the tooling that supports the process. Traditional software development is
failing to deliver sufficient business benefit and return on investment.
7/30/2019 Attendee Manual
36/160
Module 2: Value-Up Software Development 5
The Business Context for Software Development
Software development is risky. This is the business reality.
With most engineering disciplines, there are previous examples to follow. For example,
when you build a road or a bridge you can study hundreds of other similar examples. By
building a new one just like an existing one, you de-risk the whole process. Software
engineering and building IT systems in general is quite different. If a system already
exists like the one you want to build, economics dictate that you go out and buy it or
license it commercially. In other words, you would never build it yourself.
As a result of this, you need to view software development in a completely different
business context. Virtually all of your software development projects are concerned with
building products and solutions that dont already exist so the risk is immediately
higher. This business reality is the key factor that makes software development so hard
and risky and this makes attention to process essential.
7/30/2019 Attendee Manual
37/160
6 Module 2: Value-Up Software Development
A Value-Up Approach to Software Development
Non-software engineering disciplines have established the foundation of modern top-
down project management. In top-down, burn down or work down project management,
the priority is to determine an engineering design early, carefully decompose the design
into implementation tasks, schedule and resource the tasks according to their
dependencies and resource availability, and monitor the project by checking off tasks as
completed (or tracking percentages completed). This style of project management the
work-down approach is easily envisioned as burning down a list of tasks.
The work-down approach succeeds for engineering projects with low risk, low variance,and well-understood design. Many software development projects are customizations of
commercial-off-the-shelf software, such as data base systems. Often, the development is
a small part of the project relative to the business analysis, project management, and
testing. Typically, these projects have lower variability than new development projects,
so the wisdom of roads and bridges works better for them than for new development.
Value up process management recognizes and accepts the inherent risks of software
development. It views early planning and design as costly, especially if it constrains one
of the benefits of software development system development and changes are relatively
inexpensive throughout the development lifecycle. Consider the bridge building analogy,
for example. If a bridge fails to line up by 1, a rework is probably the cost of the bridge.
Fixing an analogous amount of error in a software project is far less expensive than the
cost of the project.
Value-up processes attempt to capture the unique benefits of engineering software by
measuring value delivered rather than tasks completed. Value-up seeks to incrementally
build a solution and measure the value of the software delivered to the customer at
instrumented points during the project. Value-up processes consider this value to the
7/30/2019 Attendee Manual
38/160
Module 2: Value-Up Software Development 7
customer to be the purpose of the project, and seek to ensure that this value flows from
the beginning of the project to the end. So value-up systems look continually look for
ways to improve the flow of value throughout the software lifecycle.
7/30/2019 Attendee Manual
39/160
8 Module 2: Value-Up Software Development
Comparing Value-Up and Work-Down Practices
There are several key differences between work-down and value-up practices. The main
difference between the two is the primary measurement of progress. Work-down treats
the project as a fixed set of tasks, each with some associated cost that need to be
completed, and measures the expenditure against these tasks. Value up measures value
delivered at each point in time and treats the inputs as variable flows rather than a fixed
stock.
7/30/2019 Attendee Manual
40/160
Module 2: Value-Up Software Development 9
The Core Principles of Value-Up
When software is developed using a value-up process, planning and design is done
regularly throughout the life of the project. This is in contrast to traditional software
project management that front loads the project with almost all design work. In a value-
up project, the overhead of creating planning and design artifacts should be limited to just
enough planning and design to understand risk and to manage the next small increment.
Value-up methods, such as those that are managed using an Agile process, are generally
characterized by the following six tenets:
Increase return on investment by making continuous flow of value the focus.
Deliver reliable results by engaging customers in frequent interactions and shared
ownership.
Expect uncertainty and manage for it through iterations, anticipation, and adaptation.
Capture creativity and innovation by recognizing that individuals are the ultimate
resource necessary to create value, and to create an environment where they can
deliver that value.
Boost performance through group accountability for results and shared responsibility
for team effectiveness.
Improve effectiveness and reliability through specific strategies, processes, and
practices, based on the current situation.
7/30/2019 Attendee Manual
41/160
10 Module 2: Value-Up Software Development
The Importance of Project Flow
In a value-up project, the deliverables that the customer values (working software,
completed documentation) are the only work-products that count. The project plan is
designed so the value of the software to the customer can be measured at regular intervals.
In this way, the flow of work that creates value to the customer can be measured
concretely. A value-up perspective to managing this flow of work and value treats interim
measurements of value and quality skeptically. The end product of an iteration and how
much the customer values that end product is the primary measure of project health.
Therefore, do not measure planned tasks completed as the primary indicator of progress.The project plan should count units of value delivered.
7/30/2019 Attendee Manual
42/160
Module 2: Value-Up Software Development 11
Measuring Flow
This graph is an example of a VSTS Remaining Work report that shows scenario
completion on a daily basis and the flow of progress.
In this example, planned work for an iteration is progressing well through development,
but is increasingly getting stuck in testing. This accumulates as work-in-process. If a
project manager was tracking development tasks completed, the reduction of active work
items would be declining, and the expected completion date would be met. However, in
this example, by looking at the work completed related to the resolution of scenarios it is
possible to see that because of the bottleneck of work-in-process, testing will not finishwork on time.
7/30/2019 Attendee Manual
43/160
12 Module 2: Value-Up Software Development
Exercise: Work-Down vs. Value-Up
During this exercise, students will be divided into groups and will be asked to identify
and consider their current practices. To help frame the exercise, the instructor can start by
writing the following set of headings onto a whiteboard. He can then ask students to
identify and consider their own practices in regard to each of these areas.
Planning and change process
Primary measurement
Definition of quality
Acceptance of variance
Intermediate work products
Troubleshooting approach
Approach to trust
The idea is for students, having identifies some of their own practices for each of these
categories, to decide whether or not they can be classified as work-down or value-up.
Students will be given 20 minutes or so to consider this and will then report back to the
wider class.
When gathering answers from the different groups, the instructor will write the practices
down on the whiteboard next to the adjacent core assumption. The group providing the
list can explain what they consider to represent work down practices and what they
consider embody value-up thinking. For those identified as work down practices, the
wider class can be asked to consider what some of the inherent problems may be with
these practices and how they could be adapted to benefit from value-up thinking.
7/30/2019 Attendee Manual
44/160
Module 2: Value-Up Software Development 13
The instructor can use the following table to help frame the exercise (and possibly use
this as a recap at the end of the exercise to reinforce the key attitudinal differences
between work-down and value-up paradigms.
Core assumption Work-down attitude Value-up attitude
Planning and change process Planning and design are the
most important activities to get
right. You need to do these
initially, establish accountability
to plan, and monitor against the
plan, and carefully prevent
change from creeping in.
Change happens, embrace it.
Planning and design will
continue through the project.
Therefore you should invest in
just enough planning and
design to understand risk and to
manage the next small
increment.
Primary measurement Task completion. Because we
know the steps to achieve the
end goal, we can measure
every intermediate deliverable
and compute earned value
running as the % of hours
planned to be spent by now vs.the hours planned to be spent
to completion.
Only deliverables that the
customer values (working
software, completed
documentation, etc.) count.
You need to measure the flow
of the work streams by
managing queues that delivercustomer value and treat all
interim measures skeptically.
Definition of quality Conformance to specification.
Thats why you need to get the
specs right at the beginning.
Value to the customer. This
perception can (and probably
will) change. The customer
may not be able to articulate
how to deliver the value until
working software is initially
delivered. Therefore, keep
options open, optimize for
continual delivery and dont
specify too much too soon.
Acceptance of variance Tasks can be identified and
estimated In a deterministic
way You dont need to pay
attention to variance.
Variance is part of all process
flows, natural and man-made.
To achieve predictability, you
need to understand and reduce
the variance.
Intermediate work products Documents, models, and other
intermediate artifacts are
necessary to decompose the
design and plan tasks, and they
provide the necessary way to
measure intermediate progress.
Intermediate documentation
should minimize the uncertainty
and variation in order to
improve flow. Beyond that, they
are unnecessary.
Troubleshooting approach The constraints of time,
resource, functionality andquality determine what you can
achieve. If you adjust one, you
need to adjust the others.
Control change carefully to
make sure that there are no
unmanaged changes to the
plan.
The constraints may or may not
be related to time, resource,functionality, or quality. Rather,
identify the primary bottleneck
in the flow of value, work it until
it is no longer the primary one,
and then attack the next one.
Keep reducing variance to
ensure smoother flow.
Approach to Trust People need to be monitored
and measured to standards.
Pride of workmanship and
teamwork are more effective
7/30/2019 Attendee Manual
45/160
14 Module 2: Value-Up Software Development
Core assumption Work-down attitude Value-up attitude
Incentives should be used by
management to reward
individuals for their
performance relative to plan.
than individual incentives.
Trustworthy transparency,
where the whole team can see
all the teams performance
data, works better than
management directive.
7/30/2019 Attendee Manual
46/160
Module 2: Value-Up Software Development 15
Lesson 2: Supporting Value-up Practices with VisualStudio Team System
This lesson compares and contrasts work-down and value-up practices and explains the
main benefits of a value-up approach to software development.
Objectives
After completing this lesson, you will be able to:
Describe how Visual Studio Team System supports and encourages value-up
processes and practices.
7/30/2019 Attendee Manual
47/160
16 Module 2: Value-Up Software Development
Why Value-Up Requires Tooling
Value-up practices require tool support. Traditional methods use manual process
enactment or use disparate tools that do not integrate well and do not provide a unified
view. This make tracking project progress and obtaining a current snapshot of project
health very difficult. Collecting data and tracking progress is traditionally expensive,
requiring lots of documentation, training and management. Also, the resulting process
artifacts and the associated effort do not deliver customer value.
With traditional approaches, there is often disparity among the priorities and expectations
of different team members. Most approaches to software engineering have lots of placesto track the work spreadsheets, project plans, requirements databases, bug data bases,
test management systems, triage meeting notes, and more. When information is scattered
this way, it is difficult to get a whole picture of the project. You need to look in too many
sources and it is hard to balance all the information into one schedule. Also, when there
are so many sources, the information you find is often obsolete.
7/30/2019 Attendee Manual
48/160
Module 2: Value-Up Software Development 17
Benefits of a Common Product Backlog
By providing a common product backlog you -fragment data, and enable a unified view
of data to be acquired by using tools most appropriate for the role, such as Microsoft
Excel and Microsoft Project for project managers, Team Explorer for developers, and so
on. A common product backlog also benefits from the ability to automate data collection
as the various elements of the process proceed. For example, data can be captured each
time a developer checks in code to resolve work items. Build and test results can be used
to help measure quality.
VSTS has a central work item database containing the product backlog used to track allplanned, active and completed work together with a history of actions and decisions made
for that work.
For example, VSTS has a central work item database containing the product backlog used
to track all planned, active and completed work together with a history of actions and
decisions made for that work.
7/30/2019 Attendee Manual
49/160
18 Module 2: Value-Up Software Development
Benefits of Instrumenting Daily Activities
Collecting accurate data is traditionally an error prone and very time consuming task. By
driving the data capture from daily activities (such as code check-in, builds, test runs) this
becomes an automated process increasing accuracy and saving countless hours of
additional overhead work related to creating reports.
Vast majority of the data that a team needs is directly correlated to other actions that are
already managed by software. Developers check in code, builds parse that code, testers
write and run tests, and all these activities are tracked somewhere Project, Excel, bug
database or timesheets. Often collecting data becomes a major activity. Disciplinedattention to bookkeeping is rarely sustained in practice, especially during periods of
intense activity.
Instrumenting a daily activity allows the collection and processing of data with minimal
overhead. For example, each time a developer checks updated code into version control,
work items are updated to reflect the tasks and scenarios updated by this code. The
relationships are captured in a changeset, and when the next build runs, it identifies the
change sets included and updates work items again with the build number. When tests
execute, the tests use the same build umber. Test results, code changes, and work items
are all correlated automatically.
This automatic data collection populates a data warehouse with metrics. This allows for
the creation of reports that reveal trends and evaluate the flow of quality from many
dimensions on a regular, incremental basis.
7/30/2019 Attendee Manual
50/160
Module 2: Value-Up Software Development 19
Assessing Quality
Assessing software quality is more than looking at bug count metrics. Such a metric
covers only a narrow slice of testing progress, let alone software quality. Simple charts of
single dimension metrics can carry a lot of useful information and can lead you to a lot of
useful questions. However, such charts can provide support for conclusions that are in
fact invalid.
In this example, you might conclude from a bug count report that the Data Access Layer
(first bar) is in great shape because it has a high test pass rate and a low bug count so
youd look for problems elsewhere.
7/30/2019 Attendee Manual
51/160
20 Module 2: Value-Up Software Development
Assessing Quality (Continued)
To assess software quality, it is necessary to report multidimensional patterns, rather than
single measures or a few measures along the same line. Being able to see the interactions
between different metrics allows you to consider more fully the quality of the software.
This example illustrates the danger of relying on too few metrics. Consider what happens
when you overlay code churn (the number of lines added, modified or deleted), and code
coverage from testing on the same axes as the bug count.
The ability to analyze data in different ways and to present different views is a direct
benefit of the VSTS multi-dimensional metrics warehouse. You can achieve the high
visibility levels necessary for the strictest compliance reporting, while working in an
agile manner. This level of reporting, process management and visibility is the same for
local, remote, and even outsourced projects.
7/30/2019 Attendee Manual
52/160
Module 2: Value-Up Software Development 21
Benefits of Iterative Development
An iteration is a fixed set of time used to schedule a set of tasks. Iterations are used as an
interval in which to schedule intended scenarios, measure the flow of value, asses actual
process, examine bottlenecks, and make adjustments. The benefits of iterations include:
Improved risk management.
Ability to review priorities frequently.
Improved focus on specific tasks.
Better motivation from seeing early and frequent releases.
Improved estimation.
Improved stakeholder confidence and involvement (seeing results early).
Continuous learning. The ability to learn from previous iterations and adjust and
improve as necessary.
Iterations also help with the instrumenting of development activities. This enables the
measurement of flow customer value delivered in the current feature set, assessment of
processes, elimination of bottlenecks and making adjustments.
7/30/2019 Attendee Manual
53/160
22 Module 2: Value-Up Software Development
Module Review
Traditional engineering project management fails to take advantage of the unique benefits
software development can accommodate. A paradigm shift from work-down project
management to value-up project management can provide added value unique to software
engineering:
Benefits of a value-up approach to software development.
Key differences between value-up and work-down practices:
Work-down sees completing a list of tasks as a measurement of progress. Value-up measures progress by having customer regularly evaluate the value of
delivered features.
VSTS supports and encourages value-up practices:
Single work-item database.
Scenario based development.
Flexible processes.
7/30/2019 Attendee Manual
54/160
MODULE 2: VALUE-UP SOFTWARE DEVELOPMENT
STUDENTGROUPEXERCISE: WORKDOWN VS. VALUE-UP
In this exercise, consider your current software development practices in each of thecategories listed below. Perform this exercise as individuals to start with and thendiscuss your answers and findings with your group. Contrast your practices withother definitions and practices that others in your group have used. Considerwhether youd categorize specific practices as work down or value up. After 20minutes individual and group work, you will be asked by your instructor to discussyour practices and findings with the wider class.
x Planning and change processo When do you perform your planning?o Who do you hold accountable for the plan?o What is your attitude to change?o How do you prevent scope creep?
x Primary measuremento How do you measure progress?o What do you consider are your main deliverables that you use to trackprogress?
x Definition of qualityo How do you define quality?o How would your customers and stakeholders define quality?o How to you measure quality?o How do you ensure quality?
x Acceptance of varianceo Do you accept that variance is a natural occurrence within all projects?o How to you recognize and measure variance?o What do you do about it?
x Intermediate work productso What kind of intermediate work products do you use?o What do you use them for?o Do you use them to measure progress and how effective is this approach?
x Troubleshooting approacho How do you ensure a smooth flow of progress through your project?o What are some symptoms of an out of control project?
x How do you balance the constraints of time, resource, functionality and qualityApproach to trusto What kind of performance incentives do you use?o Are they individual or team based and why?
7/30/2019 Attendee Manual
55/160
Module 3: The Business AnalystsPerspective
Table of Contents
Module Overview 1Lesson 1: Gathering Functional Requirements 2
Lesson 2: Using Personas and Scenarios 8
Module Review 15
7/30/2019 Attendee Manual
56/160
7/30/2019 Attendee Manual
57/160
Module 3: The Business Analysts Perspective 1
Module Overview
This module focuses on gathering the requirements your system must deliver. It examines
the process of gathering requirements and introduces techniques to help capture and
manage requirements throughout the software development lifecycle. This module also
explains some of the challenges associated with deciding precisely what to build and it
presents techniques for capturing and evolving requirements to ensure that requirements
stay current throughout the software development lifecycle.
Objectives
After completing this module, you will be able to:
Describe techniques for capturing functional requirements.
Explain the benefits of using scenarios and personas.
Identify key quality of service requirements that should be captured and tracked.
7/30/2019 Attendee Manual
58/160
2 Module 3: The Business Analysts Perspective
Lesson 1: Gathering Functional Requirements
This lesson describes some of the techniques for gathering functional requirements.
Objectives
After completing this lesson, you will be able to:
Describe techniques for capturing functional requirements.
7/30/2019 Attendee Manual
59/160
Module 3: The Business Analysts Perspective 3
Starting with a Vision Statement
Every project should have a vision statement that each stakeholder can understand. The
vision statement is helpful to clarify the core values of the project. It should state why a
customer or end user will want the solution the project team is building. The shorter the
vision statement is, the better it is. A sign of a successful vision statement is that
everyone on the project team can relate to it and connect their daily work to it.
Vision statements will be different depending on the end goal of the project. One way to
think about these differences is to consider whether your project is a Strategic project or
an Adaptive project.
Strategic project vs. Adaptive projects
Strategic projects involve significant investments based on a plan to improve appreciably over
their predecessors.
Adaptive projects are those that make incremental changes to existing systems.
7/30/2019 Attendee Manual
60/160
4 Module 3: The Business Analysts Perspective
Knowing When to Capture Requirements
Requirements are a quantifiable way to communicate and measure the work necessary to
complete a project. However, it is often possible for a project to stall because there are
an unrealistic amount of requirements or the requirements themselves are not achievable.
When a project stalls due to continual requirements analysis and writing this is called
analysis paralysis.
Value-up processes attempt to avoid analysis paralysis by considering two factors: first,
requirements have to be written so an audience can use them; and second, for
requirements to be useful they are considered to have a limited lifetime. Goodrequirements accept:
The business environment or problem domain changes.
The knowledge that led to the initial requirements becomes stale as lessons are
learned during later iterations.
There is a limit to the number of requirements that a team can realistically deliver.
When a team has fewer and more granular requirements, the team can focus more
attention on quality design and implementation.
7/30/2019 Attendee Manual
61/160
7/30/2019 Attendee Manual
62/160
6 Module 3: The Business Analysts Perspective
Gathering and Tracking QoS Requirements
Quality of Service requirements can define global attributes of a system or specific
constraints on particular scenarios. For a project to be complete, you need to determine
the Quality of Service requirements that apply to your system.
As with scenarios, QoS requirements need to be explicitly understandable to the
stakeholder audiences, defined early; and when planned for implementation during an
iteration, the requirements must be testable.
Define your Quality of Service (QoS) requirements for each of the scenarios to be
developed during the iteration. You repeat this step for each iteration cycle. This helps
define the acceptance criteria for the scenario.
Sources for QoS requirements come from project goals and requirements and
specification documentation. A Quality of Service requirement can start with a general
statement about performance, for example. For development during an iteration you will
need to add detail, including setting specific targets on specific transactions at specific
loads. If the requirement cannot be tested, then it is impossible to determine when the
requirement is complete.
VSTS tracks Quality of Service requirements as work items. As the requirement is
identified, it begins in the Proposed state. When a requirement is accepted for the currentiteration, it moves to the Active state and is analyzed to create tasks to implement it.
When the tasks are complete and system tests are passed showing that the requirement is
successfully implemented, it moves to the Resolved state. Finally, when the requirement
is validated, it is moved to the Closed state.
7/30/2019 Attendee Manual
63/160
Module 3: The Business Analysts Perspective 7
Discussion: Gathering Functional Requirements
Discuss with students how they gather functional requirements. What works? What does
not work? Why not?
7/30/2019 Attendee Manual
64/160
8 Module 3: The Business Analysts Perspective
Lesson 2: Using Personas and Scenarios
This lesson describes why personas and scenarios are effective tools for understanding
and communicating customer value.
Objectives
After completing this lesson, you will be able to:
Explain the benefits of using scenarios and personas.
7/30/2019 Attendee Manual
65/160
Module 3: The Business Analysts Perspective 9
Identifying and Creating Personas
In value up software engineering quality is measured as value to the customer. In some
project teams, the customer can participate, in person or via a representative, and provide
the required feedback. In other circumstances, the customer is an abstraction. One way to
make the abstraction of the customer more concrete is to use personas and scenarios.
Personas and scenarios are tools that can be used to understand and communicate the
value of software to a customer.
Personas are the personification (person-ification) of user groups represented as a specific
individual. Personas are intended to be very useful implementation guides for the peopleimplementing a product.
Good personas are:
Memorable.
Three-dimensional.
Sufficiently well described to be decisive when necessary.
Personas describe categories of users in terms of:
Personality.
Work environment.
Usage environment.
Education.
Computer experience.
Any other characteristics that make the imagined person come to life.
7/30/2019 Attendee Manual
66/160
7/30/2019 Attendee Manual
67/160
Module 3: The Business Analysts Perspective 11
Techniques for Capturing Scenarios
In the Microsoft Solutions Framework, functional requirements are written as scenarios.
Scenarios capture the steps necessary for a user to achieve a specific goal. A scenario
includes:
A persona.
A goal.
The steps necessary for the persona to accomplish a goal.
A scenario details how a persona reasons through the specific steps taken as the personaattempts to reach the goal. The goal is stated in the users language. For example, on a
shopping Web service, the end goal of the user may be to place an order.
Throughout iterations, specific sequences in the scenario may evolve, however the goal
should not.
Scenarios capture tangible customer value. Questions in the form of What if you could
[accomplish goal] like [this scenario]? help to establish prototypes and working
functionality. Researching the answers to such questions can involve focus groups and
contextual interviews with users observing and questioning users as they function in
their work environment.Write specific scenarios early and start with the scenario goal. Break down the goal into a
list of steps with a level of granularity that is understandable to the persona and in the
personas language. Focus on defining the problem space, and not the solution.
A good scenario should have one focus -- the goal. It should not capture alternate goals,
paths, and exceptions. If these situations arise, note them and save them as requirements
for another scenario.
7/30/2019 Attendee Manual
68/160
12 Module 3: The Business Analysts Perspective
Once a scenarios sequence is complete, document how the solution is expected to
respond. So for each persona-does-step there is a solution-shows-result. Those steps
that would elicit a wow from a persona are high value scenarios.
Other solution frameworks use different concepts to capture the vision of users and their
requirements. The terms Actor and Use Case are used as part of the Rational Unified
Process. eXtreme Programing uses the concept of user stories.
7/30/2019 Attendee Manual
69/160
Module 3: The Business Analysts Perspective 13
Validating Scenarios
Breaking down a project into iterations allows the customer to have several opportunities
to review the solution as it evolves. One technique to validate scenarios for each iteration
is to answer the following questions:
Do I have enough scenarios? Is it possible to map scenarios from end-to-end so that
they present a complete solution story?
Are the scenarios complete enough so that a customer can provide specific and
meaningful feedback? Are all the steps the customer needs complete? Are all steps
relevant?
Can the test team define positive and negative tests from your scenarios? Can the test
team identify how to test the sequence of steps? Can the test team determine what
data is necessary? Can the test team determine what variations need to be explored?
Can architects and developers identify component interaction? Can architects and
developers identify interfaces? Can architects and developers identify the
dependencies between services? Can architects and developers identify the features
necessary to realize the scenarios?
7/30/2019 Attendee Manual
70/160
14 Module 3: The Business Analysts Perspective
Evolving Scenarios Through the Lifecycle
In early iterations, the high value wow scenarios are developed. As the iterations
progress, add scenarios to cover features that make the software complete and satisfying,
as well as eliminating dissatisfies. This should lead to scenarios that explore alternate
paths through the solution.
If during an iteration you discover that scenarios dont capture the intended functionality
sufficiently for stakeholders, add more detail or extend scenarios.
Dissatisfiers can be difficult to turn into scenarios. This is because dissatisfiers are
usually assumed to be absent. Statements such as you didnt tell me x, the customer
didnt specify x, and x didnt show up in our research are all symptoms of failing to
consider the requirements necessary to eliminate dissatisfiers.
7/30/2019 Attendee Manual
71/160
Module 3: The Business Analysts Perspective 15
Module Review
Designing a software system is about considering the solution to be delivered and
envisioning the details necessary to deliver that solution. Writing a vision statement helps
to capture the problem domain of the software. Personas and scenarios help define the
features necessary to deliver a complete system to the customer. Quality of Service
requirements, and other requirements (Usability, security, etc.) can be captured by
considering specific user needs and questioning whether the requirements as written are
complete.
After completing this module, you are able to:
Describe techniques for capturing functional requirements.
Explain the benefits of using scenarios and personas.
Identify key quality of service requirements that should be captured and tracked.
7/30/2019 Attendee Manual
72/160
Mo u e 3: T e Bus ness Ana yst s Perspect ve
Student Group Exercise: Gathering Requirements
In this group exercise, consider and discuss how you currently capture and manageboth functional and non-functional (QoS) requirements, considering the followingquestions as you do so:
What s the purpose of requirements?
What makes good requirements?
What is a functional requirement?
What is a non-functional requirement?
Where do you get your functional and non-functional requirements from?
What are the most effective and lest effective examples you can think of?
When are requirements knowable?
How do you capture requirements?
How and where do you record them?
Do you expect requirements to change and if so how often?
How do you handle changes to requirements?
How long (typically) do you spend gathering requirements?
At what stage or stages of the lifecycle do you capture them?
How do you decide when you have enough requirements?
How do you validate your requirements?
How do you manage your requirements as your project progresses?
How do you ensure that your requirements are implemented successfully?
7/30/2019 Attendee Manual
73/160
Module 4: The Project ManagersPerspective
Table of Contents
Module Overview 1Lesson 1: Traditional Software Project Management 2
Lesson 2: Value-up Project Management Practices 7
Lesson 3: Monitoring Project Health 16
Lesson 4: Recognizing the Warning Signs 25
Module Review 31
7/30/2019 Attendee Manual
74/160
7/30/2019 Attendee Manual
75/160
Module 4: The Project Managers Perspective 1
Module Overview
This module highlights common problems associated with traditional software project
management theory and presents the theory of value-up project management. The
module goes on to describe techniques project managers can use to evaluate whether their
projects are out of control.
Objectives
After completing this module, you will be able to: Explain the problems inherent with traditional software project management
disciplines.
Describe the benefits of value-up project management practices.
Identify effective metrics that can be used to monitor project health and answer
common project management questions.
Recognize warning signs of out of control projects.
7/30/2019 Attendee Manual
76/160
2 Module 4: The Project Managers Perspective
Lesson 1: Traditional Software Project Management
This lesson describes the characteristics and inherent problems associated with traditional
software project management approaches and disciplines.
Objectives
After completing this lesson, you will be able to:
Explain the problems inherent with traditional software project management.
7/30/2019 Attendee Manual
77/160
7/30/2019 Attendee Manual
78/160
7/30/2019 Attendee Manual
79/160
Module 4: The Project Managers Perspective 5
Whats Wrong with the Iron Triangle?
Traditional project management is based on the Iron Triangle (or tetrahedron if you
include quality as a 4th dimension) view of resource allocation.
The iron triangle view of project management is the concept that there are only three
variables a project manager can manipulate. These are time, resources, and functionality.
Some projects separate quality from functionality and consider quality as a fourth
variable to be managed. In such a case, the iron triangle of project resources has an
additional dimension that captures the quality of a project to form a tetrahedron.
According to this view, a project manager has an initial stock of resources and time. Any
change to functionality or quality requires a corresponding increase in time or resources.
You cannot stretch one face without stretching the other because all of the faces form an
equal area.
In such a model, resource allocation is a zero-sum game. Resource productivity is
uniform, there is little variance in the effectiveness of task completion, and no spare
capacity exists throughout the system.
Agile methods have tended to disprove the iron-triangle model. For example, if a team
improves the flow of value through the system using tools, it is possible to shorten the
amount of time required to produce work items.
7/30/2019 Attendee Manual
80/160
6 Module 4: The Project Managers Perspective
Discussion: Project Management Practices
In this group exercise, students are divided into groups and asked to discuss their own
project management experiences. What works? What doesnt and why not? Students will
be posed the following questions to help guide them.
What are the key questions you want your project managers to be able to answer?
What metrics do you use for assessing whether or not your projects are on track?
How and when do you capture these metrics?
How do you recognize an out of control project what are your key indicators?
How do you control scope creep?
What are your key quality indicators?
How do you measure the quality of the software you develop?
How do your project managers communicate with the wider team?
How effective is your team communication and how could it be improved?
How do you measure the productivity of your development team?
What incentives do you give your developers?
While considering these questions, students will also be asked to think about which of
their practices they would consider embody value-up thinking and which do not. Groups
will present back to the class.
7/30/2019 Attendee Manual
81/160
7/30/2019 Attendee Manual
82/160
7/30/2019 Attendee Manual
83/160
Module 4: The Project Managers Perspective 9
What Is Variation?
The concept of natural variation is central to value-up project management. Variation is
used to distinguish in and out of control projects. Monitoring variation has proved very
difficult to do in the past.
Value-up software development expects variation from expected norms. Variation in a
deliverable is itself normal and an aspect of all process flows. The key point to
understand about variation in value-up software development is that its appearance is
expected and thus predictable within certain bounds. To achieve predictability, you need
to understand the causes of variance and iteratively work to reduce these causes.
Variation can be classified into two types
Common-cause variation.
Special-cause variation.
Common-cause variation is variation that occurs as a part of the process. The presence of
variation is predictable from day-to-day. An illustration is the fact that similar tasks may
take longer or shorter amounts of time to accomplish: a system may not integrate given
the stability of the system on a given day, or a scenario might delight a customer as
expected while another scenario might not. Accepting and planning for such natural
variation is common in project management. A full day may be scheduled for an
integration work item, rather than assuming the system will integrate once all the
development work is complete. Value-up processes accommodate scenarios that have to
be reworked because the customer is dissatisfied by allowing for a following iteration to
improve the feature. Schedules may include pad to deal with unforeseen variation.
Special-cause variation is variation that occurs due to something outside of the process.
7/30/2019 Attendee Manual
84/160
10 Module 4: The Project Managers Perspective
Failing to determine and monitor variation accurately causes mistakes that are
detrimental to the project. Mistake #1 is to react to an outcome as if it came from a
special cause, rather than identifying the variation as a result of a common cause. This
can cause a project manager to miss a systemic problem and dismiss it as a unique
circumstance. Mistake #2 is to treat an outcome as if it came from common causes of
variation, when it actually came from a special cause. This can cause a drain on project-
wide resources or unnecessary changes to the scope of a project as entire processes are
changed.
Tracking and determining the causes of variation have generally been ignored in
traditional software project management simply because broad system and project data
has been very difficult to collect. Even Agile methods have suffered from this difficulty.
For example, the Yesterdays Weather pattern, common to XP and SCRUM, requires a
team not to sign-up for more work in an iteration than was assigned in the previous
iteration. This contradicts the value of iterations. Iterative development allows a team to
continuously learn from its experiences, correct problems with the project through a
manageable process, and to improve the projects processes.
7/30/2019 Attendee Manual
85/160
Module 4: The Project Managers Perspective 11
Exercise: Problems with Prescriptive Metrics
In this group exercise, students will be presented a number of descriptive metrics that
could (but shouldnt) be used to measure productivity. These will include the following:
Measuring programmer productivity based on lines of code written per day.
Rewarding programmers based on number of bugs fixed.
Rewarding the team for creating tests and code to achieve 90% code coverage.
Measuring testers based on number of bugs found.
Students will be asked to consider why using such metrics is counterproductive and leads
to dysfunction.
7/30/2019 Attendee Manual
86/160
7/30/2019 Attendee Manual
87/160
Module 4: The Project Managers Perspective 13
it producing code that is self-documenting and written well enough so bugs are easily
discovered?
Multi-dimensional metrics are more complex metrics that require gathering data from
multiple sources at the same time. Prior to VSTS / TFS, the tools necessary to provide
multi-dimensional measurements have been lacking or deficient.
7/30/2019 Attendee Manual
88/160
14 Module 4: The Project Managers Perspective
Preventing the Distortion
Traditional project management tools produce reports, usually from disparate sources,
about time spent on tasks, bug counts, task completion and resource utilization. Each
measurement is usually reported separately. It was the Project Managers job to gather
these reports and find a way to use these correlate the reports and deduce the state of the
project. In general producing and correlating these reports are an inefficient use of a
Project Managers time.
Value-up project management reads such reports skeptically and sees them only as
approximations of the projects objective -- customer satisfaction with the solution. Theteams real goal is to deliver a product of value to the customer. From the perspective of
traditional project management, measuring the development of customer value is difficult,
especially when the entire project is developed over a long period of time. So available
single-dimensional metrics such as task completion, test pass rate or bug count are used
as easily quantifiable proxies.
Such individual measurements of a software project may be relevant during an iteration.
However, in a value-up paradigm, an iteration is designed to be short enough so that
these easily quantifiable proxies do not have to be relied upon as the measurement of
value delivered. An iteration is complete when the customer receives and evaluates the
delivered feature set. With short iterations that produce discrete features it is possible to
assess the value delivered, and thus the projects health, as frequently as the end of each
iteration. Until the customer can assess a working feature, interim measurements of
quality related to that feature, such as task completion, are hypothetical.
Visual Studio Team Server / Team Foundation Server is designed to facilitate measuring
the health of a project by having a common project backlog maintained in a single work
item database. The work items that make up an iteration are organized into a changeset
7/30/2019 Attendee Manual
89/160
Module 4: The Project Managers Perspective 15
keyed to a versions builds and tests. Such instrumentation allows many dimensions of
project data to be gathered, stored and correlated automatically in a metrics warehouse.
This facilitates frequent assessment of the project during an iteration and allows a Project
Manager to compare data from one iteration to another.
7/30/2019 Attendee Manual
90/160
16 Module 4: The Project Managers Perspective
Lesson 3: Monitoring Project Health
This lesson explains key project health indicators. It will demonstrate how you can
monitor project health using multi-dimensional metrics. It will also show you how
Visual Studio Team System/Team Foundation Server can be used to answer common
project management questions.
Objectives
After completing this lesson, you will be able to:
Identify effective metrics that can be used to monitor project health and answer
common project management questions.
7/30/2019 Attendee Manual
91/160
7/30/2019 Attendee Manual