Introduction to the Case Study
We are now going to describe what you might expect on a typical DAD team using a fictitious case study based on a retail bank called “BigBank.” The company would like to develop a solution to enable prospective customers to apply for a mortgage online. The solution should be easy to use on both a desktop browser and mobile responsive devices.
After trying Scrum on several teams, BigBank realized that they needed to adopt an agile method that reflects the enterprise challenges they face. In the words of one of their senior developers, “My team doesn't have the time to figure out all the stuff that Scrum doesn't address.” After a bit of investigation, they chose to adopt DAD because it offered the flexibility they required. BigBank liked the fact that DAD includes a life cycle that extends and enhances Scrum's life cycle, allowing them to retain the investment that they've made in Scrum. Given DAD's lack of prescription and focus on pragmatism, BigBank recognized that DAD would scale to meet its diverse needs.
As described previously, DAD provides guidance for the hundreds of decisions made on a typical team. For the purposes of this case study, we will only discuss a small number of decisions with the intent of illustrating how DAD provides lightweight guidance for the entire delivery life cycle. Admittedly, in the interest of brevity, this is an oversimplification of a typical delivery team.
The Team
Let's introduce the team.
Patricia, the product owner: Patricia works for Berhard, the primary business sponsor. She has no technical background but has been asked to be the product owner for this team. She is concerned about having to work full time in the same work area as the rest of the development team.
Barbara, the business analyst: Barbara is a consultant who brings many years of experience with modeling and elicitation of requirements and business process design. She reports to Patricia.
Terry, the team lead: Terry was previously a Certified ScrumMaster® (CSM®), but recently took a DAD workshop that opened his eyes to responsibilities in an enterprise situation that extend beyond just those of scrum master. As such, he took it upon himself to lead the rest of the team.
Carlos, the coach: Carlos is a Green Belt-certified DAD coach and draws upon his years of experience seeing patterns of both success and failure on agile teams. He is coaching several DAD teams besides this one.
Ashok, the architecture owner: Although Ashok is definitely a senior developer, he realizes that being an architecture owner includes responsibilities beyond being the smartest and most experienced developer on the team.
Danny, the developer: Danny is a junior developer who has been with BigBank for two years. Danny is very excited to be on an agile team.
Debbie, the developer: Debbie is an intermediate developer who has worked on web-based systems her entire career. She isn't sure about this new agile approach, but is willing to give it a try.
Tara, the tester: This is Tara's first agile team. She has always applied traditional testing practices on previous teams.
Dick, the database administrator: Dick has always worked on teams that do complete requirements and design at the beginning of the life cycle. He expects that the database logical and physical designs will be completed and reviewed by his group before any coding begins. Terry has explained to him that he will need to take an evolutionary approach, which he is not too happy about. Although Dick is only available to the team 25% of the time, it is his highest priority.
Now, let's introduce the primary stakeholders:
Victoria, the vice president of IT: Victoria has asked this team to pilot the DAD approach and is interested to know how it can help deliver the promise of agile that they have not been seeing from their adoption of Scrum.
Berhard, the business stakeholder and sponsor: Although Berhard is sponsoring this team, he has many other responsibilities.
Chris, the Certified ScrumMaster® (CSM®): Chris is not part of the team, but is an interested observer. He takes a “no compromise” approach to Scrum and is not sure why we would need DAD in addition to Scrum.
Enrico, the enterprise architect: Enrico is responsible for ensuring that all IT solutions are well designed and can support nonfunctional requirements such as security, scalability, and fault tolerance. He is worried about agile teams ignoring standards and existing assets, such as proven services that are available for reuse.
Oliver, the operations manager: Oliver and his team will have to deploy and support this application when it goes into production.
Samira, the support supervisor: Samira manages the support center and is concerned about how issues will be resolved by the team after it is deployed into production.
Mindy, the vice president of marketing: Mindy's team is responsible for all public-facing messaging for BigBank. Her team will need to put the marketing program together for this new customer offering.
Padma, the PMO lead: Padma is responsible for reporting the health of all teams and assessing delivery risk across the IT portfolio.
One of the very first decisions that any team needs to make is which of DAD's six life cycles to use for this team. Based on a suggestion from Terry, the team lead, the team elected to use the Scrum-based agile/basic DAD life cycle for the following reasons:
• The team is new to agile, and the basic life cycle provides sufficient structure for new teams.
• The work can be identified, prioritized, and estimated (at a high level) in advance, although requirements are still expected to evolve over time.
We pick up this case study at the beginning of the Inception phase.