Summary: Software used to require significant upfront planning before code could be written. Delays, bugs, unknown unknowns ran abound in those long cycles. Mindshift changes and technology have enabled Just in Time (JIT) definition and development of software to shorten feedback loops. These more modern practices are encompassed in terminology and practices such as Agile, Scrum, Kanban, etc.
Most people in the software industry understand the role of project management tools, due to the fact that more teams have transitioned to working remotely. In a nutshell, having a source of truth documenting planned, in progress and completed work helps teams collaborate across time zones without having to be on a conference call together. Everyone wants communication and alignment.
Zooming in on building software products - how does the content get written for those tasks?
Short answer:
Subsets of a larger team will discuss and design smaller deliverables for their team members to implement over the course of a short delivery cycle. In most organizations - over the course of two weeks. Those deliverables will progress from 1. TODO 2. In Progress 3. Done. Some teams will elect to have intermediate steps to signify more granular progression within their deployment ecosystem.
History and longer answer:
First. a bit of little distant history. Before cloud-based project management tools like Clubhouse, Jira, Pivotal Tracker, Asana and the like where available, software still had to be designed and created. Historically, a team of architects, developers, business analysts or other experts would write up a huge, exhaustive document of requirements that the end product should include. A little market research here, competitive analysis there, platform API referencing and whiteboarding would feed into the end result specification of what needed to be built. This manifested itself in many ways, ranging from a massive word style doc with API & data structure design, as well as business logic all baked in. The design document was intended to be exhaustive, covering edge cases as well as error states and if the developers wrote “to the spec” then delivered on time, (more on that below) all was golden.
Afterwards, a project plan would be extracted from the spec that would attempt to gantt chart an estimated delivery date for the project, from start to finish. A budget would be built to map out required resources (people) needed at each stage. Think - software developers needed at most stages, quality assurance practitioners to sign off on completion, fit to the specifications, and project managers to keep track of the schedule.
Bugs discovered by customers were pretty costly, because if a bug made it “into print” on the CD’s or floppy disks delivered to stores around the world, it would be costly to fix. For reference, in 2002, the National Institute of Standards and Technology released “The Economic Impacts of Inadequate Infrastructure for Software Testing”, a 309-page report on cost frameworks, economic models and testing approaches. Users could neither download weekly nor daily updates over the internet. You and your team had to get things right the first time.
Even back in 2001, rumblings of frustration in the industry had emerged, that huge upfront design followed by a “waterfall” of development & testing was pretty risky and took excess time without feedback. Many cite the “Agile Manifesto” as a key rallying cry for a changed way of thinking about software development. High level - move towards smaller iterative development, adaptive planning and early delivery.
Fast forward to now. June 2020.
Majority of software that we interact with today is delivered to internet connected devices that can receive updates from the corporations or communities that build them. The industry has built and designed systems that even enable a bug discovered by a customer to be technically remedied and deployed to billions of users in a matter of minutes. Teams can build smaller, incremental features and changes and deliver them quickly for feedback from end users. The industry has (for the most part) shifted from months, if not years of heads down work before a customer can see progress to minutes, but in most cases days.
Instead of an adequate upfront planning in advance of the work that is nearly set in stone, majority of the industry has shifted to Just in Time (JIT) planning and development - many espouse more specific practices of Agile, Scrum or Kanban these days. Broadly speaking, JIT and other manufacturing concepts such as Lean and Muda have found their analogs in many software development practices.
Quick note: While JIT has heralded cost, efficiency and quality gains in manufacturing and supply chain management, it can be fragile to upstream supply chain issues. If a supplier manufactured sub-component, and is delayed, the whole assembly will be as well. Wiki - https://en.wikipedia.org/wiki/Just-in-time_manufacturing .
Back to software development. If we think in simplistic manufacturing terms of how software is made now, we can think of it as an assembly line.
- Step 1: Design and/or Specification
- Step 2: Sourcing of sub-assemblies (think open source)
- Step 3: Assembly
- Step 4: Inspection
- Step 5: Packaging
- Step 6: Delivery
- Step 7: Feedback which rolls into another cycle at Part 1.
We will just dive into Part 1 as that’s what you’ve been waiting for. Since we have covered how the industry is moving away from upfront planning and towards more JIT cycles, how does that look in practice?
Often, a product manager will sit down and review notes from brainstorming sessions with the internal team (User Journey Mapping - wiki, analysis of Jobs To be Done wiki ) or simple user feedback. Most times, these items will be weighted by value to the end user vs effort to deliver. If a team can identify high value and low effort functionality they can deliver, that’s generally what they focus on. Rinse, repeat. However, there are often high value features or functionality that are difficult to deliver, but can provide a competitive advantage against competitors that might not be able to do so.
Whatever comes after a high-level targeting of what to work on next is where many teams end up struggling. Definition. Many teams attempt to do this gradually, so as not to be in a rush to define and build at the same period of time. There’s a balance regarding being able to understand a problem in depth, so as not to be learning on the job, and researching endlessly on a task that will not be picked up in the next two-week team cycle, or ever.
Ideally, a team will have enough time to think about the complexities of their broader product and how something might integrate so that they can reduce long term technical issues or debt and provide a simple solution that will be easy to maintain in the long run.
For instance, if a team sits down to define 6 proposed tasks, features or additions that are on the short list for an upcoming work cycle. Whatever happens to each or these 6 items is a definition of who it is for, often referred to as a persona. What they need to do, and why. Digging deeper into definition, teams will discuss and document what should be done, what is out of scope and how certain actions within the system should behave for the end user. Looking back to elementary school, you will hope a team aligns on the who, what, when, where, why and how.
Instead of doing upfront requirement definitions that are set in stone, organizations are deciding and defining their work product just in time.
Once an item is defined (level varies between team, organization and even over time), code can be written, tested and delivered.