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?
The competitive advantage of Agile is that it promotes what works well in software development: organize/optimize the
process for a
team that works for
the product. Anything is (part of the) process but a process that is effective/efficient will focus on People-Product aggregate.
Any Agile/Not Agile process approach that fails to address these problems together will be less effective and efficient for consistent and continuous 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 ~ Collective Ownership
- 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's responsibilities. Discipline Agile it is also very clear: the (whole) team should own its process. As conclusion: the whole team is responsible for the whole process (~people, product, process).
In this context, what should be the role of the leaders? The first thing to coach others is the responsibility for 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 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 uses
Team Leader role that
is also an agile coach and has a great advantage that could lead by example.
Why Process?
In too many teams the process tailoring will be "throwaway" as being "responsibilities of the others". The team leader could say that it is the responsibility of the project manager, the project manager will believe that it is the responsibility of the team, the team will believe that it is the 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 a 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 the 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.
The 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 sources of failures for software development teams (Agile included) is related to the
product problems: fragile and rigid products that are hard and expensive to change, too many defects and others.
In fact,
product care is the missing link in the 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 to continuously follow the customer business needs.
XP and DA recommend outstanding practices that will address and prevent product problems: TDD, Refactoring, Coding Standards, Pair Programming. DA comes 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 agree on the
Collective Ownership (& Whole team) approach, but in practice, we could have some severe problems.
Collective Ownership is really effective only in high performance, high maturity Agile teams. If it 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 is responsible to make sure that AO, seniors and team members care about the product.
- TL and AO are responsible for making Collective Ownership 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's improvements. The ugly part is that software development 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 the 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 transmit 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 the process, product and other work aspects.
DA uses the Scrum and XP practices but goes 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 strong support for coaching, with three "official" coaching roles: Coach, Team Leader, Architect Owner. That means also high coverage for all work aspects, effectiveness and efficiency.
Collaborative work
Collaborative work is the responsibility of everyone. Without active collaboration, no responsibility will be addressed well in a domain such as software development.
Tools!
People-Product-Process are the main core goal, but all are supported with tools. Scott W. Ambler warns 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.
Update
Read Uncle Bob articles:
Bibliography and recommendations
- [b1] Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck, Cynthia Andres, Addison Wesley Professional , November 16, 2004. Related sections
- Chapter 7 - Primary Practices/Whole Team;
- Chapter 20. Applying XP
- [b2] 12 Habits that Will Make You an Excellent Team Lead - DA blog, July 10, 2013 by Craig Dewalt
- [b3] Roles in Disciplined Agile Delivery - by Scott W. Ambler
- [b4] The DAD Role of Architecture Owner - by Scott W. Ambler
- [b5] Agile Transformation: Comparing Transformation Strategies - by Scott W. Ambler
- [b6] Agile Modeling - http://www.agilemodeling.com/
- [b7] Clean Coders series, by Robert C. Martin
- [b8] Scrum Guide, EN version only - http://www.scrumguides.org/
