/filters:no_upscale()/sponsorship/topic/c3ea523a-b725-40e0-9341-fcdbf57bf0f1/McKLogoRSB-1720613430518.png)
With widespread adoption of agile methodologies, particularly Scrum in software development, there no longer needs to be a discussion on whether or not it works. The conversation now is around how to get the most out of agile practices - what tweaks and adjustments can be made that empower and enable self-organising teams. We have taken on the core values of agile, as we accept it is not about the processes and tools, but about the individuals and interactions. That being said, I’m going to propose a change to one of those core values of agile practice. I am going to argue that the definition of ‘Working Software’ assumed by most practitioners is too narrow.
The agile value of rating working software over comprehensive documentation is not surprising, given that the writers of the Agile Manifesto were mostly coders. Like Maslow’s man with a hammer, a coder sees all problems as something needing to be coded. This value also comes from the philosophical position that actions are valued over words: make it work and we will believe it. This approach appeals to the craftsperson within us, but like fine crafts in other fields, it might not be the most efficient way to achieve an outcome. Sometimes flat-packed has the same utility as hand-crafted.
In modern manufacturing, products are typically modeled using software before anyone gets out a hammer and a chisel.The same approach can be used for application design. You can build a model of the thing you want, that then can provide insights into how the ‘real’ thing will work. Modeling does not replace prototyping or other methods of refining specific parts of an application. Those techniques are valid for specific details or maybe for the ‘hero pathway’ through a future application. Modeling provides a way to see the size of the application and allows it to be considered holistically. It creates a shared understanding of scope and features for the development team and stakeholders. It can do all of this with a very lightweight process, not the dark, heavy, arcane thing suggested by ‘comprehensive documentation’. I founded Primary.app to provide a way to do this job, but the solution is more about the approach than the tool.
McKinsey & Company shares insights on effectively and responsibly using AI for business value, covering topics from MLOps and organizational change to ethics and emerging use cases. Learn More.
An application model has to be easily understood by the team and stakeholders. This is its most important attribute. If the model cannot create a shared understanding with people who are not invested full-time in its development, then its key role fails. User stories have been the go-to technique for modeling in agile development, but I argue that they are overly simplistic and only touch the surface of what can be achieved. For me the winning approach is user flows. User flows are like the easy-going cousin of use cases. They are based around telling a story in a series of steps. They identify the user, who is the protagonist, they show the interfaces the user sees, and they identify the logic and conditions that apply along the way. They are more work to create than a user story, but deliver far greater value.
User flows leverage the ‘narrative paradigm,’ each flow forms a story. Once the story is understood, it provides a structure on which to hang the details that are necessary to make the product work. For example, let’s take Hansel and Gretel. The basic flow is that the protagonists go into the forest with their parents, they leave a trail of markers, their parents abandon them, they get lost, and they are taken in by an old woman. Now we have the narrative arc, we can attach some detail to it. The parents leave the children because they are poor and can’t feed them. The markers are bread so the birds eat them. The house is made of gingerbread. The old woman is a witch. There is also an alternative flow, in which the markers are pebbles, and so the children make it home. Imagine we wanted to talk about this proposed flow of events, it is easy to see how the story scaffold makes a rigid underpinning for the discussion of the detail.
Just as a cross functional team participates in the ‘straight-to-code’ version of agile software development, they can also participate in modeling. The activity is very similar with both approaches, but as the model is quick to create, easy to assimilate, and just as quick to modify, the involvement can be more intensive. This results in a synchronous activity between product owners, the UX team and developers, as questions can be raised and solutions created in real time. Without a model, these questions will be raised during development in an asynchronous manner. Decisions will need to be made to keep the work moving. These decisions will either need to be revisited or might result in parts of the backlog not making it into the current sprint.
The key to success in this activity is to make sure that all the necessary team members are involved in ‘walking through’ the model and discussing it as though it’s working software. I’ve found a number of things to be constants in this part of the process:
As a product manager, you have a minimum desirable feature set and a roadmap of future features. A common trap is to envision (and probably use Invision) a set of ‘happy pathways’ through their application. In the form of a well developed clickable prototype, these paths will be engaging and probably get buy-in from the team with relative ease, but beware, there is a trap.
Prioritizing the stuff you like and are excited about will lead to an inefficient build process. There is always some boring support processes that need to go along to support the happy paths. Building a user flow based model will reveal these dependencies and start to fill in the details in between your yellow-brick-roads. This process of discovery can radically alter the order in which things are tackled. Instead of driving too far ahead of your technical supply lines, work can be scheduled to make sure your rail-heads are right up behind in front of your front line.
A second benefit from this broader view of the future application is the creation of an appreciation for the complexity and volumetrics of information you will be dealing with. Many agile builds hit a point where sprints are eaten in major refactors or replatforms. The need to make major changes to an apps underpinnings as it grows will never be completely removed, but it can certainly be reduced. An agile model can very lightly sketch out the further reaches of the road map and color in the overlooked parts needed for the near-term must-have features. Scope in this sense is not the dirty word that caused it to be thrown out and be replaced with time.
A key driver behind the killing off of documentation was that it strangled creativity during development. If the tech team saw an opportunity to do something faster or better during implementation, this was met with much eye-rolling by project managers who could only see more revisions of the document no one ever read anyway. Pretty soon the document was being cherry picked for the bits that still made sense and large tracts of it bore no resemblance to what was in production. The thankless task of updating a comprehensive design document was passed down the chain until it didn’t happen.
An agile model can change this reality. Firstly, it is lightweight, there are no turgid passages of written descriptions and no arcane diagrams that were only ever comprehensible to their authors. Secondly, it is developed as you go. There is not a pile of work made redundant by changes. The sketchier, further-out parts of the model are easy to change. While you are at it, updating the old parts that didn’t quite happen as you thought, can be brought into line with reality. I know this sounds too good, but it is reality. At Primary.app we model the app itself using Primary. The model is large and constantly under development. Decisions are frequently made in response to drivers like what libraries are available, or how a feature interacts with existing work when seen in the flesh. Updating these becomes therapeutic thinking time, a little like doing the dishes or cleaning your desk before getting stuck into the next big thing.
A lightweight model of your application can be built in a just-in-time fashion. A model based on user flows can be used to involve all the disciplines in your product team in meaningful discussion and ideation. The resulting model can be built out iteratively to support development and synchronization with what has been built. The creation of a common language that the entire team can use will foster an inclusive team culture and pay rewards in development efficiency.
James Billson is the founder of Primary. Originally trained in construction management, James made the leap into technology during the early days of the world wide web. His initial foray into online development was the creation of a service that allowed ordering of pizzas over a web connection in his home town of Melbourne, Australia. The timing was a bit too early for this business to take off, so early no one had internet connections so orders were delivered to the restaurants via fax. The pizza business turned into a software development shop that rode the ups and downs of the tech-boom 1.0 and the tech-wreck of the early 2000’s, delivering solutions to government, the auto industry and banks. James eventually exited in a trade sale to the international advertising giant BBDO. His current venture Primary is based on the lessons learned from delivering development services to hundreds of businesses.
