Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« Operational integration in country organisations | Main | Flexible Data Governance - Oxymoron or Practical need? »

Development and support with Scrum; an integrated approach

The Scrum development methodology since a few years has been well integrated into the IT department of many organizations. It is considered to work well for numerous reasons

- Communication is vital to success in any project. Scrum promotes communication between project team members

- Scrum shows quick results. One or two iterations (sprints) are sufficient to show a working product to the client

- No time is wasted as all items are prioritised based on the business value

- The production team is a self-organised unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow.

- Scrum promotes transparency: the client knows what is going to be delivered in the sprint, since he/she has prioritised the Product Backlog.

All success of the scrum team is focused on delivering a working product on time and meeting the quality standards defined. With the sharp timelines set in the sprintplanning, the support team often experiences a lack of knowledge handover by the development team. The support team is often left clueless of what code has been brought live at the end of the sprint cycle. Once the new code is in production it is difficult for the support team to perform issue analysis, as the team never received a proper knowledge handover.

In this article I would like to cover my experiences in Scrum development and the actions that were taken to mitigate the risks of poor handover of scrum products to the support team. A brief reminder of what Scrum methodology is; scrum is one of the Agile development methodologies that uses time boxed effort, known as Sprint cycles, to develop a working increment of a software. Sprint cycles (usually) last 3 weeks, in which requirement analysis, development, testing and documenting are all being performed. Which requirement are to be build in a Sprint are determined from a Product backlog (pool of user requirements) determined by the user community and moved into the Sprint backlog for planning. Each item on the Sprint backlog is called an Epic and can be narrowed down into separate pieces of coding called Stories. In order to determine the effort for bringing each Story live, Pokering takes place, determining how many Stories can be handled within a Sprint with the available resources. Every day team members gather in a Standup to discuss the work done yesterday, the planning for that day and possible impediments, in order to track the progress of each Story. After 3 weeks a review takes place of the work that was completed and not completed and a go/no go decision to Production is made. Finally in the Sprint retrospective all team members gather to discuss the past Sprint in a Retrospective, determining what went well and what the improvements are for the next Sprint.

The process is simple and logical; a scrum team has set its goal at the start of the sprint cycle, performs the tasks in de sprint, revises if needed and at the end of the cycle assesses the success of the sprint by its products. Unfortunately, nowhere in the process, handing over its knowledge to the maintenance team has been mentioned. It would look like the development team considers the delivery of the coding to production as the final stage of product, whereas it is actually the start of the functionality being used and support by the maintenance team begins. Considerable literature has been written on best practices for knowledge management in a Waterfall model. Knowledge transfer is often taken as a phase in the project delivery. Often at the end of the project execution project members would spend time discussing the newly implemented processes and functionalities to the maintenance team, or even involve them at an earlier stage (eg during requirement analysis or testing). Involvement and participation from the support team seems much easier to fit in a timeframe of a year or longer in case of waterfall, then in a sprint cycle that only lasts a few weeks.

Then how can we better prepare the maintenance team for the upcoming product releases, without interfering the development team in their tight delivery schedule? Introducing the Development-Support integrated Scrum model:

Development-Support integrated Scrum model.PNG

View image

The Development Support integrated Scum model adds a series of easy executable handover milestones in the existing Scrum model that tests the quality of product and delivered documentation as well as the readiness of the maintenance team to start supporting the functionality. The idea is to transition the product of a stage to the support team as soon as the development team finishes a certain stage in their sprint cycle.

The first stage for the development team in the sprint cycle is to determine the Sprint backlog; which epics and stories are committed to be delivered in the coming sprint. The list of epics are immediately communicated to the support team, so that they can prepare for what is coming. A Subject matter champion (SMC) in the support team will be assigned who will align with the developer for the remainder of the sprint execution. Requirement and solution documents that are available for the development team are also made available to the support team.

In the second stage handover the developer has finalized the solution of the epic. It can be on a minimum functional level or could be on a detailed technical level. In a short 15 to 30 min session, the solution is explained to the SMC, who at this point will have an understanding of why and how the solution will be build.

In a third stage handover the functionality is delivered by developer. It is ready for the SMC to perform some simple unit tests or integration tests on its own. This ensures that the SMC understands the functionality on a practical level and could even help the developer in finding bugs in the coding.

In a fourth stage handover the developer should have finished the necessary documentation of the functionality. What was not worked out in detail in the second stage handover should now be extensively described in functional and technical documentation or work instructions. It's the task of the SMC to check the quality and the completeness of the documentation.

In the fifth and final handover a stage is given to the SMC to show to the development and maintenance team what he/she has learned from all handovers in a Reverse Knowledge Transfer session. In short he/she will explain the rationale of the requirement and the solution. He/she should also be able to show the exact changes in the code in the system. To finalize the last handover a sign off takes place between development and maintenance team on the following objects

- Functional design documents

- Technical design documents

- Process model documents

- Business requirement documents

- Open issues list

- Performance testing documentation (if applicable)

The final handover is the official handover of the product to the maintenance team. The functionality is now ready to be supported in a live environment.

The Development- Support integrated Scrum model is way of working that is easy to implement for the developer, but intensive for the SMC; the developer at the end of every sprint stage (design, build, test, documentation) only needs to spend a short time to hand the product of that stage over the maintenance team. The SMC on the other hand has to spend a substantial amount of time through reading, analyzing and testing the coding. As the SMC will find this necessary to perform quality support of the functionality, this is not seen as an objection.

The Model is a good way to perform checks on every product of the development team. What is the quality of the coding, documentation and testing. And as the check is done immediately after the release of that product, corrections are easier to make. You need not wait until the end of the sprint to perform these checks. There would have been a greater resistance to perform corrections when the Agile team is already well underway in the next sprint.

The Integrated Scrum model is foremost an integration model. The maintenance team will feel more involved in the sprint cycle and be better prepared once the product is brought live. And that should be the ultimate goal of Scrum: to deliver a quality product that works in production. And if it doesn't work, then any issues should be resolved with little effort.


Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter