How often do you check your voicemail from your home phone and check your email from your home computer? Those eras are long gone for most people. For those who use a cell phone or a laptop computer or tablet, we want the technology to work faster and faster for us. Given that a cell phone is eligible for upgrade in less than 2 years, technology renewal is more rapid than ever before. Mobile applications must catch up and be compatible to the new hardware and their operating systems.
How can we make mobile application development faster? It depends on what project management methodology is used.
Waterfall vs. Agile in Software Development Life Cycle (SDLC)
The most common structured project management methodologies are Waterfall, Agile and Iterative, which is a method between Waterfall and Agile.
Waterfall methodology, as its name sounds, implies its workflow: each stage represents a distinct phase of the project, and you must complete one phase before you can proceed to the next. In a pure Waterfall implementation, returning to a previous phase is prohibited.
Traditionally, the Waterfall methodology has been heavily used in industries with inflexible and costly changes for its infrastructure, such as the construction industry.
Agile iterates the waterfall phases in timeboxes
The Agile methodology, however, advocates adaptive planning, incremental development, early delivery of working products, and continuous improvement. Agile focuses on being just-in-time, and producing minimum viable products (MVPs) over set periods of time, known as a timeboxed approach. It was designed to handle rapid and flexible response to changes.
Unlike Waterfall’s linear method, Agile’s iterative approach focuses on delivering the highest value and return on investment for businesses. There are multiple criteria to compare Waterfall and Agile. In the minimal space of this blog, I want to focus on just a few.
Return on Investment (ROI)
ROI at the end of the project.
ROI earlier in the project.
All requirements are defined upfront and fixed in signed scope document or contract. All requirements are equal.
Define high level user stories/features and use rolling wave planning to define the near-term, must-need requirements in detail. Backlog prioritization is based on value to customer (such as ROI), technical constraints, dependencies and risks.
Deployment & Risk Tolerance
Deployed one time at the end of the project. It may take too long to see results, especially for multi-year projects. Low risk tolerance level for stakeholders.
Delivered multiple times with incremental and iterative approach throughout the project for continuous improvement. Stakeholders will see product sooner than Waterfall and generally have a higher risk tolerance level.
After the initial requirements gathering and sign off, the requirements are thrown over to the development team. Stakeholders will not see the product until the end of the project. User Acceptance Testing (UAT) is performed in the end of the project
Requires stakeholders’ input throughout the project cycle. With a tangible product to present to the stakeholders, the stakeholders can provide in-depth and detailed inputs; therefore, they can help to refine the product. UAT is throughout the project.
Upfront detailed planning all the way to end of project. Work breakdown structure is deliverable-based, including document deliverables.
Have vision in place and plan along the way. Timeboxed release schedule of working product — a short duration timebox creates urgency.
Transparency & Communication
Weekly project status meeting is conducted. We could lose a week easily due to any issue. Microsoft Project Plan, controlled by project manager, is not available for all team members to update.
Daily meetings are conducted. Impediment is targeted to be removed in a day.
An Agile team is a self-managed team. An Agile tool is shared by all team members, who update their own progress.
Although incremental and iterative development were introduced in the software industry in 1957, and Scrum, a popular kind of Agile, was normalized in 1995, some people think that it is a new concept. Actually, we use Agile in our daily life. Let’s use a family driving vacation as an example.
Suppose the trip is from Portland, Maine, to Disney World in Orlando, Fla. Due to the last-minute deal on the internet, the travelers only gather a few “must have” travel items and start driving. They are new to the route and have a rough estimate of the arrival time. They have an idea of where to stop for the night. However, they do not have the exact hotel information. While driving, they determine where to stop for lunch, but they do not have the exact restaurant name and do not know what they will order from the menu. They will research the exact food and lodging information as they go, and share the lessons learned every day.
If time permits, they will identify the food and lodging information ahead of time. They continue this Agile approach every day and research food and lodging information while they are in the car, and get to the destination in a shorter time.
If the family had decided to use Waterfall methodology, they would have spent one day just to plan their trip down to the details, and therefore would have wasted one precious vacation day.
Using Agile for Mobile App Development
Mobile application development is a good candidate for Agile methodology for a few reasons:
Compared to its full-scale web application, a mobile application is implemented with a subset of its relevant full-scale web application. The reduced functionalities make the software features small and easy to rollout. Each set of features can be deployed separately and can be incrementally added to the application. Facebook, as an Agile company, tests its upcoming releases every week. Each feature is developed by a small team. For example, each area — such as Search, Newsfeed, Profile, Video or Adverting team — is structured by a small team. For each release, Facebook’s Agile teams go through the entire SDLC in their predetermined timeboxes. A timebox can be as short as a week.
Mobile applications are Graphical User Interface (GUI) driven. Users can see and react to the system. Because they are user centric, scenario-based user stories are the best requirements format to demonstrate the user experience.
Once users have downloaded a mobile application from their app toreor Google Play, the feedback and ratings are real-time. This will allow the Agile team to prioritize the customers’ feedback and factor the feedback as rapidly changed requirements for the upcoming releases, as a part of the continual improvement.
What does Mobile application development have to do with the toll Industry?
Like other industries that are feeling the need to make use of the convenience of the mobile phone, the toll industry has started to develop mobile applications. In some states, the public can use their mobile app to declare high occupancy vehicle (HOV) status before traveling in an express lane to get discounted or free tolls. Elsewhere, customers can manage their account, such as managing transponders, paying for tolls and viewing their toll history, and even paying for parking ferry, and arena tickets, and more.
Project Sponsor’s Choice for Waterfall or Agile
The choices are clear:
If you want to see the end product for the first time at the end of the project after you send in the requirements, choose the Waterfall methodology. You may be surprised that the product is not what you envisioned. You may have wasted the entire project duration. By then, the mobile phone operating system may have been advanced.
If you are willing to roll out a minimal product in the beginning and invest time to provide feedback and refine the product throughout the project, and have the finished product turn out the way you want it, Agile is the fastest vehicle to get you there.
In honor of Pedestrian Safety Month, we’re showcasing four impactful infrastructure projects that have positively influenced their communities. Dive into the details below and stay tuned for weekly spotlights on our social media channels throughout October!
Projects inherently have risks. Some risks are high-stakes that could lead to major cost overruns or delays, while others are more minor that could lead to minor delays or changes to the scope of work.