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.
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.
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.
Approach | Waterfall | Agile |
Return on Investment (ROI) |
ROI at the end of the project. |
ROI earlier in the project. |
Requirements |
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. |
Customer Involvement |
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. |
Schedule |
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. |
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.
Mobile application development is a good candidate for Agile methodology for a few reasons:
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.
The choices are clear: