ABC of Scrum – Agile Methodology
What is a scrum? Why do we need scrum practice? How productivity increases if we follow this approach? What is lagging in other approaches? These are common question when someone tells that this is a best approach. I don’t know whether it is a best approach or not. But I can tell you, what all benefits you are going to get with this approach.
Before going to advantage of scrum, let’s know what a scrum is. The scrum contains a set of sprints and each sprint will produce shippable code to production. Sprint team contains a group of developers and testers. Both developers and testers work together to complete a set of items (these items are called as user stories). Each story contains a set of tasks depends on the purpose and usability. Each member of the team has to work on individual task.
Before going to inner details of this process, you have to know what is meant by product back log and who is going to maintain and how stories added to the back log. A product back is a place where all requirements placed. These requirements are collected from product owner, customers and clients. Anyone can add to a story to the production back log. Product owner is going to take responsibility of entire back log items in setting priority and make team to understand requirements. In the scrum practice product owner can give the priority but don’t have right to give story points.
A story point is the rough estimate on a story which will be given by scrum team. As a team, team has to decide the point for the story. In order to give points, there will be poker cards, which need to be displayed by each member of the team. And team has to come up with a common value depends on the discussion among the members. The value will be treated as story point. The story point defines the value of the story in terms of development.
Above all the things are related to internal process of the scrum.
When are we looking for new process? New process will be come into picture only when we are not happy with existing process or something lagging in the existing process.
In our existing software engineering process, most of the cases we assume that all requirements come at the same time or at the beginning of the project or product. But bitter fact is that requirements are keeping on changing and it is not possible for anyone to give all requirements at the initial stage and it’s very difficult for the clients to tell each and every thing. When clients having feasibility to change requirements after project started then they can get better product what they expected.
In regular software engineering paradigms we are having complete design at the beginning after requirements phase. Design is a big task and it required expertise and good understanding on complete project. We might read design heuristics, which itself says that design should allow to change any time, because for every design has some flaws and it needs to be overcome all the time. What will happen after coding started if design requirement need to changed? It will kill lot of effort and time. It will lead to delay in product release days. Most of the cases we never look back to design phase to identify flaws in the design once we move to development (Coding) phase. What will happen if someone finds problem in design at the time of development, are we ready to change? Doing complete design is always a risky task, because we are humans and we use to ignore few things unintentionally. So if we have a system such that we can do design at any stage, and change in design at any stage, it gives lot of freedom to both designers and developers.
In our traditional software engineering models, testing will come into picture only when development completes. So tester will involve in the actual work only after development has completed. While testing if any issues were found then again we have to do development and identifying the problem area is very complicated for any developers. And as a tester it’s very difficult to test entire application every time development fixes the issues. As tester not aware of where the problem is, they never relay on developers words. So what if developers and testers work together from the beginning on the project, just like testers working along with developers and asking them to fix the issues as and when changes moved? It saves lot of time for developers and testers, right?
In regular software paradigms the end user or client or product owner can see results only when entire project completed. Do you think we always we develop an application, what a client really want? I can simply say no. Why because we never known what other person perception, we might do something other than client expectation. That’s reason why some times we have to hear, “This is not I am expecting” from the clients. How can we overcome from this problem? What if client able to see the progress and application as and there is some progress in it with some results? Do you think it sounds great? But I feel it’s great. I always love to see product owner or client involvement in the project periodically (Demonstrate the developed application with what we had done)
How to overcome these problems with Scrum?
Requirements: In the scrum practice we never do complete product. In the scrum practice we do work sprint by sprint. When there is a change in requirement product owner can update new requirements in the product back log. If change in requirement is affecting current or previous sprints then we cancel existing sprint and will start new sprint. In this process we will restart the entire sprint which got affected. You might have a question like, if we allow client to make changes in requirement how can we complete the task? In this scrum practice most of the cases product owner is client, so when he is changing requirement then he can see process behind the schedule. Scrum is very transparent process. We will give entire decision making to the product owner whether we need to proceed with these changes are wants to change everything. You might have question like, is this right way of doing? Human brain never be stable with one decision, I do accept that.
In the scrum practice after each sprint, the sprint team will give demo on what they have done as per requirements. Client can raise questions and can ask for changes. Because of this approach client will be aware of what had implemented and if he needs any change he can ask and these changes will be taken care in next sprint depends on product owner decision. So Client will be happy with his interaction at high level and can see the progress. Because of this approach, after looking at developed sprint he might come-up with his few more ideas or specification. It will help him in understanding and finding needs.
Design: In the scrum practice we won’t maintain complete design for complete application. Only we have architectural design at high level. Component design will be maintained at sprint level. The design that the team is doing in this scrum practice is sprint design not the application design. While doing design for the sprint think about next sprints and do it for future purpose. What will happen if design fails? If design fails it affects only that sprint or previous few sprints not the complete application. If there is any change in design which need to be handled then, it will be notified to product owner to make the decisions and if they want to change then next sprint will start to accommodate new design changes.
What is the advantage of having design for single sprint? It is very simple, specification is very less and scope is very less. So you can spend your time in understanding needs and can come up with better design. One thing here every one need to remember, when you are doing design for the sprint, you must be assume that there will be some sprint which will be going to use this design and you must do the design to accept those changes.
Testing: In the scrum practice testing is a part of sprint. Tester will work along with developers and will be involved in the design phase. In the scrum practice anyone can do any work. Developer can do testing and tester can involve in design (don’t expect them to do code). Testing will be done as and when coding has completed so if there is any issues it can be resolved right away and testers will be closely work with development team so they can easily identify when issue got raised it will useful for developer to go back to most recent changes and can save their time in fixing the issue.
So after each sprint code that is done is a shippable code and can be moved to production systems if client need that feature or functionality. There might be some integration problem after moving to integration environment, in this case the patch that moved more recent and which caused the problem will be reverted to sprint and sprint team has to resolve those problems.
Product owner/Client: In this scrum practice we involve product owner and client (if client is not product owner) in each phase of sprint. And after each sprint we will give demonstration to client for explaining what we have done and looking forward, whether we did right or not with client feedback. So after each sprint release team will be getting feedback from client based on the feedback they do changes so when release time comes client will be aware of what had implemented so there won’t be any surprise things to see after release. And good thing is you won’t hear “This is not I am expecting”, until unless you won’t involve client in each phase of development.