Get certified - Transform your world of work today

Close

Adopting Agile Principles

Applying Agile principles to a software implementation project

10 November 2017

Shreehari Narayana
EdgeVerve


Though Agile was first implemented in the manufacturing industry, today’s Agile method has spread its wings over all industries, including IT. We adopted the Agile method for one of our core banking software implementation projects, and we focused on Agile principles. This initiative proved to be effective and started delivering good results from the beginning. The Agile method not only made the developers’ and functional anchors’ work easier but also increased client satisfaction.
 

Applying Agile principles to our banking software project

Here is how we adopted Scrum against the backdrop of each Agile principle.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  • The client was continually engaged in the development life cycle. After sprint planning, developers first discussed the design with the client and then started development. After developing each component, developers showed the demo to the product owner (PO) so that that client was in agreement with what developers had coded before releasing it for testing.
  • The team delivered the shippable product in each iteration. Our commitment to the PO was always intact and all user stories were completed on time.
  • We had 15-day sprints, so all the deliverables were done daily.
  • During sprint refinement, we ensured that the business value was attached to every user story. All user stories that did not have any business value were rejected.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

  • The product backlog was prepared based on the refined requirements. The PO analyzed the requirements before they were translated into user stories. Therefore, the PO had a clear vision with respect to the product backlog.
  • The team frequently discussed the development design with the PO immediately after sprint planning. The purpose of this activity was to involve the client in development and make the PO aware of the solution and the way we were developing a user story. This way, the PO had no reason to raise any surprise requirements during the sprint review meeting.
  • We accepted some changes in requirements or user stories from the PO during a given sprint unless they impacted the timeline and efforts. During the demo to the PO, our team also accepted and developed some changes in requirements.
  • We maintained the product backlog in JIRA and, apart from this, there were no other product backlogs.
  • The product backlog was reprioritized during refinement, and any user story that was classified as a "must have" and that had business value was prioritized.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

  • The product increment was delivered to production daily. Stories were delivered within the 15-day sprints.
  • Automated scripts were used for testing. The automated testing tool was used for testing all user stories.
  • The PO or customer was able to perform UAT on short notice. After developing the user story, the tester ran a demo for the PO and validated the development. The PO validated the requirement or user story and tested various scenarios that he felt were important.

Business people and developers must work together daily throughout the project.

  • The PO was always available to validate the development of the user story. The meeting with the PO was scheduled on short notice or as and when a developer was ready with the demo. The PO and team had a mutual commitment to the sprint backlog.
  • The PO was always available to resolve our clarifications. If the PO was not available, we raised an impediment in JIRA with the PO as the owner.
  • Functional/technical leads ran knowledge-sharing sessions for all developers. These sessions contained both functional and technical topics.
  • Additional backlog grooming sessions between POs and project leads were planned one week before the start of the next sprint. All the backlogs would be prioritized based on discussions. Next, we held a backlog refinement session with the Scrum Team, who worked on user stories.
  • In backlog refinement sessions, the business prioritized the backlog based on the business value, and this prioritization was discussed with the Scrum Teams.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

  • All user stories were allocated to each developer and tester responsible for the stories.
  • The velocity of the team was understood, and user stories were taken based on the velocity. The team was not overburdened with user stories.
  • Developers and testers were also given proper guidance and knowledge about the user stories, and solutions were clearly explained to them.
  • The Scrum Team members were involved in each discussion with the PO, and their input on solutions was also considered. Team members were motivated because their input was taken into consideration.
  • All the impediments related to applications and clarifications from the PO were provided to the team on time. The timeliness of the clarifications helped the team complete the development and certification of user stories within the timebox.
  • A daily status with praises was sent to the entire team so that the performing team members were motivated and honored in the sprint retrospectives.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  • An awareness was created among all stakeholders about the sprint goal and target user stories for each sprint.
  • All Scrum team members and the PO worked toward closing all the user stories for a sprint.
  • Any pending clarifications from the bank were resolved based on priority, so that development could continue.
  • The bank team was available to help the development team so that user stories were closed on time.
  • We gathered feedback about the delivered product and evaluated the collaboration between the Scrum Team and the client. We invited stakeholders to the review meeting/retrospective meeting so that they could also participate in the discussions and provide their feedback.

Working software is the primary measure of progress.

  • A user story was closed only when all the acceptance criteria were met and the PO was satisfied with the development.
  • Any minor issue in development that was found during certification would result in nonacceptance of the relevant user story.
  • At every stage of development, a demo was shown to the PO to ensure that the development met the bank’s requirements.
  • After reviewing the user story during the sprint review, the PO moved the user story to Done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

  • The functional anchor of the Scrum Team was face-to-face discussion with the development team regarding solutions for user stories.
  • Any clarifications on a user story were discussed with the PO and developers so that the developer had all the information.
  • The development team and functional teams sat in proximity to each other so that any clarifications and discussions happened around desks and not through emails.
  • After discussing with the development team and PO, all clarifications or changes in user stories were updated in JIRA against the respective user story.

Continuous attention to technical excellence and good design enhances agility.

  • After sprint planning, the developer discussed the technical design of the user story with the bank’s technical team to ensure that the bank technical team understood the design.
  • The technical lead reviewed the code and added it as a task in JIRA. Unless this subtask was completed, the user story was not moved to Done.
  • Any defects in code review were fixed in the same sprint, which ensured a quality deliverable for the client.
  • Any technical impediments were resolved based on priority, and importance was given to code quality.
  • A mechanism was built to continually monitor the code during the user story development.

Simplicity — the art of maximizing the amount of work not done — is essential.

  • The PO and the functional anchor viewed user stories that were not completed.
  • User stories were measured based on Definition of Done.
  • The amount of incomplete work was also measured based on the non-completion of the subtasks defined for the user story.
  • If a user story was not completed because of pending clarifications from the client, a technical defect, or change in scope, an impediment was raised so that it could easily be tracked for closure.

The best architectures, requirements, and design emerge from self–organizing teams.

  • Team leads managed the Scrum Team, which consisted of developers, testers, and functional anchors.
  • The solution for any complex user story was arrived at by conducting brainstorming sessions with all the Scrum Team members. Any ideas backed by developers, testers, and functional anchors were analyzed and the best solution was selected. These sessions allowed team members to come up with creative and best possible solutions, providing an opportunity to enhance their skills.
  • The concept of a self-organized team was applied extensively; the team never depended on outsiders for any solutions.

At regular intervals, the team reflects how to become more effective, then tunes and adjusts its behavior accordingly.

  • Apart from the sprint retrospective, we had an internal retrospective with all team members from all the Scrum Teams. In this meeting, all the best practices, positive points, and negative points were listed. From the list, some best practices were selected for adoption and the most affecting negative points were considered for improvement.
  • Team members shared best practices with the entire team so that everyone could follow these practices.
Technical and functional knowledge transfer sessions were also organized for all team members to help people develop and adapt new skills.
 

Conclusion

These best practices generated good results. Ninety percent of user stories were completed in sprints — and in some sprints 100% of user stories — which bolstered the Scrum Team’s and the client’s confidence.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe