Sunday, March 24, 2019

Process Alphabet: Teal Teams and Organizations

Draft Version
See also Process Alphabet

Intro


Starting thoughts and principles:

  • Unlike manufacturing, software development is knowledge work.
  • The key factors for human evolution and developing a civilization was 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 at the team and organizational level



“Teal” in Scrum


Psychological safety climate 
Scrum has as Values “commitment, courage, focus, openness, and respect. (see [SG2017])

Clarity about rights and responsibilities 
In the same time Scrum define 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 encourage cross-functional skills but does not offer too much concrete support (except the collaboration in the Scrum meetings, but it is too little).

Collaborative work to envision, look ahead, and just-in-time clarifications
Scrum prescribe collaboration mostly at the iteration level. Almost nothing about envisioning and just-time, where looking ahead is present only 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.  

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. See above the comments for collaborative work. Also, there is no explicit guidance for community-level collaboration.

Developing awareness at Individual, team, enterprise and community level 
Team level awareness is very clear in Scrum. The problem is that 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 state that “Scrum recognizes no titles for Development Team members.” (see [SG2017]). At the same time in their books (see [S30D] ), for Scrum at scale (Scrum of Scrum), Scrum creators talk about team leads and architects. This approach induces confusions 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.


“Teal” in XP


Psychological safety climate 
XP has as Values “communication, simplicity, feedback, courage, and respect.”(See [XPE2]). Communication and feedback will prevent 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:


  • 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 encourage cross-functional skills for the team members and molt-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
What is missing: 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 and practices dedicated to improvement, but there are also limitations on 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

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.

Pragmatic Agile Roles
XP recognize and describe 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 describe Scaling factors, recommend 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 and that will offer 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.

Collaborative work to envision, look ahead, and just-in-time clarifications 
DA cover all these aspects. Practices like Requirements & Architecture Envisioning, Look Ahead Modeling, and Model Storming are exercised via collaborative work.

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.

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.   

Developing awareness at Individual, team, enterprise and community level 
DA explicitly describe 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.  

Addressing scaling factors at the team and organizational level 
DA explicitly describe roles at scale in conjuction with process blades at 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.

Developing and encouraging cross-functional skills teams 
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.

Collaborative and continuous process tailoring & improvement 
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.  

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.  

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 use kind of Project Manager, while DA use 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 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)


Wednesday, January 2, 2019

Process Alphabet: Continuous Improvement

Draft Version

 

Intro


Development context is continuously changing.
Technology is continuously changing. 
Competition is continuously improving. 
Continuously improving and adapting is a survival concern.

A base for continuous improvement: collaborative work, retrospectives, current life-cycle/process awareness. Retrospectives are fundamental for improvement. Collaborative work is fundamental for retrospectives. 

What should be expected from a method/process approach
  • Continuous improvement goal must be explicitly described as fundamental
  • Support for improvement base should be running
  • Support for improving WoW with guidance for
    • Eliminating Waste
      • Core Agile Practices
      • Adapt to Context (selecting life-cycles, practices, shaping the rolling wave in context)
    • Explicit goals for Evolving WoW (short, medium and long-term)
How to improve: we need the base for improvement and then opportunistically change the WoW: learn new practices, tailor the process by shaping our information rolling wave. 

© Copyright Valentin Tudor Mocanu 2019

Continuous improvement in Scrum


Continuous improvement goal 
It is explicit, in the definition, but with too few support in the content

Continuous improvement base: Collaborative work 
Scrum help teams to start working collaboratively but do not provide real good engineering practices or guidance.  Iteration level meetings are a start for teams that do not collaborate but are too simplistic and too few for professional work.

Continuous improvement base: Retrospective 
Scrum has retrospectives but will be better if the impediments will be also a goal of the team and not only for Scrum Master.  

Guidance for improving WoW 
There very few and too generic, as selecting one problem to solve from the last retrospective. Mainly are just a few lines of text.

Continuous improvement in XP


Continuous improvement goal 
It is explicit, but not “in the title”.

Continuous improvement base: Collaborative work 
XP is based on collaboration.  Collaboration with the customer it is supported by several practices, while development is based on pair programming. Anyway, there is no guidance for pair programming alternatives.

