What image appears to you when you think of tolls? Coin collection booths?
Believe it or not, the toll industry has become software-driven using Electronic Toll Collection. Agencies that have sophisticated software can more efficiently collect revenue while offering advanced customer service features. Suppliers with cutting-edge software can increase their market share quickly in such a hot market. With an easy to navigate web-based user interface presenting accurate information, the end customers are happier. The agency’s customer service center’s operating cost will be decreased because it has an effective customer self-help portal.
More and more companies are using the Agile practice in order to bring software to market sooner. A few toll integrators and agencies are adopting Agile. Agile project management values individuals and interactions, working software, customer collaboration and responding to change. It is an iterative or incremental approach to delivering requirements throughout the lifecycle of a project. If more traditional waterfall projects take too long, aren’t linear, or change a lot, Agile might be a better solution.
Toll projects are well suited for Agile methodology. These projects are like building a vehicle with different parts built by different sub-contractors. An overall design and detailed design of each part and integration must be shared across the teams in order for the parts to fit together during assembly.
Once the design is understood by all the teams, Scrum – an Agile methodology – would be used with an iterative or incremental approach through timeboxed process for development, testing and deployment. Furthermore, adding Kanban, a process improvement method that tracks work in progress, would be beneficial to provide even more clarity on each user story/requirement.
There are only three roles in the Scrum framework:
Product owner – The product owner’s primary responsibility is to provide project vision and prioritize product backlog. This role is usually filled by the project sponsor or designee, a dedicated subject matter expert from the agency side.
Team – The ideal Agile team size is five to nine developers and testers. The team is ultimately responsible for delivering the end product.
Scrum master – The scrum master is responsible for making sure that the Scrum methodology is followed. He/She is a servant leader who facilitates meetings and coaches the team. The scrum master’s primary focus is to remove obstacles. Because there is no traditional project manager role in Scrum, the Scrum master is usually a project manager or tech lead.
Figure 1: Agile project management with Scrum
The product owner documents the product vision (what the finished product looks like) and shares the vision with the team.
The product backlog includes features, such as functional requirements, non-functional requirements, enhancements and defects. The items are sorted with the highest priority on top. The backlog is continuously groomed.
This is a mid-range planning with high-level plan for multiple sprints. The release goal for the product or functionality is clearly defined. It also serves as a base to monitor progress within the project. (Who says Agile does not need a plan?)
Agile requires frequent planning. This includes near-term planning down to the shortest timebox – a sprint. Each sprint is a fixed duration from two weeks to one month. (Though we cannot see far into the future, we can see more clearly into a few weeks. Sprint cadence should not vary so that the velocity can be measured easily.)
After back and forth with relative sizing, the three scrum roles will be ready to commit to the most near-term sprint. User stories, which give the development team context, are assigned to the current sprint number and then to the appropriate team members.
A 15-minute progress check (usually stand-up) meeting is held daily by the scrum master to ensure that the work is executed as planned. The goals of the meeting are to ensure baby steps are taken every day and obstacles are removed within 24 hours.
The daily stand-up meeting is not a technical or problem-solving meeting. Rather, only three questions are asked to each team member:
In order to conduct an effective daily scrum meeting, each team member updates the story status in the Agile tool before the meeting so it reflects the current statuses.
A Kanban board helps to visualize progress on each story and identify issues. It also captures the cycle time of each stage of the workflow.
Figure 2: Kanban Board captures work in progress in a sprint
After working hard for the entire sprint, this is the time we can see the fruits of our labor at the end of the sprint by a product demo of the planned features. Based on the demo results, the product owner accepts or rejects the work and discusses with the team what needs to be worked on next. The product owner might invite other stakeholders to see the demo.
After the sprint review and before the next sprint planning meeting, a sprint retrospective is facilitated by the scrum master to identify lessons learned and opportunities for improvement in people, process and product. The team members factor the product owner’s feedback from sprint review and decide what to implement in the next sprint. Visual progress measurements are shared.
Sprint by sprint, release by release, the final product is delivered.
It is recommended to start a trial Agile project using a small project. Once Agile has proven successful, the same approach can be adopted to more and more projects.
In order to implement Agile successfully, the following preparations are needed:
Implementing Agile must be a top-down approach. The organization must embrace five Scrum values: focus, courage, openness, commitment and respect. Organization-wide training by an Agile coach is highly recommended.
In the toll industry, most works rely on the vendors. The contract between agency and vendor must support interaction and an incremental approach, encouraging the vendor to deliver early and allowing the flexibility of requirement or priority changes.
It is important for an agency to host its own Agile tool and invite vendors as guests, instead of using the existing vendor-supplied Agile tool. This is because that a vendor may not want to give access to other vendors.
A good Agile tool should be interactive and able to provide basic progress measurements such as a sprint burndown chart (work completed per day against projected rate in a timebox), backlog burnup chart (total stories completed) and cumulative flow diagram (bottleneck identification).
Configuring the tool itself is relatively easy once you have a defined process and have gained buy-in from the stakeholders.
According to my experience, at the end of an Agile project, you will have a closer relationship with your team and stakeholders, pride in having defect-free software, satisfied customers, and the achievement of beating the deadline.
For a large project, each work stream can be broken into an Agile sub-project. Like Waterfall methodology, you still need to identify dependencies in order to mitigate risks at a program level.
Certainly. Think incremental. You can deploy one gantry at a time.
PMI Agile Practice Guide with PMI PMBOK Guide 6th Edition
PMI-ACP Exam Prep, 2nd edition, Mike Griffins
https://www.pmi.org/learning/library/agile-project-management-scrum-6269
https://www.scrum-institute.org/Release_Planning.php
https://thedigitalprojectmanager.com/best-scrum-tools/