Our Journey from Ad-hoc to Continuous Delivery
Our Project started with 3 developers and 1 BA, in the waterfall mode 4 years ago. We were facing a demanding sponsor, and quickly decided to explore Agile. We moved to Scrum mode, and worked under the scrum mode for close to 1 year.
Again, we faced a lot of challenges like:
1. Changing Requirements within a sprint
2. Changing Priorities within a sprint
3. Too much time spent in estimating and re-estimating items that were changed and de-prioritized in every sprint due to newer items that had to be added to the sprint
4. Management expectations of detailed reporting on planning
5. Working with support teams that were not Agile
6. Rapidly evolving business, the need to respond to change, regulatory requirements
7. Changing team structure due to maternity leaves
Due to all these challenges, we moved to Kanban mode. There was tremendous buy-in required from the user, the challenges we faced were about forecasting and predicting the time lines of the features prioritized by the user.
Due to the changing business and user expectation, we were given the target to deliver every week in production, when we were only delivering once every 6 weeks. We were working together with non-agile teams, who had an overhead of 1 weeks for every release.
We brought together the support and the project teams, and started involving them right from the requirement gathering phase. They started attending our daily scrum as well. This allowed them to relax their requirement of demanding binaries 1 week in advance.
Another challenge was the time we were spending on regression testing. It was 5 days. We identified a critical test suite that could be executed on a single day. Then we convinced the user to accept the possibility of a defect in the non-critical portion of the application, which would be quickly fixed in the next release. This helped us bring down the overhead for a release to 1 day. In due course, we automated this entire test suite to remove this overhead completely, as the critical test suite would be tested every evening at the end of the day.
We then focussed our attention to the requirement gathering and specification process. To ensure that our specifications were always updated, and reflected accurately the development, we moved to Behavior Driven Development. This reduced the time spent in knowledge transfer sessions to the development teams, and enabled everyone to have a better understanding of the requirement at the same time. Every member became independent, and allowed us to move to the current state of Decentralized decision making.
Each member now acts as his own lead. The requirement is received directly from the user in the form of a jira task. The team decides who picks up the task, and communicates this to the entire team. The task goes through the normal flow, coming to the Business Analyst only if the developer requires more information. Each item is developed using BDD approach, and all the scenarios are executed for success every day. The rework has reduced to virtually 0 in the team, and the user satisfaction is at a constant 10, as the time to market for tactical releases is down to 2 days.
Outline/structure of the Session
* How we started in Waterfall
* Challenges faced
* Our move to Agile Scrum
* Challenges faced in Scrum
* Our move to Kanban
* Challenges faced in Kanban and our response
* Objective of weekly deliveries and how we achieved it
* Our move to BDD and Decentralized Decision Making
After this talk, the attendees would be able to identify with a number of common problems that are faced by new agile teams, and how the problems can be overcome by means of trust and open communication between all stakeholders
Project Managers, Business Analysts