Draft Version
Intro
Starting thoughts and principles:
- Unlike manufacturing, software development is knowledge work.
- The key factors for human evolution and developing a civilization were extensive cooperation and better distribution of knowledge
- Teal organization: cellular, self-organizing, adaptive, aware, with evolutionary purposes
- Treat people with respect, honesty, be reliable, open and willingly collaborate with others
Expectation support from the method
 |
| © Copyright Valentin Tudor Mocanu 2019 |
- Psychological safety climate and clarity about rights and responsibilities
- Developing and encouraging cross-functional skills teams
- Collaborative work to envision, look ahead and just-in-time clarifications.
- Collaborative and continuous process tailoring and improvement
- Inter-teams’ collaboration and communities
- Developing awareness at Individual, team, enterprise and community level
- Pragmatic Agile Roles
- Addressing scaling factors for a team of teams and organizational levels
“Teal” in Scrum
Psychological safety climate
Scrum has as Values “commitment, courage, focus, openness, and respect.” (see [SG2017])
Scrum has as Values “commitment, courage, focus, openness, and respect.” (see [SG2017])
Clarity about rights and responsibilities
Scrum defines some clear rights and responsibilities for roles and categories of roles as:
Scrum defines some clear rights and responsibilities for roles and categories of roles as:
- “Significant aspects of the process must be visible to those responsible for the outcome” (see [SG2017])
- “The Development Team is responsible for all estimates.” (see [SG2017])
The main problem here is that Scrum covers a small part of a process and so its description for rights and responsibilities.
Developing and encouraging cross-functional skills teams
Scrum encourages cross-functional skills but does not offer too much concrete support ( only the Scrum meetings activities are not enough).
Scrum encourages cross-functional skills but does not offer too much concrete support ( only the Scrum meetings activities are not enough).
Collaborative work to envision, look ahead, and just-in-time clarifications
Scrum prescribes collaboration mostly at the iteration level. Almost nothing about envisioning and just-time, and looking ahead is presented as “refining” that is too vague (not explicitly described trough practices).
Scrum prescribes collaboration mostly at the iteration level. Almost nothing about envisioning and just-time, and looking ahead is presented as “refining” that is too vague (not explicitly described trough practices).
Collaborative and continuous process tailoring and improvement
Scrum has almost nothing beyond retrospectives, where continuous improvement cannot rely only on retrospectives.
Scrum has almost nothing beyond retrospectives, where continuous improvement cannot rely only on retrospectives.
Inter-teams’ collaboration and communities
There is no related guidance in Scrum Guide, only in Scrum of Scrums and Scrum extensions. In the Scrum of Scrum, collaboration mirrors the standard Scrum meetings but is not enough. Also, there is no explicit guidance for organization-level and community-level collaboration.
There is no related guidance in Scrum Guide, only in Scrum of Scrums and Scrum extensions. In the Scrum of Scrum, collaboration mirrors the standard Scrum meetings but is not enough. Also, there is no explicit guidance for organization-level and community-level collaboration.
Developing awareness at Individual, team, enterprise and community level
Team level awareness is very clear in Scrum. Scrum does not explicitly address enterprise and community level awareness.
Team level awareness is very clear in Scrum. Scrum does not explicitly address enterprise and community level awareness.
Pragmatic Agile Roles
Scrum seems to be very clear and explicit about “Scrum roles” but has two very different voices. Scrum Guide states that “Scrum recognizes no titles for Development Team members.” (see [SG2017]). At the same time in their books (see [S30D] ), for the Scrum at scale (Scrum of Scrum), Scrum creators talk about team leads and architects. This approach induces confusion among Scrum practitioners.
Scrum seems to be very clear and explicit about “Scrum roles” but has two very different voices. Scrum Guide states that “Scrum recognizes no titles for Development Team members.” (see [SG2017]). At the same time in their books (see [S30D] ), for the Scrum at scale (Scrum of Scrum), Scrum creators talk about team leads and architects. This approach induces confusion among Scrum practitioners.
Addressing scaling factors at the team and organizational level
Scrum Guide does not explicitly address scaling factors. Scrum of Scrums and Scrum extension address explicitly only the team size (team of teams) aspect.
Scrum Guide does not explicitly address scaling factors. Scrum of Scrums and Scrum extension address explicitly only the team size (team of teams) aspect.
“Teal” in XP
Psychological safety climate
XP has as Values “communication, simplicity, feedback, courage, and respect.”(See [XPE2]). Communication and feedback will prevent the accumulation of misunderstandings. XP has among its principles: humanity, mutual benefits, and diversity.
XP has as Values “communication, simplicity, feedback, courage, and respect.”(See [XPE2]). Communication and feedback will prevent the accumulation of misunderstandings. XP has among its principles: humanity, mutual benefits, and diversity.
Clarity about rights and responsibilities
XP is clear about responsibilities and the rights are rather implicit (if everyone is responsible in a good way, the rights of everybody will be respected). Here some examples:
XP is clear about responsibilities and the rights are rather implicit (if everyone is responsible in a good way, the rights of everybody will be respected). Here some examples:
- Always sacrificing your own needs for the team's doesn't work. If I need privacy, I am responsible for finding a way to get my need met in a way that doesn't hurt the team.” (See [XPE2])
- Collective Ownership – “The team members can collectively assume responsibility not just for the quality of what they deliver to users but also for the pride they take in their work along the way” (See [XPE2]), “Shared Code”)
Developing and encouraging cross-functional skills teams
XP encourages cross-functional skills for the team members and a multi-role approach. XP has the principle of accepted responsibility, specifying that you will be responsible for all development aspects of the work: estimates, design, implementation, test. (See [XPE2], “Accepted Responsibility”)
XP encourages cross-functional skills for the team members and a multi-role approach. XP has the principle of accepted responsibility, specifying that you will be responsible for all development aspects of the work: estimates, design, implementation, test. (See [XPE2], “Accepted Responsibility”)
Collaborative work to envision, look ahead and just-in-time clarifications
- Values level – communication, feedback
- Practices: sit together, collective ownership, pair programming
- Just-in-time is covered well by pair programming
- "Collective Ownership” is a composite practice; it is not enough to declare it (declaration-only remain at principle-only level), but you will also need to specify practices for envisioning and looking ahead level collaboration
Collaborative and continuous process tailoring and improvement
Pair programming will help a lot but there are also limitations to collaborative work (see above). Retrospectives are too often forgotten in the guidance.
Pair programming will help a lot but there are also limitations to collaborative work (see above). Retrospectives are too often forgotten in the guidance.
Inter-teams’ collaboration and communities
Very short guidance: “integrate frequently” and planning guidance could help
Very short guidance: “integrate frequently” and planning guidance could help
Developing awareness at Individual, team, enterprise and community level
Individual and team level awareness (Collective Ownership) is very clear and explicit in XP. Enterprise and community-level awareness are not explicitly addressed.
Individual and team level awareness (Collective Ownership) is very clear and explicit in XP. Enterprise and community-level awareness are not explicitly addressed.
Pragmatic Agile Roles
XP recognizes and describes more roles(See [XPE1],[XPE2]): programmer, customer, coach, tracker (project manager), tester, consultant, big boss (manager), interaction designers (~system analyst), product manager. XP has the principle of accepted responsibility (see cross-functional skills). XP is pragmatic by recognizing more roles, but at the same time recommending fewer specialists (consultants) and cross-functional skills.
XP recognizes and describes more roles(See [XPE1],[XPE2]): programmer, customer, coach, tracker (project manager), tester, consultant, big boss (manager), interaction designers (~system analyst), product manager. XP has the principle of accepted responsibility (see cross-functional skills). XP is pragmatic by recognizing more roles, but at the same time recommending fewer specialists (consultants) and cross-functional skills.
Addressing scaling factors at the team and organizational level
XP describes Scaling factors, recommends process tailoring for these factors, but does not offer guidance.
XP describes Scaling factors, recommends process tailoring for these factors, but does not offer guidance.
“Teal” in DA
Psychological safety climate and clarity about rights and responsibilities
Clear & concrete definitions for rights and responsibilities for everyone ~ concrete support for psychological safeness.
DA Principle Be Awesome: treat people with respect, honesty, be reliable, open and willingly collaborate with others
Developing and encouraging cross-functional skills teams
Teams composition should be made mostly of cross-skilled developers, and DA recommends using Generalizing Specialists - this the pragmatic way to apply the cross-skills principle.
Teams composition should be made mostly of cross-skilled developers, and DA recommends using Generalizing Specialists - this the pragmatic way to apply the cross-skills principle.
Collaborative work to envision, look ahead, and just-in-time clarifications
DA covers all these aspects. Collaborative work practices: Requirements & Architecture Envisioning, Look Ahead Modeling, Model Storming, Pair Programming, Active Stakeholder Participation.
DA covers all these aspects. Collaborative work practices: Requirements & Architecture Envisioning, Look Ahead Modeling, Model Storming, Pair Programming, Active Stakeholder Participation.
Collaborative and continuous process tailoring and improvement
DA offers tailoring guidance for team decisions along the for the full delivery life-cycle, and the team will own its process.
DA offers tailoring guidance for team decisions along the for the full delivery life-cycle, and the team will own its process.
Inter-teams’ collaboration and communities
DA offers guidance for a team of teams’ organization, development teams’ collaboration with Enterprise Architects, and at DevOps, IT and Enterprise Level. There is Guidance for Community of Practices and Center of Excellence.
DA offers guidance for a team of teams’ organization, development teams’ collaboration with Enterprise Architects, and at DevOps, IT and Enterprise Level. There is Guidance for Community of Practices and Center of Excellence.
Developing awareness at Individual, team, enterprise and community level
DA explicitly describes awareness ay individual, team, enterprise, and community level. Enterprise Awareness is one of the key aspects of DA and more practices along the life-cycle will target this part.
DA explicitly describes awareness ay individual, team, enterprise, and community level. Enterprise Awareness is one of the key aspects of DA and more practices along the life-cycle will target this part.
Pragmatic Agile Roles
DA proposes a pragmatic approach: to use the roles that work in practice for Agile. Primary roles in DA: Team members, Team Leader, Architect Owner, Product Owner, and stakeholders. Also, in practice, especially for larger teams, you will need some secondary roles as Specialists, Independent Testes and Domain Experts.
DA proposes a pragmatic approach: to use the roles that work in practice for Agile. Primary roles in DA: Team members, Team Leader, Architect Owner, Product Owner, and stakeholders. Also, in practice, especially for larger teams, you will need some secondary roles as Specialists, Independent Testes and Domain Experts.
Addressing scaling factors at the team and organizational level
DA explicitly describes roles at scale in conjunction with process blades at the Development team, DevOps, IT and Enterprise level.
DA explicitly describes roles at scale in conjunction with process blades at the Development team, DevOps, IT and Enterprise level.
How to … my custom process
Psychological safety climate and clarity about rights and responsibilities
Scrum and XP practitioners could also use the DA explicit description of rights of responsibilities. It is important to have concrete practices and rules for developing a psychological safety climate.
Scrum and XP practitioners could also use the DA explicit description of rights of responsibilities. It is important to have concrete practices and rules for developing a psychological safety climate.
Developing and encouraging cross-functional skills teams
Scrum and XP practitioners could use DA pragmatic recommendation for using Generalizing Specialists.
Scrum and XP practitioners could use DA pragmatic recommendation for using Generalizing Specialists.
Collaborative work to envision, look ahead, and just-in-time clarifications
Scrum and XP practitioners could complement their approach with DA collaborative practices & guidance for envisioning, look ahead, but also for just-in-time clarifications.
Scrum and XP practitioners could complement their approach with DA collaborative practices & guidance for envisioning, look ahead, but also for just-in-time clarifications.
Collaborative and continuous process tailoring & improvement
Scrum and XP practitioners could complement their approach with DA tailoring guidance.
Scrum and XP practitioners could complement their approach with DA tailoring guidance.
Inter-teams’ collaboration and communities
Scrum and XP practitioners could complement their approach with DA guidance for collaboration across teams, DevOps, IT and Enterprise.
Idem for Communities of Practice and Center of Excellence.
Scrum and XP practitioners could complement their approach with DA guidance for collaboration across teams, DevOps, IT and Enterprise.
Idem for Communities of Practice and Center of Excellence.
Developing awareness at Individual, team, enterprise and community level
Scrum and XP practitioners could complement their approach with DA guidance for enterprise and community awareness. Warning: trying to adopt agile and improve the process is fragile if you disregard the enterprise level.
Scrum and XP practitioners could complement their approach with DA guidance for enterprise and community awareness. Warning: trying to adopt agile and improve the process is fragile if you disregard the enterprise level.
Pragmatic Agile Roles
XP and DA are using pragmatic agile roles, while Scrum is vague and ambiguous. There are differences between XP and DA: XP still uses kind of Project Manager, while DA uses the Product Owner. More: DA has a lighter approach, has more guidance and more oriented to leader-as-coach (team leaders, architects) approach.
XP and DA are using pragmatic agile roles, while Scrum is vague and ambiguous. There are differences between XP and DA: XP still uses kind of Project Manager, while DA uses the Product Owner. More: DA has a lighter approach, has more guidance and more oriented to leader-as-coach (team leaders, architects) approach.
Addressing scaling factors at the team and organizational level
Scrum practitioners could find more about other scaling factors excepting team size in XP and DA. Both Scrum and XP practitioners could use DA guidance customizing the way of working depending on the scaling factors that are facing it in their context. Some scaling factors as geographical and organizational distribution are directly related to the team and organization/enterprise aspects.
Scrum practitioners could find more about other scaling factors excepting team size in XP and DA. Both Scrum and XP practitioners could use DA guidance customizing the way of working depending on the scaling factors that are facing it in their context. Some scaling factors as geographical and organizational distribution are directly related to the team and organization/enterprise aspects.
References (draft)
- [SG2017] – Scrum Guide - https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
- [XPE1] – Extreme Programming Explained First Edition, By Kent Beck, Addison-Wesley, 1999
- [XPE2] – Extreme Programming Explained: Embrace Change, Second Edition, By Kent Beck, Cynthia Andres, Addison-Wesley, 2004
- [S30D] - Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust 1st Edition, by Jeff Sutherland and Ken Schwaber, Wiley; 1 edition (May 1, 2012)
- DA Right and Resposabilities
- Generalizing Specialist
- Communities of Practice (CoPs)
- Center of Excellence (CoE) -
- DAD Roles
- https://disciplinedagiledelivery.com/roles-on-dad-teams/
- DA Roles at Scale
No comments:
Post a Comment