Category Archives: Portfolio Management

Bring the Work to the Teams

WorkToTeamAs new high-priority features surface on a large program it can be tempting to give in to demands from stakeholders to assemble a team of the best people from the existing Scrum teams to build those features. Typically someone will suggest plucking the best people from the various Scrum teams and forming a task force. If anyone tries to talk you into doing this, don’t let them. In agile, restructuring the teams should be done sparingly and carefully. It takes a team of people several sprints (and sometimes months) to learn to work together effectively. Reorganized teams also represent change and the range of human factors that come with change. Large scale agile is about bringing the work to the teams, not assembling groups of people for each package of work that needs to be completed.

Another consideration when someone suggests putting together a task force is that it needs a Product Owner, Scrum Master and the various cross-functional roles such as BAs, QA, etc. to be covered. Gutting existing teams to staff these roles leaves the other teams in disarray. And, of course, we would never even consider sharing people across teams, would we?

The next time someone proposes a task force, take a look at how this work can be done by the teams already in place. Chances are pretty good that the work will be completed faster and better by the established teams.

Evolving Team Structures Through the Product Development Lifecycle

One of the most fascinating management challenges is determining the best structure for Scrum teams based on the stage of the project. This does not mean the major waterfall phases like Analysis, Design, Construction, etc. When developing software for use by customers (especially niche SAAS products) and there is some level of customization or specific features for each client, there are at least a couple of distinct stages in the project:

  1. Develop the base product
  2. Develop client-specific features and convert those clients onto the system as those features are completed

Many agile writings suggest that the way to approach system development is to develop some features and put them in production right away so that clients can start using them immediately. In reality, this does not always work. For example, when an existing system is being replaced, clients cannot be put onto a new system that only has 20% of the functionality of the one being replaced. Of course, this does not preclude some form of testing of that 20% by users within the development organization (e.g. by internal client service reps who are also part of the user base).

Organizing for Base Product Development

Typically the base product development effort focuses on developing the major feature areas. The development teams can be organized along the lines of the features areas as depicted below.

Base Product Team

Organizing for Client Conversions and Onboarding

 As the base product nears completion and the teams start to work on client-specific features, the portfolio or program manager may start noticing that the client code complete date for one of the feature teams above is much later than the other teams because the bulk of the customization for that client falls on that one team. The net result is client on-boarding dates are further out in the future that delay realization of new revenue from the product. This is a clear sign that the team structures need to change. At this stage, the focus shifts to optimizing staff utilization while retaining the benefits of teams building features or feature slices from top to bottom. This is called Focused Balance. Work is focused as much as possible on one or a few teams to gain the efficiencies that come with understanding and ownership of the epic , but when necessary client-specific epics are spread across the teams to deliver them as soon as possible.

Client Onboarding Team

Restructuring the teams

When scheduling and work allocation issues require that multiple teams work on the same epic, the following should be considered when deciding who should be on each team:

  • Knowledge about specific feature areas of the system.
  • Technical skillsets. Rebalancing may be necessary when certain feature areas from the base development phase emphasized a particular technical skillset.
  • Technical leadership – most teams need a technical leader.

Cross-Training and Collaboration

Team members will need to step out of their comfort zones and learn other parts of the system. Product owners, who have become experts in the feature areas that their teams constructed in the initial stages of development, will be overseeing a backlog that contains features and stories that are outside of their current area of expertise. Recognizing and fostering the need for collaboration across the teams is critical to the success of this model. At this stage, the job of the product owner is to connect team members with subject matter experts rather than being the subject matter experts.

Reflections:

  • Team structure may need to change to optimize the schedule for client-specific feature development.
  • Restructuring and rebalancing evenly distributes system knowledge and technical skills across the teams.
  • The Product Owner’s role changes to be less of a subject matter expert for their team and more of a facilitator.