In Part 1 of How to Make Agile Iteration Possible Within Waterfall Budgeting, I covered the business desire to achieve iterative development and quick time-to-market, with the reservations of rigid waterfall budgeting and planning. I also covered pre-project and project start steps, which I believe are critically important to achieving the desired result during implementation. If you haven’t read Part 1, start there. You can do everything right on the delivery side but still be very agile in the wrong direction.
Now on to delivery steps. As a reminder, we are communicating these steps to the product owner, stakeholders, and management in the pre-project stage. Having buy-in and time scheduled early will save a lot of heartache later on.
Delivery
- Development team delivers feature to QA team to test locally or on Develop server.
- Goal: Functional and regression testing of delivery.
- Tip: Doing QA verification immediately after development, instead of waiting, ensures the developer’s mind is fresh in familiarity with the implementation and test cases.
- QA verifies feature as complete and ready for QA server deployment.
- Goal: Identify defects early.
- Tips: This minimizes the time to correct defects, regressions on QA, and thus follow-up QA deployments. You can deploy continually or in a release at the end of a time period.
- Project Manager works with Business Analyst to review features completed and update overall project progress.
- Goal: Compare progress completed vs fixed timeline and budget.
- Tip: Project Manager should regularly review this with the Product Owner and Management.
- 2nd Stage Demo(s) of feature on QA server.
- Goal: Celebrate what the team has accomplished! Demonstrate to stakeholders and Product Owner the value added by the team, update project completion percentage.
- Tips: May find more success with focused attention by scheduling with relevant individual stakeholders rather than comprehensive delivery. Can be incremental changes from the first demo.
- Feature stakeholders perform UAT.
- Goal: Achieve final sign-off for this iteration.
- Tip: There should be no scope changes during this step, as those were covered in the first demo. Assess further changes identified during UAT to see if they can fit in a future time period, or wait until a separately budgeted, phase 2 project.
- Deploy the feature to Prod with a Feature Toggle system. The Product Owner can then release it whenever they want.
- Goal: Lower risk, enable multiple iterations before release.
- Tip: Product Owner should maintain a schedule for feature releases.
- Regularly scheduled delivery team retro.
- Goal: Celebrate successes. Identify steps to improve velocity and quality.
- Tip: Focus on what is within the control of your team and follow up with action items.
Final Recommendations
A few more thoughts for you to consider. These recommendations do not fall in a specific timeframe, but are key to help the project moving forward.
- I recommend to obtain commitment from the Product Owner and Stakeholders to check and provide updates directly in the ticket tracking system.
- Goal: Writing up an ask once is better than someone else’s interpretation of it. It also doesn’t have to be copied over to another location.
- Tip: This step is optional but highly recommended! It’s easy to lose track of a task as simple as copying from an email to the associated ticket.
- Make it a priority to minimize meetings and attendees. Many do not think about the hidden costs to meetings.
- Could it be an email or comment on a ticket first?
- How much development and testing halt in the time before a scheduled meeting? What about after? How long does it take to regain focus?
- How many people actually need to attend? If you invite someone, they will often feel obligated to attend.
- Consider what else you spend a lot of time doing outside of feature development. Could it be shorter and still effective?
- I once worked with a client to reduce their production deployment time from 5-12 hours end-to-end to 4 minutes.
Now you might be thinking, “I thought this was about agile Iteration? Why are specific recommendations on ticket tracking and meetings included?”
Becoming Agile
Companies that “do” agile implement highly structured business process that can add robustness and flexibility but also add overhead. Companies that are agile use transformative thinking to optimize their time to delivery. These are suggestions to get you thinking in the right mindset and improve through practice. For more information on how Perficient can help you achieve your agile goals and implement your dream digital experiences, we’d love to hear from you.
Contact Perficient to start your journey.
