Assuming control of our Department of State (DoS) Office of Foreign Missions (OFM) which is a full IT Services contract with a large system/software effort. Directed to implement Agile Scrum methodologies to an existing team in the middle of ongoing development efforts. The team had little to no knowledge of, and experience with, Agile Scrum. The team was doing 4-week “sprints” with minimal user stories developed and tracked, and with minimal requirements defined.
There were 12 releases a year based on work performed and completed each 4-week effort. While the timing of releases was consistent, the content of and value delivered was inconsistent and unpredictable. And with this approach completed work was held for releasing at monthly intervals instead when ready and causing code merge challenges.
The challenge was to implement the Agile Scrum framework to instill discipline and predictability into the development efforts without totally disrupting the ongoing development of some important functionality that was under specific time deadlines.
An Agile (incremental) approach was taken to implementing the Agile Scrum framework and methodologies on the DoS OFM contract. An Agile Scrum overview was given to the team. Some basics were implemented:
- The Team was/is using Team Foundation Server (TFS) for code version control, builds and deployments. There were some user stories in it. It was made a requirement to have a PBI/Bug in TFS and in the current sprint for all work.
- Story points were implemented with a very clear and simple points system approach.
- A standard set of tasks were identified to be created for all PBIs
- The Sprint timeframe was changed from 4 weeks to 2 weeks.
- Daily Stand-ups were held with TFS up and members talking about the specific user stories in the sprint
- End of Sprint demos were introduced
- End of Sprint Retrospectives were implemented
Using a standard points approach, and discussing initial estimates after completion, the team became comfortable and more accurate with their storing estimating. Now, user story points are predictable and reflect true velocity for each sprint.
The team has become more comfortable and efficient at decomposing requirements into Epics, Features, and User Stories. Creating Sprint backlogs and working only on activities in the backlog has normalized. Therefore, all development is defined, tracked, and reported on.
Leveraging biweekly Retrospectives, the team has continually implemented changes to processes. They have become comfortable with trying ideas, realizing some do not always work, that it’s okay, and they make tweaks and changes in an upcoming Retrospective. Through trial and error, the team has defined Agile Scrum compliant processes that works for it.
Initially the Sprints were strictly development sprints. This has expanded to including integration with incidents/requests in the Remedy/ServiceNow software. Including Research, Analysis, documentation writing, tool eval, etc. into the backlog.
Incrementing 2-week sprints with twice the number of sprint planning sessions has made the team more responsive and adaptive to customer needs and priorities. Implementing daily stand-ups and end of sprint demos has made the team’s work more transparent to the customer.
Ting customer quarterly priorities to sprint planning session, sprint backlogs, and new releases facilitates our direct customer being able to report on team progress more accurately to senior management and being able to report on value delivered.
Incrementing Agile Scrum methodologies in an incremental fashion has allowed the team to add/change its processes. Become familiar and comfortable with them and make changes to them on a continuous basis. So, through trial and error, the team has defined Agile Scrum compliant processes that works for it. Being more efficient in the processes has made the team more efficient in completing and delivering work. Becoming more efficient and accurate in estimating story points has made the sprint velocities more accurate and therefore more reliable for planning.
Continuing to expand on what work is included in Sprint backlogs provides more insight into work being performed and delivered to the customer. And it has improved the work defined and tracked in sprints.
Along with the adaption of 2-week sprints, a CI/CD approach was adopted – work is deployed when ready instead of being saved. Doing this, the team appears to be more responsive to the user community and reflects very positively on our customer.