I know after reading previous content you might feel that, this approach is so simple and easy to follow. But scrum itself a challenge. The team is committing to management that we are going to do these stories in this scrum. Team has to work hard to reach that goal. In the scrum every member has equal responsibility, everyone has to work and mingle with each other. Creating a comfort atmosphere among team member is a challenging task. The entire sprint depends on each individual and team communication. In this scrum approach there won’t be any boss. So when there is no boss, we have to educate each team member such that they have to feel responsible. I know it’s hard to follow for existing team who are working when boss put some pressure on them and commanding them. If any one feels that I am going to work when someone commands and look at me, and then just get of the scrum, it is not for you.
Until unless people realizes with what is exactly scrum it never going to be succeed. The success of the scrum practice completely depends on how the company manages to educate the member to understand this process. You know basic motto of scrum practice is “Adapt”. I can give guarantee that 99% scrum will be failed at initial stage, not because of lack of knowledge or understanding but lack of proper sprint planning. The team which will learn from mistakes can sustain quickly than other team.
Most of the people have misunderstanding that with this approach there won’t be any product manager. Technically it is true but product manager can manage the scrum, as a scrum master. But it real scrum practice it is not advisable. It needs lot of changes in product manger attitude towards the team.
Product Back Log
What is a product back log? Who is going to maintain this? How many back logs do we need to maintain for a project? I think these are questions might rise in your brain. Let’s clear these questions first
Product back log is a place to keep all our requirements. Anyone can update product back log. Requirements will be collected for clients, end user and product expertise and will be posted in product back log. This product back log holds all the requirements relate to a project. There will be only on back log exists for one project. There should not be more than one. We must have a common place to trace all requirements. If we have more than one then it is very complicated to maintain requirements and priorities and updates. We might miss some updates at one place it will lead so many complications and it is also create more confusion to people who are going to use or refer the back log for updates or requirements. So there should be only one product back log exists for one project.
Product owner is responsible for the product back log. Client can be act as product owner. The product owner responsibility is to update priorities and understand the requirements.
Product owner is the person who is going to manage product back log. Product owner has to review product back log periodically and updates priorities. Priorities will be updated based on client needs and ROI (Return on Investment). Product owner will give priorities but he is not involved in work load or efforts. How much a team can do, will completely depends on the team. They have to decide how much they can do, and they have to provide estimates for the task that are going to work on.
Product owner has right to terminate current sprint and can start new sprint based on product back log. If team has any impediments then product owner has to resolve those impediments. He is responsible for solving any product related issues. Team need to discuss and have to resolve any problem exist in the team, if they are not able to resolve then they can discuss with product owner. Creating such environment in the team for resolving their problems is scrum master responsibility.
Scrum master is the person who is looking at sprint team and monitors the progress. The scrum master can be a member of the sprint team. But a scrum master look at one sprint team. He is going to monitor one team progress. He is completely responsible for entire team. He has so many responsible in the Scrum practice. He is the person who will do actual work in sprint planning.
- He has to protect team from other interference.
- He has to respond to each and every problem of the team members
- He is responsible for team interactions
- He is responsible for sprint planning
- He has to collect each team member opinion and effort regarding each task.
- He has to give points to each user story after having discussion with team.
- He has to make sure that no one influences other team member for giving efforts.
- He has to make sure that all team members understood the requirements clearly.
- He is responsible for not making any changes in the committed work after sprint started.
Scrum master is never being responsible for sprint release. He is responsible for work progress. The team is going to be responsible for entire sprint release.
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.