In this section the class will explore the nature of software product development and work together to compile a list of challenges that teams traditionally face. We will discuss in detail why software development projects face unique challenges when compared to most other traditional project types. The information we identify and capture will be important as the class progresses, as we will use this information to ensure that our transition strategy will lead the participant's organizations to increased project efficiency and improved product development and delivery.

EXERCISE 1: Defining Our Challenge
Course participants will identify and discuss the biggest or most prevalent project issues their team and organization have experienced? The class will work in teams to compile a list of these issues and then each team will share their experiences with the class.

1. Challenges of Traditional Software Product Development
• Creating a shared understanding of software development
• Understanding a project's "triple constraints"
• Defining the measure of a successful project
• Customer involvement and collaboration
• Investigating scope creep and the nature of scope management
• Managing the development team, managing personalities
• Organizational process requirements and constraints
• Changing customer product expectations
• Reviewing industry data for product development success and failure



EXERCISE 2: Traditional Approaches to Solving Project Challenges
Course participants will identify and discuss what approaches their company or organizational employed to address these common project challenges? How effective were these been in reducing or eliminating these challenges? Have any of these strategies resulted in consistent development and delivery improvement? Each team will share results with the class.

Building on the previous section, we will explore the fundamentals of Agile, and how Agile addresses the challenges of product development. More than simply a methodology or approach to software development, Agile embraces a set of principles that drive effective software development. Agile focuses on the customer, embraces the ever changing nature of business environments and encourages human interaction in delivering outstanding software.

1. The Essentials of Agile
• What is Agile?
• Why utilize Agile when traditional project management methodologies have been used for over 30 years?
• The Agile Manifesto
• The 12 Agile Principles
• The Agile Product Development Lifecycle
• Embracing Change During a Project
• Focusing on the Customer
• Continuous Planning Utilizing the Five Levels of Agile Planning
• Defining Scope on an Agile Project
• The Basics of Iterative Planning and Delivery
• Benefits of Utilizing an Agile Approach for Software Development


2. Forming the Agile Team
• Team Roles and Responsibilities Including the Customer's Role
• Expectations
• Self-Directed, Self-Organizing Teams
• The Nature of Communication and Collaboration



EXERCISE 3: Self-Organizing Teams
Course participants will experience the benefits of self-organization and the direct effects on productivity and team morale. The exercise will also explore how individual contribution and team delivery are used to improve the team's ability to meet customer expectations.

Building on the identification of common project challenges and introducing the fundamentals of Agile, the class will work through associating common waterfall project phases and requirements to their Agile equivalents. The class will work extensively through the details of a typical waterfall project and how each of these areas can be successfully mapped to its Agile equivalent. Following the mapping of each project area, the class will discuss the benefits of making the suggested changes and how to most effectively complete these changes.

1. Project and Product Planning
   Traditional planning approaches prescribe that all planning is complete before development begins, and all development is complete before testing begins. This sequenced approach to product development often is executed outside of customer involvement and regularly results in less than optimal results. We will identify the differences in planning approaches between waterfall and Agile and how to effectively make the transition.


1. Waterfall Practices
• The Project Manager
• Front-loaded planning
• Separation of requirements gathering, development, and testing teams
• Documentation as the primary means of communication and collaboration
• Planning reflects the contract requirements before customer needs
• Plan is set and the development unit attempts to simply "work the plan"


2. Agile Practices
• The Agile Coach
• Team based approach and responsibility for project planning and execution
• Continuous collaboration and continuous planning
• Face-to-face communication
• Self-organizing and self-managed teams held accountable
• Shortened feedback cycles to allow for increased incremental improvement



EXERCISE 4: Experiencing the Cone of Uncertainty
Course participants will experience the difficulty in attempting to plan efforts far in advance of their execution. The exercise results will be related to how we typically front-load our planning efforts in a futile effort to predict the future.

2. Product Requirements
   Excellence in requirements is a necessity regardless of project approach utilized. There is an appreciable difference in how requirements are elicited and documented in waterfall versus Agile, and as we explore these differences, we will do so in the context of efficiency and quality of this process. We will explore some common deficiencies in the traditional approach to requirements gathering including missed requirements, poorly defined requirements, misinterpreted requirements, or ever-evolving requirements based on changing customer needs.


