- 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
People First
Alistair Cockburn refers to people as “non-linear, first-order components” in the software development process. His observation, based on years of ethnographic work, is that people and the way that they collaborate are the primary determinants of success in IT solution delivery efforts. This philosophy, reflected in the first value statement of the Agile Manifesto, permeates DAD. DAD team members should be self-disciplined, self-organizing, and self-aware. The DAD process framework provides guidance that DAD teams leverage to improve their effectiveness, but it does not prescribe mandatory procedures.
The traditional approach of having formal handoffs of work products (primarily documents) between different disciplines such as requirements, analysis, design, test, and development is a very poor way to transfer knowledge that creates bottlenecks and proves in practice to be a huge source of waste of both time and money. The waste results from the loss of effort to create interim documentation, the cost to review the documentation, and the costs associated with updating the documentation. Yes, some documentation will be required, but rarely as much as is promoted by traditional techniques. Handoffs between people provide opportunities for misunderstandings and injection of defects and are described in lean software development as one of seven sources of waste. When we create a document we do not document our complete understanding of what we are describing, and inevitably some knowledge is “left behind” as tacit knowledge that is not passed on. It is easy to see that after many handoffs the eventual deliverable may bear little resemblance to the original intent. In an agile environment, the boundaries between disciplines should be torn down and handoffs minimized in the interest of working as a team rather than specialized individuals.
In DAD we foster the strategy of cross-functional teams made up of cross-functional people. There should be no hierarchy within the team, and team members are encouraged to be cross-functional in their skillset and indeed perform work related to disciplines other than their specialty. The increased understanding that the team members gain beyond their primary discipline results in more effective use of resources and reduced reliance on formal documentation and handoffs.
As such, agile methods deemphasize specific roles. In Scrum for instance, there are only three Scrum team roles: ScrumMaster, product owner, and team member. Nonteam roles can be extended to stakeholder and manager. The primary roles described by DAD are stakeholder, team lead, team member, product owner, and architecture owner. These roles are described in detail in Chapter 4, “Roles, Rights, and Responsibilities.”
Notice that tester and business analyst are not primary roles in the DAD process framework. Rather, a generic team member should be capable of doing multiple things. A team member who specializes in testing might be expected to volunteer to help with requirements, or even take a turn at being the ScrumMaster (team lead). This doesn’t imply that everyone needs to be an expert at everything, but it does imply that the team as a whole should cover the skills required of them and should be willing to pick up any missing skills as needed. However, as you learn in Chapter 4, DAD also defines several secondary roles often required in scaling situations.
Team members are often “generalizing specialists” in that they may be a specialist in one or more disciplines but should have general knowledge of other disciplines as well. More importantly, generalizing specialists are willing to collaborate closely with others, to share their skills and experiences with others, and to pick up new skills from the people they work with. A team made up of generalizing specialists requires few handoffs between people, enjoys improved collaboration because the individuals have a greater appreciation of the background skills and priorities of the various IT disciplines, and can focus on what needs to be done as opposed to focusing on whatever their specialties are.
However, there is still room for specialists. For example, your team may find that it needs to set up and configure a database server. Although you could figure it out yourselves, it’s probably easier, faster, and less expensive if you could have someone with deep experience help your team for a few days to work with you to do so. This person could be a specialist in database administration. In scaling situations you may find that your build becomes so complex that you need someone(s) specifically focused on doing just that. Or you may bring one or more business analyst specialists onto the team to help you explore the problem space in which you’re working.
DAD teams and team members should be
- Self-disciplined in that they commit only to the work they can accomplish and then perform that work as effectively as possible
- Self-organizing, in that they estimate and plan their own work and then proceed to collaborate iteratively to do so
- Self-aware, in that they strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly
Although people are the primary determinant of success for IT solution delivery projects, in most situations it isn’t effective to simply put together a good team of people and let them loose on the problem at hand. If you do this then the teams run several risks, including investing significant time in developing their own processes and practices, ramping up on processes or practices that more experienced agile teams have discovered are generally less effective or efficient, and not adapting their own processes and practices effectively. We can be smarter than that and recognize that although people are the primary determinant of success they aren’t the only determinant. The DAD process framework provides coherent, proven advice that agile teams can leverage and thereby avoid or at least minimize the risks described previously.