5 Minute Read
Companies have many options for operations support software. Software vendors market neatly packaged solutions to their audience of (mostly) non-technical decision-makers. They ask their customers to pay the sticker price on the window, enjoy the features listed above that bottom line, and drive off the lot with the solution. Vendors expect that few customers will care to take a look under the hood; they expect many will not even know what they are looking at, and they know their customers will have to live with any limitations the software has. Many businesses now have their own agile software teams as they require deeper customizations than the paint color, upgraded engine, and third row of seats. But they must manage a long list of requirements and specifications to get behind the wheel of their own custom software.
What are Agile Teams?
Agile teams operate in an entirely virtual realm. Their work is laborious and intense, but it is never touched, felt, or smelled. Contrast the software engineer’s outputs with the outputs of their peers — HR produces workers, Sales produces orders, Facilities produce workplaces, and Operations produces widgets. These things are "real," relatable, and tangible to workers outside their respective domains. Outside the IT department, the terminal emulators and IDE windows that grace developers' screens are foreign and intimidating. Development teams, like the Great and Powerful Oz, are usually content if external observers pay no attention to what’s happening behind their closed curtain. In reality, the totems (user stories, Kanban boards), rituals (standup, story pointing), and ceremonies (sprint planning, retrospectives) that epitomize the careers of agile team members are not conceptually all that different from their peers. These teams may appear to be operating in a state of loosely organized chaos. In fact, the Agile Manifesto is a meticulously devised solution to the unprecedented complexity and uncertainty that successful agile teams are repeatedly asked to conquer.
Understanding the Agile Approach
The products that Agile teams deliver are built using methodical deconstruction techniques. The software developed by Agile teams is simply the sum of its parts. Their products are an amalgamation of one or more epics, each epic an amalgamation of features, and each feature an amalgamation of requirements. It is often at this level that these teams, with responsibility for hundreds (if not thousands) of requirements, can begin to finally plan activities at the traditional PMI work package level. PMI’s principals are most relatable to a Waterfall SDLC (the archrival of Agile), an increasingly unpopular methodology, even though a waterfall approach is more relatable for those whose backgrounds are outside the software development domain. Because comparable investments are made in software projects and other capital projects, senior management will ask the same five questions of their software development teams (credit to Cottmeyer):
- When will the project be done?
- How much will it cost?
- Does the organization agree to what “done” looks like?
- What are the risks to delivering on time and on budget?
- How will we mitigate those risks?
Consider a traditional waterfall team’s responses, contrasted with an Agile team’s:
Waterfall
- When will the project be done? Time to deliver an average requirement * total # of requirements (how do you eat an elephant? one bite at a time).
- How much will it cost? Cost per average requirement * # of total requirements.
- Does the organization agree with what "done" looks like? When all requirements have been met.
- What are the risks to delivering on time and on budget? Committing to too many requirements.
- How will we mitigate those risks? Negotiate for fewer requirements.
Agile
- When will the project be done? After X number of sprints, wherein progress is incrementally planned for a targeted grouping of requirements.
- How much will it cost? Calculate the cost for a sprint rather than the entire project. Then estimate the number of sprints and any milestones (like delivering the Minimum Viable Product) that may be reached along the way.
- Does the organization agree to what “done” looks like? MVP has been met. Beyond this, any additional work implemented from a prioritized backlog of requirements.
- What are the risks to delivering on time and on budget? Incomplete, incorrect, or incompletely broken-down requirements, leading to poorly executed sprints.
- How will we mitigate those risks? Regular retrospectives and adjustments. Taking the opportunity for incremental improvement occurring with each successive sprint. Openness to breaking down requirements into smaller pieces.
Apparently, there’s a nexus forming around this whole “all the requirements” concept for the Waterfall team, whereas Agile teams are focusing on many smaller (and more manageable) constructs. Now, I’ll be the first to admit that this comparison gives the impression of a dichotomy where one does not exist. Even Agile projects can have whiffs of Waterfall concepts, and project leaders must be open with their stakeholders about this. Agile teams still answer to stakeholders who need straight answers to these sorts of questions, so Waterfall’s big-picture perspective (how big is this elephant?) is still good to have. Indeed, knowing all the requirements can be tremendously empowering for both teams. However, Agile teams refuse to be paralyzed while some requirements remain unknown. Further, while a Waterfall team may have a monumental Requirements Phase, followed by a monumental Implementation Phase, Agile teams can comfortably operate simultaneously with both requirements gathering and implementation.
Looking at a Sample Requirements Backlog
| Requirement | Features | Epic | Tasks | Story Points | Sprint | Predecessors | Successors |
|---|---|---|---|---|---|---|---|
Blog CRUD | Blog Operations | View published blog entry - UI Design View published blog entry - API Design | 3 | Sprint 1 | |||
Blog CRUD | Blog Operations | Text block entry form - UI Design Text block entry form - API Design | 5 | Sprint 1 | |||
Blog CRUD | Blog Operations | Publish Blog Post - UI Design Publish Blog Post - API Design | 2 | Sprint 1 | |||
GDPR | Compliance | GDPR Warning - UI Design GDPR Warning - API Design | 3 | Sprint 2 | |||
Google Analytics | Analytics | Visitor Tracking - Page Header Modification | 2 | Sprint 2 |
The examples above are based on a hypothetical project, but reflect the actual client projects I work on. These Requirements backlogs are built so that Agile projects can be managed through implementation, and so the products of these projects have documentation available. This provides a reference and allows for sustainably supporting the end product in the future. Given the scale and complexity of these backlogs, does your team have the capability to support them? Often, managing the Requirements backlog falls under the domain of Business Analysts (BAs). They then build and prioritize it based on input from their stakeholders, and the stakeholders use it for purposes such as planning grooming sessions, sprints, and projecting total project costs and timelines. I have used this approach for years, and I wouldn’t want to work on any large-scale Agile project without first applying these foundational concepts. This invaluable approach informs the stakeholders to whom my Agile teams answer, and it helps keep the developers informed, empowered, and productive. From experience, I can't see how both domains (business and technical) can be kept adequately informed about the project without this approach.
How to Integrate Requirements and Knowledge Management
Some final takeaways — the distinction between a Requirement and a Feature is sometimes ambiguous. As a rule of thumb, a Requirement is not a Feature when it has been sufficiently deconstructed so that a team can singularly focus on its implementation. Requirements can have relationships with their brethren through predecessor and successor relationships. Also, consider that the development team's DevOps tool might not be the best platform for managing Requirements. Consider working with an expert to implement a purpose-built knowledge management tool, like Notion, as a workspace for Requirements-gathering teams. Records can be cross-linked between knowledge management and DevOps tools easily. Furthermore, the robust editors and embed capabilities in Notion can lead to better socialization of ideas, synchronous and asynchronous collaboration, and a more refined/polished Requirement after it has been moved to the DevOps tool. My experience shows this approach to be appealing to Agile teams and functions extremely well in practice. Poor quality software cost US businesses $2.8 Trillion in 2018 – how much of that came from your company? How much better off would you be if you had better software? Let's talk about it and find out.
5 Minute Read
6 Minute Read
6 Minute Read
5 Minute Read
