My tryst with Agile

I recently did a 2 year long Agile project. Before I talk about the project, first what I had heard about Agile

• Frequent delivery allows the Product owner (PO) to see results continuously and make adjustments where necessary.

• There are ways to understand and learn impediments that affect the velocity of delivery.

• There are no defined roles and the team takes complete ownership since they give the estimates.

My project was a very large fresh ground up development project using microservices on cloud with all the latest tools present that allow for smooth delivery of projects. The End timeline was fixed. Expected Sprint Velocity was fixed.

The team was brand new comprising of resources with mixed experiences.

The POs and the Assistant PO were quite well briefed in their role and responsibilities.

All ceremonies were followed.

Yet the difficulties and finding are NOT complimentary to Agile. I think Agile makes certain assumptions and requires certain environment for it to succeed.

Sprint Demo: The functionalities were usually so complex that the sprint demos was not sufficient to display the whole functionality. The team could demo only a snapshot of the functionality. This meant that PO could only get a hint as to what parts of the system were getting ready.

Testing & Development at the same time: It is a large enterprise project and so must undergo SIT before UAT could be viewable by POs can be done. SIT was to be done by combination of members from the Quality assurance and the squad's BA team. The Quality assurance team lacked enough time to gather business knowledge and the BA team enough time give this knowledge. No tinkering of the schedule or joint sessions etc. could not break the issue of insufficient knowledge. At the same time the defects that arose from SIT could not be handled by the Dev team at the speed at which they were required to. This meant that the SIT sprint schedule was disrupted. This in turn affected the UAT schedule.

Actual Sprint: The sprint period was decided at 1 month. But realistically this would be about 2 to 2.5 weeks as there would be time required to understand the new functionalities to be developed and then about a week to do Sprint Demos and the Sprint retrospectives. The sprint schedule was found to be too aggressive for the team to course correct. Unless the impediments were known earlier or were quite small it was almost impossible to recover and generally affected sprint outcome. This further exacerbated issues in product backlog management.

Impediments related to project architecture, continuous integration and deployment, common framework code or failure to use it correctly was almost impossible to recover from. This is because it was usually too late to replace the stories with another one to meet the story point target. As a result a lot of code hacking, burning the nights & technical debts (technical changes that will be corrected subsequently) occurred. So, one of the main benefits related to Agile i.e. the ability to discover and course correct failed for the squad. BUT, at the program level it seemed to be useful as the project metrics and experiences of the various squads came to be known earlier. This led the senior management to make corrections.

Squads: Agile Squads were supposed to be balanced where the team themselves take ownership. Even after frequent training, briefing on roles and responsibilities it was found that the "developers" in the team were too conditioned to task taking. Across a number of squads it was found that the technical lead or the scrum master had to allocate the tasks. Even after about 17 sprints, it was found that the squad members were reluctant to update their tasks in order to show progress, reluctant to take ownership of the tasks.

Agile assumes that the team collaborates constantly to help each other and course correct where necessary. The team was willing to share what they were doing but collaboration required constant prodding. In addition, the expected sprint velocity, requirements to give sprint demos at a frenetic pace meant that the more junior resources found themselves at the deep end with no one to support.

The delivery process simply could not account for training onramp. I am not sure if this is an issue with this project only but my sense is that this will be across the enterprise projects that are delivering large products. The demands of the projects may not allow for the team to be trained, be given sustained buddy to improve. Another crucial assumption that Agile makes is that each member is able to deliver but in a team that is almost never the case. There are members who can deliver and then there are those that need constant guidance in order to deliver. Crucially, all the stories of Agile assume a self driven and competent Agile team.

Side Effects: As Sprints 14 & 15 closed mental fatigue became a constant with a number of squad members. The constant changes due to a less than mature architecture, less than mature DB design and other business and technical configurations that needed to be done along with the delivery project schedule piled on additional pressure on the squads. Burnouts were common, frustrations was apparent. The frenetic pace of testing also meant that the scrum master, business analyst and technical leads did not have adequate feel for the readiness of the system.

Agile can be very onerous delivery process for a large enterprise project that has a fixed deadline.

So is it all gloom and doom?

I would make the following changes to the project.

1. Force the client to delay the timelines.

2. The buffers that were built into the sprint schedule for recoveries to have been kept.

3. Ensure each squad is resources with the right resource at all times.

4. Agile is great but it needs supporting environment.