1. Waterfall Practices
• JAD sessions
• Never ending requirements meetings
• Documentation primary means for requirements communication
• Large amounts of effort expended to document detailed requirements for all requested product components
• Changes to requirements after the requirements phase invokes heavy change management processes


2. Agile Practices
• Requirements are gathered at a high-level, in simple to understand language
• The Agile team works directly with customer to properly understand the value of each requirement and its related acceptance criteria
• The Customer (product owner) prioritizes each requirement so that the Agile team is able to deliver in order of priority



EXERCISE 5: Hands-on Requirements Exercise
Course participants will be given the challenge to create a product by following simple instructions given by the trainer. The class will experience just how difficult it is to deliver a project that delights the customer, even when the product is simple in nature.

3. Scope Definition and Management
   Scope is a key component in every software development project and in this section we will explore how Agile teams define and manage the project scope. A traditional project approach prescribes that change needs to be managed, whereas Agile practices allows for the project scope to be pliable in an effort to deliver a higher quality product, in a shorter amount of time, and with the same number of resources.


1. Waterfall Practices
• Changes from baseline must be assessed for timeline and dollar impacts
• The change process must be documented in detail and executed diligently when change is requested mid-project
• Customer sign-off is required for all scope documents so that change is appropriately managed
• Extensive, heavy processes are put in place to address and vet change requests, where the true outcome of these processes serves to inhibit requests for change, even where change may benefit the product


2. Agile Practices
• Change is welcomed as an expected consequence of emergent requirements and product evolution
• Changes are added to the backlog, resulting in a changed feature set prioritization
• Adjustments to the schedule are made as the team adapts to the new elements. These changes are driven by the customer as they make trade-offs in the project's triple constraints
• The customer adjusts priorities as required by business needs, changes in the market, new regulations, etc.
• The team utilizes a burn-down chart to effectively communicate the impact on budget and schedule of requested changes



EXERCISE 6: Defining Scope on an Agile Project
Course participants take a simple project and then as a group will identify the vision for the product. Following the identification of the product vision, the team will then need to work as a team to determine if the new requirements presented would be considered in or out of scope.

4. Product Quality
   The waterfall model typically 'inspects' quality into the process. Final system and integration testing is the first opportunity in the entire product development process where the team and customer find out if what the team built is what the customer needs. This becomes particularly painful when you deliver on time, on budget, and in scope only to experience 'buyers remorse' from the customer: "You built what I asked for but it's not what I need…"


1. Waterfall Practices
• Developers perform unit tests to ensure the component is functional
• Upon completion of development, the code is 'thrown over the wall' for QA testing
• QA maintains primary responsibility for product quality
• Quality is specifically a component of functional adherence to original documented requirements


2. Agile Practices
• The development team is comprised of both developers and QA resources
• Quality is a result of the entire team collaborating regularly with the customer to make adjustments
• As product increments are completed, demonstrations are provided for the customer to allow for the product to emerge based on an evolving competitive landscape
• With each completed iteration, code from earlier iterations is tested regressively and multiple times, creating a very robust code set
• Quality is designed into the product/process and not inspected in with final test cycle



EXERCISE 7: Measuring Quality in our Product
Course participants will work through the exercise building a product over three iterations. Project constraints and objectives will be defined for the teams where the variable of product quality will be examined at the end of the exercise. Following the exercise, the class will discuss the nature of product quality, who defines quality, and how to effectively manage the process to regularly evaluate the emergent quality of the product.

5. Managing People, Personalities, and Process
   It is often said that it is not our processes that develop and deliver great software, it is our people. In this section we will explore the most effective means to manage an Agile team to improve productivity, increase team accountability, and allow for individual resource growth.


1. Waterfall Practices
• The Project manager assigns work to the individual resources on the team, often in small increments
• Feature component planning and development process is not collaborative, no team accountability is practiced or expected
• The project plan is 'etched in stone' and is rarely re-baselined to reflect the current project reality
• Assumes project execution is linear and need for effective collaboration is minimal
• Resource assignments follow a 'top-down' management methodology
• Variances are usually considered negative


