Companies have many options when it come to selecting software to support operations. Software vendors market neatly packaged solutions in 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 is sold with.
Companies who require deeper customizations than the paint color, upgraded engine, and third row of seats need to manage a long list of requirements and specifications to hope to eventually get behind the wheel of their own custom software. This is the reason many businesses now have their own agile software teams.
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 software engineer’s outputs with the outputs of their peers— HR produces workers, Sales produces orders, Facilities produces workplaces, and Operations produces widgets. These things are “real”, relatable, and tangible to workers outside their respective domains. Outside of the IT department, the terminal emulators and IDE windows that grace developers’ screens are foreign and intimidating. Development teams, for their part, 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 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, but 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.
Agile approaches
The products 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), which is 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 to 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, but Agile teams refuse to be paralyzed while some requirements are still unknown. Further, while a Waterfall team may have a monumental Requirements Phase, followed by a monumental Implementation phase, Agile teams can comfortably operate with both requirements gathering and implementation happening simultaneously.
