COURSE 4815 | 2-DAY SESSION
Transitioning from Waterfall to Agile
Course outline
Section I: Introduction to Agility
Agility is comprised of a unique set of principles and values that must be understood and embraced before the organization can employ Agile practices. In this section, we will survey the essence of Agility.
Exercise
To establish a basis for your exercises, you will first compile a list of the things in your organization that are “broke”, and “need fixin’”. This list will provide a touchstone for the exercises that follow.
- The Essence of Agility
- The Agile Lifecycle
- Learning and Adaptation
- Collaboration
- Customer Focus
- Self-Directed Teams
- Lean Principles
- Progressive Requirements Elaboration
- Incremental Delivery
- Iterative Planning and Adaptation
Exercise
Some organizations have already integrated some facets of Agility into their processes (even if they call them by other names). After exploring the Essence of Agility, you will look for ways in which yourorganization has embraced any of those concepts. These are your beginning points from which you can become *more* agile!
Section II: Us vs. Them Teams
The heart of every project is the team. Yet in traditional approaches, the team often operates as a collection of competing individuals, rather than as a unit. Even worse, many organizations have divided responsibilities in ways that pit different groups against each other, when the project desperately needs cooperation. Agility means establishing a single team for each project, and ensuring that it comprises all of the necessary people.
- Traditional practices
- The project manager
- Shielding developers & customers from each other
- Building silos of responsibility
- Documents as the primary means of communication
- Lessons Learned at project end
- Contrast with the Agile approach
- The Agile coach
- One big co-located team
- Continuous collaboration
- Face-to-face communication
- Regular feedback
- Regular retrospectives
Case Studies
How can different types of organizations change from team structures that segregate and isolate people to more collaborative and open mode of interaction? The larger and more formal the organization, the more challenging this change will be. The three case study organizations provide examples of how to build collaborative teams when faced with different issues.
Exercise
In this exercise, you will determine how Agile teaming could benefit your organization, and identify which of the case studies’ lessons can help your organization embrace and implement collaborative teams.
Section III: My Project Plan, Right or Wrong
Traditional approaches are often referred to as “plan-based” because of the importance they put on up-front planning and then controlling the project so it conforms to the plan. Of course, some organizations go to the other extreme, paying little attention to their plans after the project starts, or even foregoing planning altogether. Agility means planning just enough, doing that planning when it is needed, and accepting the fact that reality often works out differently from our plans. Agile projects value achieving the project goals; the plan is merely a tool to help them do that.
- Traditional practices
- Predictive planning
- Command and control management
- Corrective action (Conformance to plan)
- Periodic Status Reporting
- Document review/sign-off as milestones
- Contrast with the Agile approach
- Time-boxed projects & iterations
- Incremental planning & estimation
- Self-directed teams
- Daily status checks & periodic review
- Adaptation to new information
- Information Radiators
- Software delivered regularly
Case Studies
How can different types of organizations change to self-directed teams that adapt to project realities? The three case study organizations provide examples of how to make the case for a different way of planning projects, and how to make it happen.
Exercise
How can your organization change to self-directed teams and incremental planning? In this exercise, you will determine how Agile planning could benefit your organization, and identify which of the case studies’ lessons can help your organization embrace and implement self-directed teams
Section IV: The Insidious Creeping Scope
Traditional approaches usually begin with an important (and sometimes long and drawn out) Requirements phase during which all of the product requirements are elicited, analyzed and documented. Everyone in the project commits to the resulting specification, and then significant effort is expended in Change Control. Conformance to the Requirements Specification becomes the measure of project success. (Until the customer complains!) Agility means documenting requirements just enough, eliciting more detailed information when it is needed, and accepting the fact that things will change before the project is over.
- Traditional practices
- Big-bang, up-front requirements definition
- Requirements sign-off
- Little customer involvement after requirements
- Restrictive change control
- Conformance to specification
- Product delivered/accepted at project end
- Contrast with the Agile approach
- Product vision by the customer
- Incremental requirements definition
- Welcome changing requirements
- Prioritization by the customer
- Iteration goals by the customer
- Incremental product acceptance & feedback
Case Studies
The three case study organizations provide examples of how to make the case for a different way of defining requirements, and how to make it happen.
Exercise
How can your organization change to progressive requirements elaboration? In this exercise, you will determine how Agile requirements could benefit your organization, and identify which of the case studies’ lessons can help your organization embrace and implement an Agile requirements method.
Section V: Where’s the Quality?
Traditional projects are often quality-challenged. The testing phase at the end of the project seems to be never-ending, and in spite of all that time and effort, a defective product is delivered. This results in high support costs, unhappy customers and out of control costs. Agility means keeping the focus on quality from the very beginning of the project, testing continuously and ensuring that every piece of code is technically excellent. And because testing is not saved for the end, quality surprises are eliminated. Agility means producing production-ready software regularly throughout the project!
- Traditional practices
- Little focus on developer verification
- Testers responsible for quality
- Testing postponed to the project end
- Contrast with the Agile approach
- Developers focused on technical excellence
- Test-Driven Development (TDD)
- Developer/tester/customer collaboration/feedback (Pair Programming)
- Testers as members of the development team
- Early and regular "System" & "Acceptance" testing
- Each product increment production-ready
Case Studies
How can different types of organizations move the quality focus from a check at the end to a central focus of the technical work? This will almost certainly require that the developers (and possibly others) adopt a new view of their responsibilities. The three case study organizations provide examples of how to make this kind of radical transformation of attitudes and actions about quality.
Exercise
There is so much we could do, but the organization can only absorb so much change. Some things are more achievable than others, and some will bring more benefits. In this last exercise, you will identify the “low-hanging fruit” for *your* organization -- those things that are both within your reach, and would be oh-so-sweet! Then you will compile a plan to harvest this low-hanging fruit.
Section VI: Course Wrap-Up
There is too much to Agility for you to adopt all at once, so you will need an action plan. Review what we have covered in the course and prepare a viable action plan for your organization.
- Review the Essence of Agility
Exercise
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 student