2. Agile Practices
• Self-organizing team plans and selects its own work
• Project manager is a facilitator and a coach, managing results and outcomes rather than tasks and assignments
• Design evolves as more is understood about the project
• Collaboration between the team and client results in higher productivity and ownership
• Mistakes are tolerated as a necessary component of learning


6. Product Delivery: The "Big Bang" Approach or Incremental Delivery
   The waterfall approach to software development prescribes that the delivery of the product occurs near the end of the project lifecycle, resulting in a "big bang" approach where there is only one chance to get it right. This type of approach often results in a mismatch between customer expectations and the delivered product, requiring additional work to remediate the disparity. Incremental delivery takes the surprise out of product development, keeping the customer involved in the product's development through maximized exposure to the product. Any disparity between customer expectations and the developed product occur during development, rather than at the end of the lifecycle where changes are most costly.


1. Waterfall Practices
• Project generally proceeds with sequential analysis, requirements, design, coding, and test phases
• Customer does not see a working product until close to the end of the test cycle
• The Processes Change Averse: Discovery or missed requirements can cause delays and add significant dollars to the project budget
• The entire feature set is worked as a single top priority element
• Risk is generally managed by exception and handled as it occurs


2. Agile Practices
• Highest priority features are developed first
• Highest risk factors are addressed early in the project – concurrent engineering practices result in the best architectures and best overall design
• Working elements of the product are delivered in measured increments: the customer sees and experiences the product growing before their eyes
• Discovery and new requirements are merged with the existing product backlog. Rework and delays are relatively small or insignificant



EXERCISE 8: The 'Big Bang' versus 'Small Batch' Approach to Product Development
Course participants will work through a series of iterations, each with the same objective. Each team will utilize a different approach to achieving the iteration goal, keeping track of the team's level of effort and time required to complete. Following the conclusion of the final iteration, the class will discuss the differences between the different approaches.

This portion of the class will explore the challenges of transitioning from waterfall to Agile, effective approaches for addressing these challenges, and key tricks and tips to avoid common downfalls of this endeavor.

1. Challenges of Transitioning from Waterfall to Agile
• Defining your organization's project challenges
• Architecting the problem rather than the solution
• Cultural resistance to change
• Organizational barriers to incremental delivery
• Distributed teams


2. Transition Strategies
• Mapping out Agile processes against current organizational constraints
• Identifying appropriate candidates for first Agile project
• Taking baby steps in adoption
• Defining a 'Hybrid Approach' which encompasses current best practices with process improvements
• Overcoming general resistance to change
• Identifying leaders in the organization that can lead the transition


3. Transition Roadblocks and Myths and How to Navigate Around Them
• MYTH: Agile is undisciplined, comprised of 'cowboy coders'
• MYTH: Agile is nothing but 'galloping scope creep'
• MYTH: Agile does not respect documentation requirements of my industry or organization
• MYTH: My job is going to be eliminated
• MYTH: Agile does not scale for larger projects
• MYTH: Agile sounds great, but it can't work for my company, we are unique
• MYTH: My team would never be able to self-organize, they are too disorganized
• Resources or management with no desire to expose 'bad wiring' and/or fix the broken processes
• The WIIFM Syndrome (what's in it for me?) and how to respond



EXERCISE 9: Constructing Your Own Transition Strategy
Course participants will define the areas where their organization may put up resistance to implementing the agile approach. We will identify where the resistance is due to fear, misunderstanding, lack of training, or some other issue. Each participant will explore avenues of resolution and methods to help the organization harvest the benefits of agile implementations.

While Agile offers significant benefits, many organizations think that they are "locked-in' to their current methodology. Yet in spite of the status-quo, there are a tremendous number of aspects of Agile that can benefit the organization. Which aspects of Agile can help your organization right now? Prepare an action plan to implement such a scenario. Review what we have covered in the course and identify the key areas where your organization may benefit from transitioning to an Agile approach.

EXERCISE 10: Preparing Your Action Plan
Prioritize the Agile concepts that you could introduce in your organization. For the three highest-priority concepts, create an action plan to make those things a reality on your projects. Compare notes with other participants.