We apply a tailor-made adaptation of XP practices

Scrum framework doesn’t mention about how the software is developed i.e. which development techniques have been used. It lets the team to decide which techniques and practices will be used.  I think it’s a good idea to share the practices we benefit as a Scrum team thanks to the leadership of the Scrum Master. (A tailor-made adaptation of XP practices)

Pair Programming: All production code is written by two people at one screen/keyboard/mouse. This helps us to ship software with superior quality, less bugs, less iteration and as a result greater efficiency.
Test Driven Development: TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests. Chances are the test coverage percentage of our software stack decreases due to other priorities. In any case, we focus to keep it above a certain threshold.
Unit testing: It's a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. Unit testing is key for the team to level less buggy software.
Continuous Integration: New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or changes are discarded. This eliminates manual work and saves time and efforts.
Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running. In the lack of refactoring, the quality of software decreases and the probability of major bugs increases.


How did we benefit from Contract-First REST API Design Approach?

To recall, the fundamental purpose of this blog is to share openly the best practices we had as the Scrum team from a Product Owner Perspective. That’s why it makes sense to share a typical approach we follow while developing new features by cooperating with client development teams with a strict deadline or  time pressure. It’s Contract-First REST API Design. A recent example of this was a back-end development of a new Payment channel to sell recurring TV packages to end users through the TV Web portal.

To launch this commercially, the in-house Web portal development team was relying on us to progress further and actively developing the brand-new web pages. Besides, the launch date was fixed and committed to the top-management.

Even though the deadline was approaching, since the earlier Sprint has failed, as the PO, I had to prioritize the relatively small work that was left over at the Sprint Planning event. My perspective was as the whole team had focused to ship the Sprint goal of the previous Sprint and we are pretty close to bring it to Done state, I set a Sprint Goal that dictates to continue to work on the earlier goal and only to take small baby steps regarding the payment solution. My rationale was freezing the work we already had started and progressed a lot and focusing on something totally new wouldn’t be an effective way of utilizing team’s efforts.

Okumaya devam et “How did we benefit from Contract-First REST API Design Approach?”