Sunday, February 12, 2017

Agile Goals: People-Product-Process. Who should be responsible?

A software development team, starting with their leaders, should always care about People, Product, Process. In this order and in parallel. All the core aspect will need the support of Tools.
Too many times teams focus only on (current) delivery and all mentioned aspects are rather ad hoc.  


 Why People-Product-Process?

A competitive advantage of Agile is that promote what works well in software development: organize/optimize the process for a team that work for product. Anything is process, but a process that is effective/efficient will focus on People-Product aggregate.

Any Agile/Not Agile process approach that fail to address these problem together will be less effective and efficient for a consistent and continue process improvement. Example: if the product aspect it is somehow out of scope for Scrum, that will be a default source of problems.    

Who should be responsible ? 

We can identify three kinds of responsibilities in an Agile team
  • Team responsibility as Whole Team 
  • Seniors (considering skills and experience) responsibility, with formal or informal leading roles
  • Coaches     
All Agile methods propose a Whole Team approach. XP is very clear: "We are in this together" "We support each others' work, growth, and learning." [b1].  People, Product & Process are everyone responsibility.  Discipline Agile it is also very clear:  the (whole) team should own its process. As a conclusion: the whole team is responsible for the whole process (~people, product, process). 
In this context, what should be role of the leaders ? The first thing to coach others is the responsibility about things to care and coach/lead by example. Finally, they must lead so these responsibilities to become effective.
In different agile styles and different agile methods, we could have different types of leaders. Here are briefly, the explicit roles in Scrum, XP and Disciplined Agile

XP suggest as first principle "Lead by example": 
"In each case, the gesture is the same: change myself, then offer the fruits of that change to others. Both steps create value. When I change, it's because I've found a way to improve. When I offer new skills to my customers, I pass along these benefits." [b1]
From the start, that is a big problem for the Scrum, where we have only the coach, that usually cannot lead by example. There is no one with explicit "lead by example" responsibility in "orthodox" Scrum. This could be also a problem for XP, where, for example, the Architect is not defined as an Agile leader, but as a role that will rather will be hard to adapt in an Agile process.
Disciplined Agile has redefined the Architect as Architect Owner which has explicit responsibilities of mentoring, coaching and lead by example on technical aspects.  DA use Team Leader role that is also an agile coach and has the great advantage that could lead by example.

Why Process? 

In too many teams the process tailoring will be "throw away" as being "responsibilities of the others". The team leader could say that it is responsibility of the project manager, the project manager will believe that it is responsibility of the team, the team will believe that it is responsibility of the management...
Team Leader involvement: the process should be the responsibility of the whole team ... and as a direct consequence is default responsibility of the TL, that should be also the default process coach of the team. There is no sense to have an TL in an Agile team that does not "lead the process". 
Architect Owner: who else will better understand the technical strategy part of the process? AO experience and skills could help the team to tailor the process to the current technical context.

Scrum Master: a good SM must rely on experience, and best process experience could be acquired as Team Leader (or eventually as Architect Owner). By not specifying "agile" responsibilities for TLs and Architects, Scrum does not have an explicit roadmap to produce good coaches.
Same problem could manifest for XP coaches, were only team members that behave like TLs or AOs could become good coaches.

Disciplined Agile has much more support to lead and initiate an Agile process. Their associated responsibilities for Team Leader and Architect Owner suppose involvement as coaches and leaders by example: "An Excellent Team Lead is like a shepherd for the DAD Team that is guiding the team" [b2] See more on <Why People?>.
More: most of the Disciplined Agile content it is a guidance for tailoring the process to context needs.

Why Product?

One of the most common source of failures for software development teams (Agile included) are the product problems: fragile and rigid products that are hard and expensive to change, too many defects and others.
In fact, the product care it is missing link in processing improvement approach. As Robert C. Martin said, the first responsibility of a programmer is to be able to continuously change the product (see Clean Coders series) in order continuously follow the customer business needs.

XP and DA recommend outstanding practices that will address and prevent the product problems: TDD, Refactoring, Coding Standards, Pair Programming. DA come with more support:  Architecture Envisioning, Proven Architecture Milestones and other Agile Modeling practices plus the process guidance for technical strategy in context. 

All Agile methods agrees on Whole Team approach, but in practice we could have some severe problems. Whole Team is really effective only in high performance, high maturity Agile teams. If does not work, usually there is nothing else to fix and compensate that.

Disciplined Agile has explicit support for solving these problems:
  • AO is responsible for the product, but also coaching
  • TL it is responsible to make sure that AO, seniors and team members care about the product.  
  • TL and AO are responsible for making Whole Team effective, including whole team care about the product 

Why People?

People are the ones that will make the product and apply the process. So, by not caring about people, we will compromise also the product and the process. Software development cannot work well without collaborative work, continuous learning and continuous focus on people improvements. The ugly part is that software development it is a domain were learning and people improvement aspect is ad-hoc and often neglected.

Scrum - collaborative work could help, but is naive to believe that all the needed collaboration could be done only in prescribed meeting. The other kind of people improvement it is rather ad-hoc, and Scrum Master will cover rather only the aspect of the learning the Scrum rules. 

Extreme Programming - offer a foundation of effective practices that help people to learn from each other and help to efficiently transmitting  knowledge: Pair Programming, Move people around, System Metaphor, Coding Standards, TDD. The problem is that anything else is ad hoc and with no explicit responsibilities. Anyway, the leading by example principle is explicit:
"The way to begin organizational change is still to start with yourself. It is the one change you have control over. First develop your skills, then put them into service. Leading by example is a powerful form of leadership." [b1]
We could find real support for "leading by example" in Disciplined Agile, where Team Leaders and Architect Owners have the responsibility to do that for process, product and other work aspects.   
DA use the Scrum and XP practices, but go beyond that. The TLs/AOs first responsibility is to enable and make sure that collaborative work, continuous learning and people improvement focus are happening. Also they could help and guide the team to self-organize and to care about People-Product-Process. 
With DA we have a strong support for coaching, with three "official" coaching roles : Coach, Team Leader, Architect Owner. That mean also high coverage for all work aspects, effectiveness and efficiency.

Collaborative work

Collaborative work is responsibility of everyone. Without active collaboration, no responsibility will be addressed well in a domain such software development.


People-Product-Process are the main core goal, but all are supported with tools. Scott W. Ambler warn about the risk to <Focus on people and Process> and forgot the tools: "Ignoring tools can ease your agile transformation at first but eventually tends to get you into trouble when you start to apply agile in more complex situations.". See more on: Agile Transformation: Comparing Transformation Strategies.

Bibliography and recommendations