- Context Counts-The Agile Scaling Model
- What Is the Disciplined Agile Delivery (DAD) Process Framework?
- People First
- Learning Oriented
- Agile
- A Hybrid Process Framework
- IT Solutions over Software
- Goal-Driven Delivery Lifecycle
- Enterprise Aware
- Risk and Value Driven
- Scalable
- Concluding Thoughts
- Additional Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
Scalable
The DAD process framework provides a scalable foundation for agile IT and is an important part of the IBM agility@scale3 strategy. This strategy makes it explicit that there is more to scaling than team size and that there are multiple scaling factors a team may need to address. These scaling factors are
- Geographical distribution. A team may be located in a single room, on the same floor but in different offices or cubes, in the same building, in the same city, or even in different cities around the globe.
- Team size. Agile teams may range from as small as two people to hundreds and potentially thousands of people.
- Regulatory compliance. Some agile teams must conform to industry regulations such as the Dodd-Frank act, Sarbanes-Oxley, or Food and Drug Administration (FDA) regulations.
- Domain complexity. Some teams apply agile techniques in straightforward situations, such as building an informational Web site, to more complex situations such as building an internal business application, and even in life-critical health-care systems.
- Technical complexity. Some agile teams build brand-new, “greenfield systems” from scratch running on a single technology platform with no need to integrate with other systems. At the other end of the spectrum some agile teams are working with multiple technologies, evolving and integrating with legacy systems, and evolving and accessing legacy data sources.
- Organizational distribution. Some agile teams are comprised of people who work for the same group in the same company. Other teams have people from different groups of the same company. Some teams are made up of people from similar organizations working together as a consortium. Some team members may be consultants or contractors. Sometimes some of the work is outsourced to one or more external service provider(s).
- Organizational complexity. In some organizations people work to the same vision and collaborate effectively. Other organizations suffer from politics. Some organizations have competing visions for how people should work and worse yet have various subgroups following and promoting those visions.
- Enterprise discipline. Many organizations want their teams to work toward a common enterprise architecture, take advantage of strategic reuse opportunities, and reflect their overall portfolio strategy.
Each team will find itself in a unique situation and will need to tailor its strategy accordingly. For example a team of 7 collocated people in a regulatory environment works differently than a team of 40 people spread out across several locations in a non-regulatory environment. Each of the eight scaling factors just presented will potentially motivate tailoring to DAD practices. For example, although all DAD teams do some sort of initial requirements envisioning during the Inception phase, a small team does so differently than a large team, a collocated team uses different tools (such as whiteboards and paper) than a distributed team (who might use IBM Rational Requirements Composer in addition), and a team in a life-critical regulatory environment would invest significantly more effort capturing requirements than a team in a nonregulatory environment. Although it’s the same fundamental practice, identifying initial requirements, the way in which you do so will be tailored to reflect the situation you face.