Agile Forest

Scrum as implemented within teams is something that many of us have been doing for a while. It isn’t a simple implementation, but we have done it for over a decade. As teams begin to invest in applying Scrum at scale, the complicated quickly becomes complex. Methods such as LeSS, Enterprise Scrum, SAFe, DAD and Spotify are good examples of where people have aimed to return this complex set of activities back to complicated.

But they are all missing the realisation of a very simple concept, that all people and teams are not created equal. Sure there is a vast appreciation in these methods of the concept of teams – teams that are autonomous, fully empowered to work with their Product Owner to deliver customer value. These teams, often known as feature teams, pull items of larger work off a portfolio backlog, a backlog recognised to often be owned by someone further up the organisational chain of decision making.

However, where are the technical leaders in this? Where are the managers, be it project managers, or people leaders? Some would argue that in a truly agile organisation such roles shouldn’t exist, and maybe a more lean or autonomous organisation would seek ways to immediately remove these roles. But in a transformation, when so much is in flux, when there are already so many risks of change around, maybe there is another way.

What could the alternative be? What if we could be more tolerant and respect people’s roles and the value that they could provide in these roles?

This blog post is dedicated to such an approach and seeks to discover and highlight the concept of team types.

 

Feature Delivery Teams

The first team type is the one that we all know best. This is the team that does Kanban or Scrum, or whatever else in order to deliver value to customers. This type of team commonly works off a Product Owned backlog.

Interestingly, at scale they can be either one of many teams delivering as part of a product centric focussed tribe or part of a project centric focussed tribe. Which approach of tribal grouping – project versus product would depend on multiple factors.

This team should also be accountable for the outcomes that they deliver to production – work is not considered complete until the benefits have been realised through hypothesis validation, and any production incidents are also owned and resolved by this team. In simple terms, rather than passing off their problem to another group who only do fail and fix, this team “fixes whatever problems it may create”. In this respect, the team will have a clear desire on good quality software and reducing technical debt because they will also own the maintainability of the code. If technical debt or refactoring is ignored by the Product Owner, they will acutely feel the pain of it further down the line and consequently better appreciate the balance of feature delivery with quality.

There are three points that need to be highlighted for feature delivery teams:

• The backlog, owned by a single person, the Product Owner
• This backlog will contain Features and User Stories for the team to work on. This work is expected to provide an outcome that results in either increased customer value, increased customer growth, increased customer retention, increased business revenue or increased cost avoidance. In high feature outcome focussed teams, increased business revenue or increased cost avoidance, are usually related to customer centric features. In a more balanced team, for example one with a stronger devops focus, some features are less direct functional and are more focussed on increased customer retention through reliability and availability of performance. But this balance, or sliding of focus is probably worthy of a separate blogpost.
• The team’s regular cadence around their transparency of work, often known as a Daily Scrum, Daily Standup or a Huddle, is focussed on the individual work items, blockers to progress and potentially the current team goal.

Project Support Team

Not necessarily applicable in all organisations, if the Agile transformation hasn’t tackled removal of the term “Project”, or if it simply makes more sense to bundle together like business goals that cross cut multiple products, then the project support team is an important team to recognise for the value that it provides.

Common activities that this team will own include:

• Managing (solving and potentially further escalating) risks and roadblocks escalated up from the feature delivery teams associated with the project
• Raising risks and issues to the Product Support team if they are more globally impacting than the project itself
• Managing the project financials
• Maintaining user experience consistency across all of the feature teams associated with the project
• Managing cross team dependencies
• Maintain the Project Delivery Roadmap and definition of the Minimal Viable Project

There are three points that need to be highlighted for the Project Support Team:

• The backlog, is owned by a Chief Product Owner, with Feature Delivery Teams executing on the items in the Portfolio backlog through their work with their Product Owner. Arguably the activity of portfolio backlog management could be considered a Project Support Team responsibility, but clear accountability lies with the Chief Product Owner.
• This portfolio backlog will contain significantly large enough activities for a Feature Delivery Team to break down and work on. These could be loosely called “Features” or may be even bigger and called “Initiatives” and “User Stories”. Most of the Project Support Team’s work however is risk and issue management and such doesn’t exist as a backlog but should equally be managed in a transparent manner.
• The team’s regular cadence, more commonly known as a Scrum of Scrums, is focussed on mitigating risks and issues.

Product Support Team

In the duel relationship with the Project Support Team, the Product Support Team is an important group of people who own the multi-team related risks, issues and release activities related to the Product (sometimes considered a platform or channel).

Common activities that this team will own include:

• Managing (solving and potentially further escalating) holistic risk to the product based on release drivers from the feature delivery teams
• Aligning marketing campaigns to potentially drive down multiple messages being released at the same time for the same product
• Working with other areas of the organisation to prepare them for release readiness
• Demonstrating to all teams working on the Product the recent changes- think of this as a multi team Sprint Demonstration so that if teams are working on different projects they have the opportunity to be aligned with how the product is changing
• UX consistency, patterns, standards and alignment where multiple feature delivery teams are impacting the same product zones
• Architectural vision and guidance (note execution should be with the feature delivery teams)
• Performance and penetration testing
• Capability uplift of teams with respect to critical changes to either the product or process to deliver on the product

In a number of cases, the greater the amount of automation that this team or the feature delivery teams can build in to reduce the above activities, the better – especially when it comes to release and testing automation. Note that I haven’t even mentioned production acceptance regression testing as I do fully expect the feature delivery teams to build up this suite.

In SAFe, this is where the Release Train Engineer and the Architecture related elements may fit in, but I don’t really see this team as delivering architectural features, they are responsible for product delivery capability.

There are three points that need to be highlighted for the Product Support Team:

• The backlog, unlike the Project Support Team, is likely a multi Product Owner scenario, with the full Product Support Team driving and agreeing to priority.
• This backlog will contain activities for the team to work on. These could be loosely called “Features” and “User Stories”, but the customer in most of this work is not going to be an end user and is more likely to be an internal customer such as the Project Support Teams, the Feature Delivery Team, Marketing, IT Service Centre, Risk or Compliance areas of the organisation. This work is expected to provide an outcome that results in either increased customer retention (through minimised interruptions/updates), or increased cost avoidance (through risk avoidance).
• The team’s regular cadence, more commonly known as a Scrum of Scrums, is focussed on mitigating risks and issues, transparency and execution of both release management and of capability uplift activities.

Conclusion

I understand that many people will read this blog and go “that’s not very Agile”, but the reality is that a transformation doesn’t happen overnight and unless you have a horde of Agile Coaches going across massive 30,000 people, you are going to have to pick and choose battles, with those battles often not immediately targeting both governance, finance and human resources sections of the organisation.

This is a way of an intermediary step until you may be ready to transform systemic organisationally wide dysfunctions.