Continuous improvement base: Retrospective XP retrospectives are a kind o Cinderella. They use retrospectives, but they often forgot to mention it in method descriptions

Guidance for improving WoW 
XP is good for learning about Core Agile Practices (see Process Alphabet dedicated section) and about principles related to improvement, but there are no options for life-cycle and for core practices alternatives (excepting few “corollary practices”). Here are some of their principles
  • Definition: “It means continuous awareness, responsiveness to feedback, and openness to improvement
  • Barely good enough: “The cycle is to do the best you can today, striving for the awareness and understanding necessary to do better tomorrow. It doesn't mean waiting for perfection in order to begin.”
  • Optimize the whole: “Micro-optimization is never enough. To improve our results, we must look at the whole situation before deciding what to change
XP has no adapt to process guidance and no concrete goals for evolving WoW (excepting the Core Agile Practices).
 

Continuous improvement in DA


Continuous improvement goal 
It is explicit, and there is associated guidance.

Continuous improvement base: Collaborative work
DA offers more non-solo work practices (beyond pair-programming) and guidance.

Continuous improvement base: Retrospective 
It is explicit, and the responsibility is associated in the right way with the whole team.

Guidance for improving WoW  
This is the most of DA content, guidance for choosing and improving the WoW process goals decisions points, and guidance for Core Agile Practices. 

How to … my custom process


Continuous improvement goal 
Make this goal explicit.
Scrum users: Inspect & Adapt is a good thing but is too vague and too few to be used only on Iteration Reviews and Daily Meetings. Use Disciplined Agile guidance with concrete goals and options. Here the explicit goals: Identify improvements, Share improvements, Support teams, Organize Communities of Practice (CoPs), Organize Centers of Excellence (CoEs), Govern improvement.
XP users: XP guidance about Core Agile Practices is great, but in DA you can find also some missing core practices such as: Architecture Envisioning, Look Ahead Modeling and Planning, Model Storming.  Also, as in the case of Scrum users, the DA concrete improvement goals will help.

Continuous improvement base: Collaborative work 
You will need good coverage for all fundamental collaborative practices: intra-team, inter-teams, and collaboration with stakeholders.
Scrum users: you need to complement the Iteration and Daily Meetings with Pair Programming and the DA practices for collaborative Looking Ahead and Just-In-Time clarifications. For stakeholders collaboration, you will need to complement Product Owner with Active Stakeholder Participations and eventually with On-Site-Customer. Inter-teams knowledge & experience sharing could be done with DA Communities of Practice (CoPs) and Centers of Excellence (CoEs) .    
XP users: as plus versus Scrum, XP has Pair Programing and has additional practices for the collaboration with stakeholders. Anyway, XP does not address well the Retrospectives. For retrospectives and inter-teams collaboration, I have the same recommendation from DA guidance as in the case of Scrum.

Continuous improvement base: Retrospective 
Must be explicitly defined as an improvement meeting with a Whole Team approach.
Scrum users - The remove impediments responsibility should be extended from the Scrum Master to the whole team. Also should be considered DA idea to invite the Product Owner in the Retrospective and also consider DA associate guidance.
XP users should consider the DA guidance about this subject that is neglected in XP.

Guidance for improving WoW – What you need to improve your WoW?

Core Agile Practices  
See Process Alphabet: Core Agile Practices
  • Use XP and DA guidance
Adapt to Context guidance 
See Process Alphabet: Adapt to Context
  • Use DA guidance

Explicit goals for evolving the WoW
Scrum users: again, Inspect & Adapt for Iteration and Daily meeting is useful but is too few. Should be used  the DA concrete goals for Evolving the WoW.
Here are some of the DA guidance subject of interest (you will recognize some of the process alphabet topics):
  • How will we collaborate within the team?
  • What lifecycle will we follow?
  • How do we explore an existing process?
  • What processes/practices will we initially adopt?
  • How will we identify potential improvements?
  • How can we reuse existing practices/strategies?
  • How will we implement potential improvements within the team?
  • How will we capture our WoW?
  • How will we share effective practices with others within our organization?
  • What digital/software tools will we adopt? 

References