Make great things

Scrum and other frameworks are guides. The best practices and activities in this chapter have been distilled from years of sweat and hard work, so do consider implementing them in addition to the rituals observed by the team within a sprint.

Each project is nuanced, and each team is different. The goal is to ship great software that exceeds client expectations, so improvise and evolve the frameworks to suit the specific project after becoming comfortable with the fundamentals in this book.

Reviewing technical architecture

While small, experienced teams do not need architecture review sessions each and every sprint, large pods that integrate into the client ecosystem most certainly do. Here’s why:

• They assess the impact of decisions. The session facilitates debate about a gamut of architectural decisions and their impacts on all teams (internal and external).
• They facilitate knowledge sharing. The session equalizes knowledge across multiple teams from a technical design perspective. While the target state is always to have mature teams, the reality is that all teams experience changes that affect their knowledge base (e.g., people leave and new members are added). Use these sessions to train and onboard new members or further educate teams into the domain.
• They aid in adherence to enterprise design. The session may be valuable from an enterprise compliance perspective. In other words, the team may inherit some necessary architecture from the enterprise, which means the team must be transparent with their implementation.

Reviewing design

Product design plays an important role in software success. In certain instances (especially in a B2C context), UI design plays an important and highly regulated role. Whether it’s fitting within an established design system, complying with accessibility requirements, or working closely with the enterprise marketing team, design review sessions may need to be set up in parallel to other sprint rituals.

Ideally, product designers have a future vision—a few sprints’ worth of refined backlog. The team can collectively decide which features and stories require design approval before the engineers picking up the stories for implementation.

Planning releases

Release planning is governed by the overarching goals of the product. Include this discussion as part of the state of the union or reworkshopping sessions. Alternatively, facilitate release planning as a separate session.

Throughout delivery, the product manager and the key stakeholder should keep an eye on the overall progress toward the next scheduled release, as well as on the product roadmap beyond. Release planning sessions lift the ongoing product conversation to a more strategic level that covers the product schedule, funding, and objectives; the active SOW as well as any need for future SOWs and funding; and the data necessary to warrant investment after the initial phase of the project is completed.

Managing scope

Scope creeps happen. Set this expectation within Devbridge and for the client. For some clients, such as large banks, the notion of deprioritizing backlog items does not apply as the associated funds are backed by a business case guaranteeing a certain set of features. Other clients, as scope increases, have flexibility in backlog priorities and what needs to be achieved in the MVP.

Beyond setting expectations, the best method for managing scope creep is early identification and prolific communication in the form of change requests.

Start managing this expectation as early as the workshop with the following in mind:

• Assume the workshop identifies at most 60 percent of the ultimate complexity.
• Include such assumptions in the estimate and present said estimate to the client with the identified variance.
• Explain to the client that this data is based on historic data but is by no means a guarantee.

Capture each increase in complexity, shift of assumptions, and change to an existing story definition as a separate Jira ticket and marked as a change request. This demonstrates to the client what percentage of total spend is necessary for changes throughout delivery, perhaps positively influencing future rounds of funding. Use the following general guidelines for change requests:

• Establish a backlog for out-of-scope functionality. Every time the development team discovers new functionality or more complex implementation (i.e., implementation complexity that does not match the initial assumptions), the project lead notes it in the backlog. Each item is marked with a dedicated label in order to note and export easily.
• Consistently review and update the out-of-scope backlog items. Our PM and project lead should evaluate the out-of-scope item list every week to determine what stays and what is removed. Close irrelevant items and update the changes with a due date within a single sprint.
• Issue the change request. Once reviewed and estimated, a change request is issued by the product manager within a week.

Err on the side of pessimism and caution when identifying out-of-scope functionality. Because all backlog items are sized at 50 percent or less of total sprint size, ensure the team has enough flexibility to absorb a reasonable change in complexity. If the change is significant enough or the story is not able to close within a sprint, this is a good indication of scope creep.

Last, even if you are funded based on outcomes, tracking changes in Jira will give you invaluable data when the next funding cycle comes around.

Recognizing debt

Compromises made while writing software are known as technical debt. All teams incur debt in an effort to take software to market in a reasonable time. Some debt is acceptable and (as long as someone is keeping track) easily addressed when under less time constraints. Other debt may be crippling to the team and the product—from performance issues to poorly designed architecture that results in difficulties maintaining software.

Product debt is a similar concept that extends beyond development and includes compromises made in usability, accessibility, features, and the like. Debt is acceptable to incur for the sake of launching a product. Teams always work within constraints of time, quality, and cost. How the team identifies which debt is acceptable and “good for the product” is important.

The following illustration explains the different types of technical debt:

Always track and estimate debt as stories in the backlog. Monitor the size of technical or design debt throughout delivery, especially for large product rollouts; be mindful of debt size in contrast to the remaining backlog size. Consider reporting debt and future rework needs to your stakeholders to manage expectations and prepare for the V2 roadmap.

Good debt: Intentional and professional

Good debt is incurred when an easier, faster solution is selected intentionally with full awareness of the long-term impediments. A senior team member weighs the pros and cons to determine that the benefits outweigh the compromises before taking action.

Mistake debt: Accidental and professional

Mistake debt is incurred when a mature team with the necessary technical skills makes a bad decision—from too little context, too little information, too little time. For example, functionality rework falls into this category as the product matures and collects user feedback. While the initial implementation aligns with the objectives, outside rationale (e.g., user feedback) of the product team requires debt to be addressed later in the life cycle.

Lack-of-experience debt: Unprofessional and accidental

Similar to mistake debt, lack-of-experience debt arises because members of the team sometimes make decisions that require rework after the code is reviewed. At times, the team lacks experience, which impacts their ability to code effectively. This is normal in software delivery and can be a vehicle for less experienced team members to improve and learn. Such debt is often accrued as members onboard into a new domain and need to learn the intricacies of new technology stacks and industry verticals.

Bad debt: Unprofessional and intentional

Bad debt is simply writing bad code and cutting corners to meet sprint objectives without considering the impact on the health of the product. While all other categories are normal and expected as software matures, monitor bad debt proactively. This category decreases team productivity to zero.