Throughout my 17-year career, I have worked on projects using several different development methodologies. Most projects I’ve done have utilized the traditional agile approach. Agile is the most popular and widely used, but depending on the project specs, I’ve found other alternative strategies that are better suited for the work.
Originally published on Keyholesoftware.com by Brian Jacobs on 1/12/23.
A Real-World Example
Most recently, I worked on a project for an international client by the name of Solera. Our primary contact worked from the UK, so we had to deal with a six-hour time difference, meaning that our daily meetings were in the morning for us and the afternoon for them. The time zone difference did present a challenge with daily schedules, but we found ways to communicate clearly and efficiently.
With excellent help and guidance from our UK contact, we got our environments set up in Docker, Postgres, VPN, Git repos, and localhost. Once our dev environments were set up, we were ready to begin the project.
The project was small in scope, and the client wanted the work done as soon as possible due to budgetary concerns. With that in mind, we worked through the project with a different methodology than most traditional tried and true ways (ie Agile). If we had chosen Agile, we would have wasted time and resources.
I hope this example demonstrates that sometimes, Agile isn’t the best choice, even if it is the most highly touted. Sometimes, it’s worth thinking critically about the project and its requirements to select a methodology that works better. In this post, I will explore a few of those Agile alternatives.
An Agile Alternative For This Example
Regarding the example above, instead of a traditional agile approach that involves sprint planning, backlog grooming, sprint retros, etc, we were given a PDF with mockups and info regarding interface behaviors, error handling, data handling, etc.
I reviewed the PDF and came up with questions for things that needed more explanation, edge cases, and exceptions. Then, we went through the document in a web call, addressed the issues, defined technical aspects and interface behaviors, and added notes with the refined requirements.
The updated document became the de facto stories and tasks for front-end and back-end development as well as QA. Thus, we were able to proceed quickly with development and testing.
The advantages of this method are:
- No time was spent writing out stories, adding tasks, and estimating hours
- No formal sprint retros and backlog grooming
- Discussing questions in the daily standup and getting to a resolution more quickly
- By screen sharing completed work frequently, demos clearly showed what development was done and what was outstanding and allowed design adjustments and refinements to be made
For small to midsize projects, this approach seems ideal. Formal meetings weren’t needed, as the goals of retros, grooming, writing stories, tasks, and demos are accomplished during daily standups or other arbitrary web calls. While we did not have formal stories written out, we still clearly knew who was working on what, how much development was done, and what development remained.
When making refinements along the way, we only had to update a single PDF document rather than updating or creating new stories in a tool such as Jira. This allowed the developers to take the project and run with it. Developers are often most productive when able to be heads-down, coding all day instead of spending hours dealing with emails, unnecessary meetings, and other non-dev-related tasks.
Issues were addressed very quickly when they arose, communication was clear and concise, and development and testing went forward smoothly. I have worked on projects in the past in which the dev team was given mockups with click thru paths of the screens. While not all details are fully conveyed and some issues were discovered later on, having a full overview of the project allowed a good architecture and design to be constructed and built upon.
State Driven Development: Another Agile Alternative
Another agile alternative strategy that I find to be easily understood is State Driven Development. This paradigm involves providing and defining all the various states that apply to a screen or component.
States do not apply for static elements since content is readily available upon page load. However, for screens or components with dynamic content, the following states typically apply:
- Loading state
- Happy data
- No data
- Not enough data
- Too much data
- Error states
Let’s talk a little more about each of these in depth.
Loading State
Most screens or components in an API-driven application will have a loading state either when retrieving or sending data. A loading state is often needed to indicate that data is being processed. Usually, a spinning animation or simple text message is displayed while this data processing is underway.
Happy Data
Happy data is the display of data when all the expected fields are present and the result set is manageable. Load times are fast, all the data renders properly and is easily readable, and there is minimal scrolling required to view all the data.
No Data
Usually, a specific message or UI is needed when an API call completes successfully but no results are returned. For example, if data for a table or chart is to be displayed, a message such as, “no results found” is often displayed.
Depending on the design, the X and Y axis of the chart or the column headers of a table may still render with the “no data” message displayed. Alternatively, a simple “no data” message or image may suffice. Either way, the “no data” state should be considered, so developers, QA, and automated tests all account for it.
Not Enough Data
The “not enough data” state has some design and programming considerations to be aware of and should be handled accordingly. “Not enough data” refers to the display of data when not all fields are present.
In most cases, displaying nothing works fine. In some cases displaying “N/A”, “(empty)”, or some other text is needed to make it more apparent that a data field does not exist. Some designs display a label with no value. Others may omit the display of a label if a corresponding value is not present. Visual aids such as grayed-out text or an icon may be displayed in place of incomplete data.
There are some things to consider here. If a data table is normally 500px tall when enough data is present, it may be only 75px tall when very little data exists; this could potentially cause layout issues. A slider or carousel that, ideally, has dozens of frames to scroll through may render oddly if only a few frames exist. Also, left and right scroll buttons or table pagination controls may need different handling or displays if not enough data exists to scroll or page through.
Too Much Data
Having too much data may cause side effects that should be taken into account. A long word or number may cause text to be cut off or hidden if not enough space is given for it to fully render. Several paragraphs of text may cause unexpected layout issues by pushing other elements away from their desired placement. If scrollbars appear, they may also cause layout issues.
Too much data can also lead to performance issues if the data is too much for a browser or API request to handle. Most of the time, too many data scenarios only cause minor layout and display issues that can be handled with CSS fixes. Other times more drastic solutions are needed – such as partial loading of data, pagination, load as you scroll, etc.
Error State
In an API-driven application, error states can occur for a variety of reasons. Scenarios including system errors, API failures, session timeouts, validation errors, and more are all part of most web applications. Error handling is a major effort when doing development, on both the front and back-end. Design is also heavily involved in the display of error messages as there are so many ways to convey error messages to the end user.
The states listed above apply to most web applications I have worked on. Being aware of them and making sure they are accounted for resolves the vast majority of edge cases. It also makes an application more “bulletproof.” Discussing the above states with your development team often leads to improved design and better code bases, and ensures everything is accounted for and handled properly within a system.
Another Nontraditional Agile Alternative
This next agile alternative/programming method is not the most scientific or well-defined, but it is not without practical benefits. This method works best when the design or end goal of a project is not fully known or when the product owner does not fully know what they actually want.
In that scenario, it is often beneficial to have some examples to look at, click around on, experiment with a real interface or two, and then proceed with that extra trial experience.
Rapid Prototyping
Rapid prototyping usually involves two or more developers developing the same thing in different ways. Pitfalls and unknowns are discovered, advantages and disadvantages to each method are found, a consensus can be reached based on comparing notes, and progress is made. This is also a good way to learn a new framework, library, or code package.
Rapid prototyping creates something tangible that can be seen and demonstrated, allowing a client to play around with it and decide what they like or dislike.
Clients are often very pleased to have an application that they can view in a browser or mobile device. Even though the product is not fully developed or tested, having a real example is very beneficial when still defining the full end-to-end product. The rapidly developed prototypes can then be iterated upon, keeping desirable features, discarding unwanted features, and further defining the end goal.
In many instances throughout my career, the client has needed quite a bit of time to come up with requirements, next steps, approval, and/or funding. That downtime can be used by the development team to clean up the prototypes, come up with a solid architecture, refactor and optimize the code, fix bugs, and make other improvements.
The end result is a more stable code base that can be tested and made production ready much easier. While this is a less defined work path, it is still an effective way to build a system and make use of downtime.
Final Thoughts
While there is no right or wrong way to develop a system, some ways are definitely more efficient than others. In my experience, getting a screen or component developed before expected has worked out very well as it gives the client something tangible at an earlier date, allows more time for testing, and gives a product owner plenty of time to decide if the end result is what they actually want. On most small to midsize projects I have worked on, myself and my team have been more productive when given a workload to just run with and get knocked out.
The contents of this article are written from my own experience, spanning my 17-year career. These points will not apply to every project out there, but they can be used as insight into alternative strategies for developing a system.
Each method has different pros and cons, some may be very suitable for a project, while others may not be. Determining which strategy to use becomes more clear with some experience and experimentation.
I would appreciate hearing your feedback if you have any after reading this post. Let me know what you think about these agile alternatives in the comments below, and if you enjoyed reading, go subscribe to the Keyhole Dev Blog for more.
Latest comments (0)